los puntales 1 Acción métodos de fichas de trabajo como el interceptor de tokens de Struts 2, ya que agregará un token a su sesión y lo comprobará al enviar el formulario, pero se trata de un proceso mucho más manual. El flujo de trabajo básico es:
- El usuario obtiene el formulario a través de una Acción Struts (no directamente al JSP). Struts Action llamará al
saveToken(request)
antes de reenviar al JSP que contiene el formulario.
- El formulario en el JSP debe usar la etiqueta
<html:form>
.
- Su acción a la que se envía el formulario primero llamará al
isTokenValid(request, true)
, y debe redireccionar a la primera Acción con un mensaje de error si devuelve false
. Esto también restablece el token para la próxima solicitud.
Hacer esto no solo evitará envíos de formularios duplicados, sino que cualquier script tendrá que golpear la primera Acción de Struts y obtener una sesión antes de poder enviarla a la segunda Acción de Struts para enviar el formulario. Como un sitio no puede establecer una sesión para otro sitio, esto debería evitar el CSRF.
Si normalmente envía usuarios directamente a su JSP, no lo haga. En su lugar, crear una nueva clase que hereda de ActionForward
y establecer esta ya que es execute()
método:
public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception {
saveToken(request);
return super.execute(mapping, form, request, response);
}
En lugar del proceso manual, sería uno no ser capaz de extender simplemente el ActionServlet e insertar la misma lógica en el 'proceso() 'método para verificar la validez del token? Tampoco entiendo el deseo de cambiar el token CSRF: eso suena como una receta para desastres ya que invalidará cualquier otra página abierta/formulario en el sitio. –