CSRF es posible si los parámetros no se pasan a través de la cadena de consulta?

Navega tus respuestas
0

Estaba leyendo en página de OWASP en CSRF y en su ejemplo usan una solicitud donde los parámetros sensibles se almacenan en la cadena de consulta: 

http://bank.com/transfer.do?acct=MARIA&amount=100000

En mi sitio, hago una solicitud donde no se almacena nada sensible en la cadena de consulta: 

http://mysite.com/accounts/delete

Pero si observa la solicitud sin formato, puede ver la información confidencial: 

POST /ajax/deletion/account HTTP/1.1
Host: www.mysite.com
Connection: keep-alive
Content-Length: 15
Accept: application/json, text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
Content-Type: application/json; charset=UTF-8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: X-Mapping-fjhppofk=B8BFE26CD0B3A37348ECC6FFE3948274; connect.sid=s%3A4t4wfMTR6kCPRfwe5OEmYbse.Y%2FOfSmt%2Bo5JWDWglvUHIufOOFvfebr86CLiUcgdW6j8; 

{"account_id":35653}

Lo que me pregunto es si estoy a salvo de los ataques CSRF, ya que no incluyo ningún parámetro en mi cadena de consulta. Si no estoy a salvo de CSRF, ¿cómo podría un usuario malintencionado enviar una solicitud falsificada?

    
pregunta Abe Miessler 21.08.2013 - 19:37
fuente

3 respuestas

1

Las solicitudes POST pueden, de hecho, ser falsificadas entre dominios, sin embargo, depende del tipo de datos que intenta POST.

Parece algo como esto: enlace 

<form name="badform" method="post"
 action="http://bank.com/money_transfer">
    <input type="hidden" name="destinationAccountId" value="2" />
    <input type="hidden" name="amount" value="1000" />
</form>
<script type="text/javascript">
    document.badform.submit();
</script>

Si un atacante crea una página HTML con esto en ella, y atrae a una víctima (con Javascript habilitado) a esa página, se enviará esa solicitud POST y se ejecutará la transferencia si el cliente está actualmente registrado en bank.com y si no están utilizando tokens CSRF.

Sin embargo, en su ejemplo específico, son los datos JSON que se están POSTANDO, no el POSTing HTTP tradicional de parámetros.

Para eso, puedes usar una de las siguientes técnicas: enlace

Sin embargo, como dice @Patrick, no podrás suplantar el tipo de contenido. Entonces, si el servidor está comprobando que la POST tiene un tipo de contenido de application/json y solo lo permite en tales casos, y / o si el encabezado X-Requested-With: XMLHttpRequest está marcado, entonces no será posible. Pero si no están marcados, no es difícil hacerlo.

Respuesta corta: en muchos casos, sí, es posible incluso si no hay una cadena de consulta, y los tokens CSRF siempre deben usarse independientemente del método HTTP del formulario o del tipo de datos que se envíen.

    
respondido por el Anorov 21.08.2013 - 19:50
fuente
0

CSRF trata de hacer que el navegador de la víctima envíe una solicitud a un servidor, de manera que el servidor "actúe" de alguna manera en la solicitud, en virtud de que provenga específicamente del navegador de la víctima. En muchos sitios, el navegador de la víctima enviará un valor de cookie que fue enviado previamente por el sitio, y este valor de cookie encarna el autenticación. En resumen, los sitios de destino creen que la solicitud proviene de la víctima (y, técnicamente, lo hace) y representa la voluntad real de dicho usuario víctima (y que uno está completamente equivocado).

Es este valor de cookie el que evita que el atacante realice la solicitud por sí mismo; Dado que la cookie se almacena en el navegador de la víctima, la solicitud debe enviarse desde el navegador de la víctima, por lo tanto, el CSRF.

Los contenidos de la solicitud dependen completamente de la forma en que está diseñado el sitio de destino y de lo que el atacante intenta lograr. En el ejemplo de OWASP, la solicitud es para algún sitio bancario y los parámetros de solicitud codifican una transferencia de dinero, pero eso es meramente ilustrativo. Es concebible que un sitio específico pueda aceptar solicitudes que no incluyan un carácter '?' y que todavía tengan algún efecto que sea beneficioso para el atacante, en particular si el objetivo del atacante es la interrupción (por ejemplo, un enlace "eliminar mi cuenta": no parámetro, pero sigue siendo un efecto no despreciable).

    
respondido por el Tom Leek 21.08.2013 - 19:47
fuente

Lea otras preguntas en las etiquetas

¿Existen fallas obvias en este método de comunicación de receptor anónimo usando Twitter? ¿Existe una guía estándar sobre cómo debería aparecer la entrada desinfectada en el mensaje de error?