¿La navegación de incógnito / privada evita los ataques XSS?

15

Al iniciar una sesión de navegación privada / de incógnito, no deben existir cookies de otros perfiles de navegación. Por ejemplo, si estoy conectado a un sitio en mi perfil de navegación principal, luego comienzo una nueva sesión de navegación privada, no estoy conectado a ese mismo sitio (cookies que no se transfieren). Suponiendo que se trata de una nueva sesión de navegación privada, no debería haber ninguna cookie o información confidencial existente que esté disponible.

¿Esto también tiene el efecto secundario de prevenir o anular los ataques XSS, ya que no hay datos confidenciales para robar? ¿O es una falsa sensación de seguridad?

    
pregunta Jack 21.10.2018 - 21:42
fuente

3 respuestas

32

Un ataque XSS no se trata principalmente de cookies. Tampoco se trata de robar datos confidenciales. En su lugar, se trata de ejecutar un código controlado por un atacante en el lado del cliente dentro del contexto del sitio que visita. El tipo de daño que puede hacer este código depende del sitio y el contexto reales.

El uso de una sesión de navegación privada no evitará el XSS por sí solo, pero podría limitar el impacto del daño que puede hacer el XSS, es decir, no tiene acceso a las cookies u otros datos almacenados desde la sesión del navegador no privado. Aunque podría hacer daño, pero nuevamente, esto depende del contexto específico y del sitio que visite.

    
respondido por el Steffen Ullrich 21.10.2018 - 21:49
fuente
3

Existen principalmente dos tipos de ataques XSS: persistentes y ad hoc.

Una sesión de navegación privada lo protegerá de ataques XSS ad hoc, pero no de ataques persistentes.

Un XSS persistente funciona cuando un atacante inyecta un código de script en algún lugar de la página sensible, esto podría hacerse enviándole un mensaje preparado en la plataforma, o por algún otro medio de inyectar datos en el almacenamiento de la página sensible. Cuando inicie sesión en la página confidencial para ver algunos datos, el servidor cargará los datos inyectados, los transferirá a su navegador y se ejecutarán si el sitio es vulnerable. Un ejemplo sería un mensaje preparado en una transacción de banca en línea. El atacante le enviaría una transacción real y la parte del mensaje contendría un script dañino. No hay ninguna otra página involucrada, por lo que no puede protegerse contra esto, solo el propietario de la página puede hacerlo.

Un XSS ad-hoc puede funcionar haciendo que haga clic en un enlace preparado, que incluye datos de inyección. Dicho enlace podría parecerse a https://banking.securebank.com/searchTransaction?query=<script>doEvil(...)</script> , donde el script inyectado es parte del enlace. El atacante intentará que hagas clic en este enlace o intentará ejecutarlo en segundo plano a través de JavaScript desde su propia página preparada. Por lo tanto, si abre enlaces de correo electrónico y páginas que no son de confianza en una sesión separada, su cuenta de usuario en la página confidencial estará a salvo de este tipo de ataque, ya que no ha iniciado sesión en la página sensible en la sesión de incógnito. Por lo tanto, aunque el XSS aún pueda ejecutarse, no puede causar ningún daño a su propia cuenta en la página confidencial, que es lo que queremos proteger.

    
respondido por el Falco 22.10.2018 - 09:32
fuente
1

Como ya mencionó Steffen, un XSS ( cross ataque de secuencias de comandos del sitio), no por definición solo funciona con cookies. Si alguien tiene acceso a una base de datos y edita ciertos campos, que contienen etiquetas de script que pueden ejecutarse en ciertas páginas web, puede ejecutar un ataque XSS.

Simplemente significa que alguien ejecuta scripts en su navegador en la página que está visitando para recuperar su información (quizás cookies) o engañarlo ajustando el DOM para, por ejemplo, vincular un botón de pago a su sitio web defectuoso.

    
respondido por el Devilscomrade 22.10.2018 - 08:39
fuente

Lea otras preguntas en las etiquetas