Estoy copestando una aplicación web que no usa un token anti-CSRF, pero usa parámetros cuyos nombres contienen dos puntos. Uno de los parámetros es, por ejemplo, _pt1:p1:1:pc1:pageToolbar:t_id_ .
Cuando hago la página de envío automático de HTML con un elemento de entrada como este:
<input type="hidden" name="pt1:p1:1:pc1:pageToolbar:t_id" value="1"/>
se enviará la URL codificada, por lo que no será correcta para la aplicación. ¿Significa esto que CSRF es imposible?
Hay tres tipos de contenido diferentes que puede permitir que se envíe un formulario (a menos que tenga un permiso especial de CORS):
application/x-www-form-urlencoded
multipart/form-data
text/plain
Has probado el primero y no funciona. Es poco probable que la segunda te ayude (es solo una forma de unir varios tipos de contenido cuando estás cargando archivos). Así que tu mejor apuesta sería la tercera. Pruebe un formulario que se vea así:
<form enctype="text/plain">
<input type="hidden" name="use:a:colon" value="This is an attack!">
<input type="submit">
</form>
Podrás enviar solicitudes sin tener codificados los dos puntos. Wheater realmente funciona o no, bueno, eso es otra historia. Es posible que el servidor no acepte este tipo de contenido o que haya otros obstáculos.
No, eso no significa que sea invulnerable a CSRF, solo que el enfoque que está tomando para probar CSRF es limitado.
Para las pruebas, puede usar un proxy como burp o Zed Attack Proxy para enviar los datos en bruto que desee. O puedes usar curl o un complemento de navegador como datos de manipulación.
Para un exploit, probablemente puedas hacer lo que necesites con JavaScript (aunque ha pasado un tiempo desde que jugué con estas cosas, así que necesitarás experimentar). O bien, realice una ingeniería inversa de la aplicación para averiguar cómo ella envía los datos al servidor y copie ese enfoque / código.
Lea otras preguntas en las etiquetas web-application csrf