Cross site request forgery (CSRF) estan diseñados para enviar que un FORM POST oculto en maligno.com sea enviado en secreto para secuestrar su cuenta en ejemplo.com. Los sitios web como Facebook implementan esto utilizando algo llamado "fb_dtsg" con la solicitud, y el proposito general es que solo puede realizar una accion (como actualizar su correo electronico) si se envia un valor valido de "fb_dtsg" con la solicitud. A menos que el atacante tenga XSS, ningun atacante puede obtener este valor unico y falsificar una solicitud cuando visita su sitio malicioso. En este tutorial voy a describir un bypass interesante que encontre, asi como las cosas que tambien puedes probar.
El sitio tiene un token CSRF... no es vulnerable - piénselo de nuevo
Un programa de recompensas tenia tokens CSRF en todas sus solicitudes. Literalmente, cada accion que realizaba se enviaba con un token CSRF. El bypass fue en realidad extremadamente simple, uso de clickjacking.
Si, por ejemplo, estaba actualizando el correo electronico de mi cuenta y modifico la solicitud para enviar un valor CSRF en blanco, reflejaria los cambios que queria hacer pero con error: CSRF_token no es valido. Por favor, vuelva enviarlo... el correo electronico no se habia actualizado exitosamente, pero habia sido reflejado en la pagina.
Gracias a la falta de X-FRAME-OPTIONS, pude enviar la solicitud para actualizar el correo electronico, luego anote el resultado "haga clic en el usuario" para hacer clic "enviar". Bingo, esa cuenta ahora es mia!.
Otras formas comunes de eludir tokens CSRF
Token CSRF en blanco
Extremadamente simple, solo intente enviar un valor CSRF en blanco y vera si validan del lado del servidor. No se olvide de ver tambien si los cambios que intento realizar se reflejan en la pagina. ¡Combine esto con clickjack y tendra un problema potencial de CSRF en todo el sitio!
Compartiendo tokens CSRF
He tenido casos en los que mientras la sesion de los usuarios es valida, el token CSRF de los usuarios se puede compartir en cualquier otra cuenta. Cree dos cuentas y vea si puede compartir tokens csrf entre las mismas.
Cambiar un caracter
A veces, un sitio solo verificara la longitud de un token CSRF (tonto, lose). Intente cambiar un caracter (para que tenga la misma longitud) y vea que sucede. Te sorprenderias.
Usando archivos .swf
@avlidienbrunn hizo un gran informe sobre el uso de archivos .swf para CSRF: https://hackerone.com/reports/44146
¿Puedes usar CSRF en JSON y XML?
Claro que se puede, esto podria requerir un poco de juego, ya que aveces tienes que usar el caracter '=' en algun lugar, A continuacion se muestra como realizar para XML:
<html>
<body>
<form ENCTYPE="text/plain" action="http://sitiovulnerable/prueba.php" method="post">
<input type="hidden" name="<foo> <html xmlns:html='http://www.w3.org/1999/xhtml'> <html:script>alert(1);</html:script> </html> </foo>">
<input type="submit" value="submit"> </form>
</body>
</html>
Y en JSON (este ejemplo exporta una lista de contactos)
<html>
<body>
<form ENCTYPE="text/plain" action="http://vulnsite.com/snip/snippet.php" method="post">
<input type="hidden" name="{"params":{"limit":20,"and":false,"filters":[],"excluded_contacts":[]},"fields":["First Name","Last Name","Email Address","Title","Notes","Organization","Street","City","State","Tags","Zip Code","Phone Number","Gender","Event ID","Event Title","VIP","Twitter Handle","Twitter URL","Twitter Followers","Twitter Following","Facebook Name","Facebook URL","Facebook Friends","Instagram Handle","Instagram URL","Instagram Followers","Instagram Following","Website","Date Added","Unsubscribed"],"recipient":"myemail+2" value='@gmail.com'>
<input type="submit" value="submit"> </form>
</body>
</html>
Observe como se esta utilizando el "=" en el parametro de correo electronico, gracias a la forma en que funciona Google Mail, un correo electronico enviado a myemail+2=@gmail.com ira a myemail@gmail.com.
Proteccion CSRF a traves de Referer
He visto sitios que verifican si el Referer es su sitio y si es = a su sitio entonces permiten la solicitud. Si no es = entonces bloquean la solicitud. Un enfoque interesante para detener los ataques CSRF, como podemos evitar esto es usando la siguiente manera:
* https://tusitio.com/https://www.elsitiovulnerable.com/
Algunos sitios solo comprueban si CONTIENE la URL de su sitio web, lo que significa que solo podemos crear una carpeta en nuestro sitio para enviar la solicitud CSRF.
* Enviar un Referer en Blanco
Enviar un formulario dentro de un iframe realmente le dara un Referer en blanco. A veces esto es suficiente para pasar por alto su proteccion.
Probablemente haya algunas cosas que me falten, o quizas tenga un concepto interesante para evitar el CSRF. Si es asi, no dude comunicarse conmigo y lo agregare aqui. Happy Hacking.
No hay comentarios:
Publicar un comentario