Cómo previene Tomcat la falsificación de solicitudes entre sitios
La falsificación de solicitudes entre sitios, también conocida como "Adjuntar con un clic" o "Session Riding", a menudo abreviada como CSRF, se realiza falsificando solicitudes de usuarios confiables. de aprovechar sitios web confiables. Explota sitios web confiables falsificando solicitudes de usuarios confiables.
Un ejemplo citado a menudo cuando se habla de CSRF es:
El usuario A visitó un banco en línea y realizó algunas acciones en el sitio web del banco.
Después, hizo clic en un enlace desconocido. El enlace dirige a una página web maliciosa proporcionada por el usuario B. La página también contiene enlaces para acceder a la misma información bancaria que el Usuario A, que podría ser para transferir dinero o cambiar una contraseña.
En este momento, si la información de verificación de identidad de A no ha caducado, se utilizará directamente para ayudar con éxito a W a realizar las operaciones correspondientes en el sitio web del banco, y todo esto se lleva a cabo sin el conocimiento de A a continuación.
Para evitar CSRF, los métodos comunes son:
Las solicitudes contienen información de token aleatoria
Las cookies contienen información de token csrf
Citar otras solicitudes de autenticación son de primera clase.
De forma predeterminada, Tomcat proporciona una buena herramienta para prevenir CSRF: el filtro de prevención CSRF.
Tomcat proporciona varios tipos de filtros de forma predeterminada para manejar diferentes escenarios y requisitos de aplicaciones. Por ejemplo, antes presentamos el propio conjunto de filtros de codificación de Tomcat, así como el procesamiento entre dominios y los problemas entre dominios de Tomcat, etc. El filtro de prevención CSRF presentado hoy también es uno de ellos.
Todo el flujo de trabajo del filtro se puede resumir de la siguiente manera:
Los filtros proporcionan protección CSRF básica para aplicaciones web. Su mapa de filtro corresponde a /*
y todos los enlaces que devuelven páginas se codifican llamando a la codificación HttpServletResponse # encodeRedirectURL(String) o HttpServletResponse # encodeURL(String). El mecanismo de implementación es generar un token y guardarlo en la sesión, la codificación URL usa el mismo token, cuando llega la solicitud, compara el token en la solicitud y el token en la sesión, solo si ambos son iguales Permitir la ejecución continuar.
Profundicemos en los detalles de implementación interna del código fuente a través de un ejemplo.
Aún puede utilizar la aplicación Manager de Tomcat para verlo.
En su web.xml, existe dicha configuración:
El siguiente es el método doFilter de CsrfPreventionFilter.
Notamos que la configuración anterior contiene un EntryPoints, en comparación con el código, se puede ver de un vistazo que esta configuración se usa para hacer algo similar a la función de exclusión, que es una asignación para omitir la verificación en la configuración.
Si no está en EntryPoints y existe en la sesión pero no contiene el Nonce correspondiente, se devolverá 403 (SC_FORBIDDEN) directamente.
Si la sesión no existe, se hará lo siguiente en doFilter:
Hacer esto como una solicitud inicial guardará las propiedades correspondientes en la sesión y las agregará a LruCache en el mismo tiempo medio. El punto aquí es utilizar la subclase CsrfResponseWrapper de HttpServletResponseWrapper para reemplazarla con la respuesta que se pasa a los procesos posteriores.
Por lo tanto, todas las llamadas posteriores a encodeUrl en realidad llaman a lo siguiente:
public String encodeURL(String url) {
return addNonce (super. encodeURL(url) );
}
addNonce corresponde a agregar una etiqueta csrf o nonce a la URL entrante para solicitudes posteriores.
La operación de codificación específica de la página utiliza la URL codificada de la respuesta, que es el addNonce que usamos anteriormente:
Corresponde a la aplicación Manager, cuya página se genera a través de Servlet, por lo que La lógica específica está en el archivo Java. Podemos observarla conectándonos a la página. En este momento, solicitar la URL para obtener la lista de aplicaciones queda así:
http://localhost:8080. /manager/html/list Cada solicitud que no está en EntryPoints se agrega con org.apache.catalina.filters.CSRF_NONCE= 6BC061DD606D7BA1BDEF7F40657F0C 47
Esta forma de salida de URL es el resultado de llamar a encodeURL en la página. Corresponde al código en el administrador y se ve así:
Lo anterior es el principio de implementación y los detalles del filtro de prevención CSRF, que es el principio de implementación y los detalles del filtro de prevención CSRF. Por supuesto, la posición de retorno 403 mencionada anteriormente y la generación de nonce se pueden configurar a través de los parámetros proporcionados por el filtro, que corresponden a denyStatus y randomClass respectivamente.