¿Protegerse contra XSS al configurar cookies basadas en URI?

Navega tus respuestas
0

Tengo un sitio web escrito en nginx.conf - enlace - que esencialmente acepta dos parámetros, un sistema operativo y un nombre de página del manual y realiza una redirección a un sitio diferente según los parámetros de la URL.

Dado que la intención es que el sitio se navegue y se use directamente desde la barra de direcciones del navegador, todos los caracteres cuentan, y quiero que sea posible tener un location que establezca una cookie a través de un enlace regular. Solicitud de GET , de modo que se pueden realizar más solicitudes de páginas de manual sin especificar un sistema operativo.

Sin embargo, me di cuenta de que si establecía incondicionalmente una preferencia / cookie basada en un parámetro en la URL, entonces mi sitio estaría sujeto a XSS, ya que cualquier otra página web podría crear una URL de configuración de cookies maliciosas y cargarla. en segundo plano, modificando las cookies de mi sitio y rompiendo el paradigma de seguridad.

¿Cuál es la solución? ¿No puedo configurar las cookies de forma segura en un idioma como nginx.conf que no lleva ningún estado entre las solicitudes?

    
pregunta cnst 13.03.2013 - 07:02
fuente

2 respuestas

0

Parece que la solución es proporcionar al usuario una página intermedia después de ingresar la URL de configuración de cookies.

En dicha página, simplemente proporcione un enlace a sí mismo.

Dentro de nginx.conf , verifique $http_referer en un location de dicha página; si coincide con $request_uri , configure la cookie; de lo contrario, sirva la página con el enlace a sí mismo, con Cache-Control: no-cache .

Esta solución se basa en la idea de que no es posible modificar el encabezado HTTP Referer (a través de JavaScript o de otra manera) en las solicitudes realizadas por los navegadores web.

Incluso sería inmune incluso si fuera posible acceder a sockets TCP sin formato desde JavaScript ( sockets sin procesar desde el JavaScript del navegador web no son posibles por razones de seguridad) y cree sus propias solicitudes personalizadas, porque incluso entonces tales sockets existirían en un reino separado del que Las solicitudes HTTP del motor del navegador web y las respuestas no se tratarán como HTTP y no podrán establecer ninguna cookie.

    
respondido por el cnst 13.03.2013 - 07:02
fuente
0

Como solo hay unas pocas versiones de BSD, puede hacer fácilmente una lista blanca en el servidor. Solo configure la cookie si "versión de SO" coincide con las versiones de SO permitidas. Si la comprobación falla, redirija al usuario a la raíz del documento de su sitio web.

No veo por qué esto sería un ataque XSS ya que la cookie modificada no se lee ni se usa en ningún lado del lado del cliente con JavaScript. Si me equivoco, por favor dígame.

    
respondido por el Matrix 13.03.2013 - 21:27
fuente

Lea otras preguntas en las etiquetas

Cómo recuperar datos borrados de forma segura duplicar o completar ciclos de algoritmos de encriptación