Cita:
Iniciado por falotron 
Ando dándole vueltas a cómo proteger los formularios de mi web de los ataques mediante modificación de los mismos... realmente no sé si es lo que se conoce por ataques CSRF (Cross-Site Request Forgeries), intuyo que no, ya que las soluciones que he leído mediante tokens no me sirven en mi caso, o éso o es que me he perdido algo al aplicarlas
El problema...
Un usuario está logado en mi aplicación web, con su correspondiente variable de sesión llamémosla $_SESSION['user'], llega a una página con un formulario, saca el código fuente, copia el formulario, hace sus modificaciones, lo guarda y lo ejecuta...
Las soluciones propuestas en muchos sitios, por ejemplo...
http://shiflett.org/articles/cross-s...uest-forgeries
No me sirven, ya que en el código fuente queda reflejado el valor de $_SESSION['token']
Únicamente valdría si el atacante no está logado en mi aplicación web, pero supongo que si alguien quiere atacarme es porque está usando mi aplicación, está logado y por tanto en la página de recepción de datos del formulario la variable $_SESSION['token'] existe (se ha creado en la página del formulario) y coincide con $_POST['token']
¿Me estoy equivocando en mi razonamiento?
Si estoy en lo cierto, ¿Hay alguna manera de asegurarse realmente de que el usuario viene de mi formulario y no de uno modificado?
Gracias!
La prioridad en la seguridad de una web respecto a los formularios NO ESTA en el formulario en sí, sino en el tratamiento de las variables que se envían previo al proceso en sí.
Un ejemplo muy tonto:
-Tienes una web con un campo de lista en un formulario llamado CATEGORIA, y dicha lista tiene 10 valores, de 1 a 10. ¿tienes temor a que puedan copiarte el formulario y enviarte un 11? Pues que lo envien! tu luego en el php donde se recogen las variables haces las validaciones pertinentes para que dicho valor sea un valor entero entre 1 y 10 y listo
Otro detalle es usar la variable reservada: $_SERVER['HTTP_REFERER'] , para controlar desde que pagina llega el envio