¿Defensa contra ataques del mismo origen?

4

La pregunta:

¿Cómo puedo, como víctima, proteger mi sitio para que no sea manipulado y no pueda hacer algo que se supone que no debe hacer, en un servidor compartido? La política del mismo origen mira hacia otro lado. Probablemente lo más conveniente sería si pudiera decir algo como "mi url = origen siempre único" .

Fondo:

He entrado recientemente en el mundo de Javascript y he aquí mi comprensión de Política del mismo origen : SOP entra en juego siempre que dos sitios en orígenes diferentes interactúan, ya sea a través de XMLHttpRequest , <script> loading, acceso DOM a través de window.open() 's Window de referencia o mediante un iframe ..

Ahora está todo bien y bien en el caso de un "un sitio por dominio" o "en el sitio por subdominio" , pero ¿qué pasa con el alojamiento compartido o los dominios compartidos? ?

Escenario:

Deje que el sitio del chico bueno resida en

http://shared-hosting.tld/~target/administration/

y el atacante está en

http://shared-hosting.tld/~attacker/

Aparte de las cookies, la víctima tiene una sesión autenticada que de alguna manera está ocurriendo en /administration/ (cookies, almacenamiento local, lo que sea). Después de esto, el atacante engaña a la víctima para que visite el sitio en /~attacker/ y al usar window.open() o iframe en el sitio del atacante, navega por el navegador de la víctima hasta /administration/ . Ahora que el atacante tiene una referencia al objeto Window y ambos sitios son del mismo origen, el atacante tiene acceso completo al contenido de ese sitio mediante la manipulación de DOM (autenticado y todo), porque el SOP no interfiere.

Y por favor no se enrede cómo el sitio /administration/ de la víctima autentica (y mantiene) el estado autenticado de los usuarios. A menos que haya una manera de solucionar este problema de esa manera.

También:

Entiendo que solo estoy apuntando al objeto Window y al acceso a DOM a través de él, porque no veo (sé) otras formas en que un sitio podría interactuar maliciosamente con otros sitios en un host compartido en este caso , pero no dude en resaltar otras malas intenciones relevantes para esto.

Algunas reflexiones: ¿Javascript está comprobando la carga de páginas legítimas? No parece que ayude. ¿Encontrando el sitio "real" de la víctima dentro de un sitio "bienvenido" con un atributo de caja de arena? ¿No se permite el acceso de los padres y niños? .. Todo parece volver siempre al "padre" pudiendo acceder al "niño" sin ninguna restricción.

    
pregunta Gima 24.03.2013 - 17:19
fuente

2 respuestas

5

En primer lugar, debe leer la Parte 2 del Manual de seguridad del navegador, específicamente la la misma política de origen para Acceso DOM y XMLHttpRequest .

La misma política de origen está limitada por el nombre de dominio, no por la ruta y es probable que esta regla fundamental nunca cambie. Si dos aplicaciones web comparten el mismo dominio, entonces podrán leer los datos de los demás utilizando un XMLHttpRequest. Esto se puede usar para derrotar tokens CSRF , en un ataque similar al de Sammy MySpace worm . El identificador de sesión también puede ser accesible si el indicador de cookie http_only no está establecido.

Entonces, ¿cómo tiene dos aplicaciones correctamente en un espacio aislado? Deben estar en un dominio diferente . Los subdominios son gratuitos , por lo que para usar el SOP para el sandbox de estas aplicaciones, debe usar target.shared-hosting.tld y attacker.shared-hosting.tld .

Si lees la política de cookies del mismo origen , verás si una cookie está orientada a shared-hosting.tld , luego *.shared-hosting.tld podrá acceder a este valor de cookie. Pero esto también es fácil de evitar, solo asegúrate de que todas las cookies estén sujetas al subdominio, por lo que www.shared-hosting.tld sería un dominio seguro.

Y este uso del SOP para aplicaciones de sandbox funcionará bien, siempre y cuando la aplicación de destino no sea vulnerable a XSS.

    
respondido por el rook 24.03.2013 - 17:46
fuente
1

La respuesta corta es poner tu aplicación en su propio dominio. No comparta el dominio con nadie de su confianza.

Por ejemplo, en lugar de alojar tu contenido en http://shared-hosting.tld/~gima/ , alójalo en http://gima.shared-hosting.tld/ o http://gima.org/ . Cualquier buena compañía de hosting debería apoyar esto. (Si no lo hacen, ¡elija una empresa de alojamiento diferente!) Si utiliza cookies, http://gima.org es más seguro que http://gima.shared-hosting.tld/ , ya que evitará que otros usuarios utilicen el mismo servicio de alojamiento compartido.

Si haces esto, la política del mismo origen te protegerá.

    
respondido por el D.W. 25.03.2013 - 03:19
fuente

Lea otras preguntas en las etiquetas