Es un poco difícil de responder en detalle cuando no proporciona información crítica como la arquitectura del sistema, la plataforma, el servidor web y los marcos involucrados. Si las cosas se hacen bien, el riesgo es insignificante. Para saber si se han hecho correctamente y continuará se está haciendo bien ... ay, ahí está el problema. Lo que depende de la información de la que estaba hablando.
A falta de esa información, voy a salpicar mi respuesta con might 's y a veces ' s; por favor ten paciencia conmigo.
¿Hay algún riesgo de seguridad que deba tener en cuenta con esta configuración?
Puedo pensar en algunos de ellos, pero otros seguramente existen. Muchos de estos se basan en la suposición de que podría existir una vulnerabilidad en el sitio public , y se refieren a si y cómo podría influir en el sitio privado.
-
secuestro de sesión y destello. En algunas plataformas (principalmente las pilas de PHP y * AMP), los datos de la sesión pueden almacenarse en el sistema de archivos y pueden consultarse en el proceso de cualquier . Lo que significa que un proceso deshonesto en el servidor web público podría enumerar o adivinar los nombres de los archivos de datos de la sesión, leerlos y revelar información que podría ser crítica.
-
omisión de autenticación. De nuevo, dependiendo de la plataforma, podría ser posible engañar al sitio seguro para permitir el acceso a un usuario del sitio público. Esto no pasa por alto la verificación de la dirección de red, por lo que si niega el acceso privado a direcciones externas, este vector de ataque específico se frustrará.
-
denegación de servicio. Por supuesto, el sitio privado comparte algunos recursos con el sitio público, y puede estar sujeto a una denegación de servicio de esa manera.
-
ataques entre sitios. Esto depende demasiado de la estructura del sitio para dar detalles. En términos generales, existen medidas de seguridad para evitar que victimsite.com suministre el código que llama a casa a evilhost.com . Muchas de estas medidas funcionan menos, o no funcionan, si los dos sitios tienen las formas public.site.com y private.site.com . Este vector de ataque involucra a alguien que proporciona un enlace al sitio público a una víctima en el interior (por ejemplo, a través de un correo electrónico), y un código de secuencias de comandos en el sitio público que intentaría robar Información o causar estragos en el sitio privado. Si esto funciona, es decir, si el sitio público es vulnerable a este tipo de ataque, funcionará mucho mejor en el sitio privado en el mismo dominio, que si estuviera en un dominio diferente.
-
conexiones compartidas, compartibles o forzadas. Si el sitio público se divide, un atacante ya está dentro del perímetro de identificación del sitio privado. Suponiendo que pueda recuperar las credenciales necesarias (y en algunas plataformas, esto es posible; requiere un endurecimiento no predeterminado para evitarlo), puede identificarse ante otros hosts, por ejemplo. La base de datos con información confidencial, y es mucho mejor (en la mayoría de los * AMP, que se aproximan al 100% del lado equivocado) la posibilidad de que se le permita el acceso.
-
acceso a nivel de código. Esto no es muy probable, ya que requeriría otras vulnerabilidades, como el acceso de escritura por el proceso del servidor web y el mismo nivel de acceso entre los subprocesos que pertenecen a los sitios públicos y privados. Aún así, excepto por unas pocas excepciones felices (Debian y Ubuntu), esta es a menudo la configuración predeterminada a menos que el administrador del sistema tome medidas específicas. En el peor de los casos, esto permite una vulnerabilidad en el sitio público para otorgar a un atacante acceso completo a todo a partir de las contraseñas relacionadas con el sitio privado, además de modificar la información y los informes, interceptar algunos tipos de tráfico (piense "webmail"), y destruir datos.
En un sistema debidamente asegurado (por ejemplo, aquí , puntos 6 en adelante; algunos punteros en PHP y, por supuesto, OWASP ), tendría pocas preocupaciones. Todavía lo suficiente como para preguntarme, ¿realmente debo hacer esto? ; no es como el espacio del servidor es tan caro ya. Pero muy pocos. Especialmente si los administradores de sistemas se mantienen al día con los avisos necesarios.
Por otro lado, colocar un sitio privado y supuestamente seguro en un sistema instalado fuera de la caja y que no esté muy bien mantenido (por ejemplo, una instalación de Wordpress) equivale a conjurar a Murphy en su peor momento, y no puedo recomendar demasiado en contra.