Subdominios específicos del usuario: seguridad de JavaScript

Question

Subdominios específicos del usuario: seguridad de JavaScript

#1 de D.W. (5 votos)
#2 de tifkin (5 votos)

9

Si proporciono un sitio web público para los usuarios en mi sitio web en su propio subdominio (por ejemplo, bob.myapp.com ) bajo su propio control, ¿puedo permitir que ejecuten JavaScript arbitrario sin poner en riesgo mi servidor de aplicaciones principal (por ejemplo,% código%)? Los usuarios podrían poner sus propios archivos myapp.com en la raíz pública de sus subdominios.

Tengo un extremadamente conocimiento limitado de la Política de JS Same Origin, pero creo que los diferentes subdominios cuentan como diferentes orígenes. Por lo tanto, si mi aplicación principal ( *.js ) está protegida desde XSS, etc., ¿hay algo específico por lo que deba preocuparme por los subdominios de los usuarios de los que no tendría que preocuparme por ninguna otra fuente externa?

¡Gracias!

web-application web-browser http javascript same-origin-policy

pregunta AviD 25.10.2012 - 20:17

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application web-browser http javascript same-origin-policy

Almacenar números de cuenta y códigos de clasificación en línea DUKPT: ¿cómo verifica el receptor el contador de transacciones?

score 5 · Answer 1

Sí, tienes que preocuparte. Si bien los subdominios están en su mayoría aislados de su dominio principal (gracias a la política del mismo origen, hay algunas excepciones que podrían suponer un riesgo).

Un riesgo tiene que ver con las cookies. La secuencia de comandos en bob.myapp.com puede establecer una cookie para myapp.com . Esta cookie se enviará a myapp.com cuando el usuario visite myapp.com . Esto se puede usar para ataques de fijación de sesión.

Por ejemplo, el contenido de usuario malintencionado puede establecer una cookie de sesión ( sessionid=1234 ) con el dominio myapp.com . Luego, cuando el usuario visita myapp.com , su navegador enviará la cookie de sesión establecida por el atacante. Como el atacante conoce el ID de sesión que usará el usuario, ahora el atacante puede secuestrar su sesión.

Una mitigación es alojar el contenido del usuario en alice.myappusercontent.com , bob.myappusercontent.com , etc., mientras que su aplicación está en myapp.com . Eso debería detener estos ataques.

La referencia clásica para obtener información sobre la política de origen del mismo y el aislamiento en la web es el Manual de seguridad del navegador . Consulte especialmente la sección en la política del mismo origen y en vida fuera de las reglas del mismo origen .

score 5 · Answer 2

A mi entender, la política del mismo origen protegerá a los usuarios de AJAX entre sí, pero no necesariamente a su sitio principal. Por ejemplo, user1.myapp.com no podrá publicar solicitudes en user2.myapp.com, pero podrá publicar solicitudes en myapp.com. Puede resolver esto obligando al sitio principal a utilizar el subdominio "www" (www.myapp.com) y enviar cualquier solicitud a myapp.com allí.

Hay algunas cosas que podría hacer para ayudar a proteger las cookies de su aplicación principal. Asegúrese de que todos los dominios de sus cookies están vinculados a un específico y no están siendo comodines (por ejemplo, * .myapp.com), de lo contrario los subdominios podrán acceder a ellos. Puede habilitar la marca HttpOnly para evitar que los usuarios roben la cookie a través de javascript. Si los usuarios pueden usar los idiomas del lado del servidor, coloque su aplicación principal en un subdominio, de lo contrario, podrán acceder a sus cookies. También sería aconsejable habilitar el indicador de seguridad.

Para obtener más información sobre la política del mismo origen (y muchos otros temas de seguridad de aplicaciones web), eche un vistazo a Browser Security Handbook o su libro The Tangled Web .