¿Estoy bajo riesgo de ataques CSRF en una forma POST que no requiera que el usuario inicie sesión?

Question

Probablemente soy un novato total aquí, pero aún no estoy seguro de qué es exactamente un ataque CSRF (Cross-Site Request Forgery). Así que veamos tres situaciones ...

1) Tengo un formulario POST que utilizo para editar datos en mi sitio. Quiero que estos datos se va a editar Sólo los usuarios que han iniciado sesión.

2) Tengo un sitio, que puede ser utilizado tanto por usuarios que han iniciado sesión, así como invitados. Algunas partes del sitio son solo para usuarios que inician sesión, pero también hay formularios POST que pueden ser utilizados por todos los usuarios, anónimos y no (por ejemplo, un formulario de contacto estándar). ¿Debería salvaguardarse el formulario de contacto contra los ataques de CSRF?

3) Tengo un sitio que no tiene ningún sistema de autenticación (bueno, quizás eso no sea realista, así que digamos que tiene un sitio de administración que está separado del resto y la parte de administración está salvaguardada adecuadamente) La parte principal del sitio solo la utilizan usuarios anónimos. ¿Deben salvaguardarse los formularios POST?

En el caso de 1) la respuesta es claramente sí. Pero en el caso de 2 y 3 no lo sé (¿y la diferencia entre 2 y 3 es incluso significativa?).

Answer 1

Hay medios de CSRF siempre HTML o JavaScript malicioso que se apunta en su sitio web se han incrustado en otra página HTML (o un mensaje de correo electrónico) que se ha ejecutado correctamente.

Un ejemplo es el siguiente, que se ha colocado en otra página web que pregunta inocentemente para su nombre y edad antes de proceder:

<form action="http://yoursite.com/transferfunds" method="post"> 
    Your name: <input type="text"><br> 
    Your age: <input type="text"><br> 
    <input type="submit"> 
    <input type="hidden" name="amount" value="1000"> 
    <input type="hidden" name="toaccount" value="12345678"> 
</form> 

Tenga en cuenta que los puntos de acción a su sitio web y que los insumos oculta contiene la necesitan Información de POST Este ejemplo intentará transferir un fondo de 1000 (en cualquier moneda) al número de cuenta 12345678. Si requiere un inicio de sesión en su formulario y también lo comprueba, entonces lo anterior solo se ejecutará con éxito si el usuario no conoce inició sesión recientemente en su sitio web, pero aún no se ha desconectado, o la sesión aún no ha caducado.

Para evitar que esto suceda, su mejor opción es agregar un token basado en solicitud al formulario y validarlo en el lado del servidor. Es decir. genere una cadena aleatoria larga, única e imposible de adivinar que almacene en la sesión e incruste como elemento <input type="hidden"> del formulario. Cuando se envía el formulario, compare el valor del token enviado con el que ya está en sesión (y elimine inmediatamente el que está en sesión). Para ir un paso más allá, haga uso de CAPTCHA.

En su caso particular, creo que en realidad estás más preocupaciones acerca de XSS, que es un opuesto de CSRF, pero que a su vez también puede ser una fuente para CSRF. Un ejemplo de XSS es cuando el usuario introduce lo siguiente en un campo de entrada que se va vuelvan a mostrarse más pronto o más tarde en el mismo sitio web:

<form name="delete" action="admin/deleteusers" method="post"></form> 
<script>document.form.delete.submit();</script> 

Siempre que -como ser el administrador- vistas a la página con el comentario con la forma (y el guión) (¡invisible!) dentro, se ejecutará con éxito.

La prevención de XSS es realmente bastante fácil. Solo HTML-escape cualquier entrada controlada por el usuario (es decir, URL de solicitud, encabezados de solicitud, parámetros de solicitud y cuerpo de solicitud) antes de mostrarlos en la página web.En PHP puede utilizar htmlspecialchars() para esto y en Java/JSP JSTL fn:escapeXml(). De esta manera en cada una de la < se convertirá en < y > a > lo que hará que cualquier HTML entraron/JS se mostrará literalmente tal cual y por lo tanto no puede ser ejecutado.