Cross-site request forgery

Cross-site request forgery, abreviado como CSRF o XSRF es un tipo de ataque malicioso de paginas web. Aunque este tipo de ataque se parece a los de cross-site scripting (XSS), XSS requiere al atacante inyectar un codigo a la pagina web, mientras que CSRF es un metodo mas de "ingenieria social" ya que hay que pasarle un URL a la victima, haciendo esta una accion.

Ejemplos

Un envio de mail:

http://[server]/index.php?subject=Tarado&message=Sos un gil!&submit=OK

Eso enviaria un mail al administrador de la pagina con los siguientes datos:

Usuario que lo mando= La victima (si tiene cookie logueada en este website)
Asunto: Tarado
Mensaje: Sos un gil!

Todo esto se hizo solamente porque la victima abrio un URL que le paso el atacante. Obviamente, la victima tiene ke tener cookie en la web, para que al entrar en esa URL ya este logueado y le mande un mail al administrador puteandolo Casi siempre estos tipos de ataques se ven en formularios de contactos, foros, y cosas asi

Practica

Supongamos que tenemos un codigo de fuente asi:

Y el server es Argentohack.com.ar con Path envia.php Como lo explotariamos? Asi:

http://argentohack.com.ar/envia.php?asunto=0wned&mensaje=Mensajeaca&Enviar=Ok

Con esta vulnerabilidad podemos perjudicar asi a la web como tambien a un usuario

Prevenir el ataque

For the web site, switching from a persistent authentication method (e.g. a cookie or HTTP authentication) to a transient authentication method (e.g. a hidden field provided on every form) will help prevent these attacks. A similar approach is to include a secret, user-specific token in forms that is verified in addition to the cookie. An alternate method is to "double submit" cookies. This method only works with Ajax based requests, but it can be applied as a global fix without needing to alter a large number of forms. If an authentication cookie is read using JavaScript before the post is made, the stricter (and more correct) cross-domain rules will be applied. If the server requires requests to contain the value of the authentication cookie in the body of POST requests or the URL of GET requests, then the request must have come from a trusted domain, since other domains are unable to read cookies from the trusting domain. On the other hand, this method forces users to enable JavaScript, negating the only way a user has to prevent most cross-site scripting vulnerabilities from being exploited. Contrary to popular belief, using POST instead of GET does not offer sufficient protection. JavaScript can be used to forge POST requests with ease. Nonetheless, requests that cause side effects should always use POST.[1] Also, POST does not leave a trail of variable data in web server and proxy server logs, while GET does leave such a trail. It is still clearly best to use POST when coding in a defence in depth approach. Another approach is to check the HTTP Referer header to see if the request is coming from an authorized page. Unfortunately, this technique may not work reliably, since browsers sometimes omit the Referer header because of a user's privacy settings or because the Referer is a secure https page. Although cross-site request forgery defenses typically require modifying the web application, individual users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session.[2]

Saludos Phanter_RooT [at] argentohack.com.ar