¿Qué es más seguro: muchos subdirectorios, o muchos subdominios?

Question

¿Qué es más seguro: muchos subdirectorios, o muchos subdominios?

#1 de atdre (8 votos)
#2 de rook (8 votos)

6

Tengo 3 sitios web que podrían configurarse como "VirtualApplication" en servicedefinition.csdef:

www.mydomain.net/enroll

www.mydomain.net/admin

www.mydomain.net/

... o puedo configurarlos como un sitio:

enroll.mydomain.net

admin.mydomain.net

www*.mydomain.net

Dado que tengo la intención de instalar SSL en mi sitio, planeo comprar el dominio con un nombre SAN de "www.mydomain.net" O "* .mydomain.net". Mi pregunta es ¿qué enfoque es más seguro?

¿Hay alguna guía sobre lo que debería ser el dominio de la cookie o el URI de la federación? Mi preocupación con el enfoque de VirtualApplication es que la cookie de raíz para "/" puede abrirme a varios ataques.

Del mismo modo, me preocupa el uso de un certificado de comodín, ya que es más caro y el hecho de que sea un comodín elimina cualquier posibilidad de un certificado EV. También creo que los certificados de comodín no tienen una garantía sólida (en caso de manipulación SSL).

web-application tls csrf cloud-computing azure

pregunta random65537 13.04.2011 - 22:29

fuente

2 respuestas

8

Hay al menos un beneficio de seguridad de los subdominios. Si hay una vulnerabilidad XSS en enroll.mydomain.net , no se puede usar para secuestrar una sesión en admin.mydomain.net . Esto se debe a la Política del mismo origen . También haría que sea más fácil mover esa aplicación a un servidor diferente si es necesario. El aislamiento del fracaso es un buen enfoque de defensa en profundidad.

Entonces, sí, los subdominios son más seguros que los directorios.

respondido por el rook 13.04.2011 - 23:13

fuente

Lea otras preguntas en las etiquetas web-application tls csrf cloud-computing azure

¿Cómo enrutan las VPN el tráfico SSL y comprometen la seguridad? Encuentre el agujero de seguridad en mi sitio y evítelo [duplicar]

score 8 · Accepted Answer

Ninguna de las dos es necesariamente más segura, pero le daré algunas opiniones y quizás hechos.

Host-extract puede determinar los nombres de host, que también es posible a través de enumeración de host virtual .

DirBuster , skipfish , y fuzzdb puede confiar en navegación forzada , índices de directorio y ubicaciones de recursos predecibles para encontrar Estructuras de directorio vulnerables y otras cuestiones. Las arañas y rastreadores pueden atravesar directorios, y algunos también pueden atravesar nombres de host (sé que skipfish es capaz de hacer esto).

De alguna manera, el alojamiento virtual es más difícil de administrar (usted mencionó SSL, lo cual es un gran punto). Si esto es fácil de administrar, puede terminar siendo más seguro debido a la capacidad de los directorios para filtrar mucha más información que los nombres de host y para ser más vulnerables a ataques como XSS (como lo describe @Rook en su respuesta). ).

Prefiero al menos separar los sitios (por nombre de host) que contienen comportamiento (por ejemplo, Flash, Ajax, bibliotecas de Javascript, marcos RIA, páginas dinámicas, etc.) en lugar de los que tienen formato o contenido estático (HTML, CSS, XHTML, páginas no dinámicas). Creo que también es una buena práctica separar los dominios SSL de los dominios no SSL. El motivo es que puede proporcionar controles más estrictos sobre el escape de contexto en los nombres de host SSL / TLS que en los nombres de host no SSL / TLS. Si separa Javascript de CSS de HTML, entonces sabrá qué codificación contextual debe tener lugar en qué nombres de host también. Tengo más sugerencias sobre cómo manejar XSS en esta publicación donde menciono a no compila HTML en el servidor y otros tidbits .

Por lo general, esto nunca depende de un profesional de seguridad, o un equipo de seguridad. Depende de los desarrolladores, comercializadores y expertos en SEO. Ellos deciden qué obtiene un nombre de host o una estructura URI. Investigaré más sobre este tema y actualizaré mi respuesta a medida que obtenga nueva información. Es una pregunta interesante.