Protección contra ataques CSRF

Puede protegerse contra los ataques CSRF.

Procedimiento

Abra el archivo web.xml.
Para validar la señal (token) que se utiliza como protección contra ataques CSRF, cree un validador de solicitud que se registrará en la aplicación (si el validador no está ya presente en el archivo web.xml).
Ejemplo:
```
<context-param>
  <param-name>scui-request-validator-10</param-name>
  <param-value>
com.sterlingcommerce.ui.web.platform.security.SCUICSRFTokenValidator
  </param-value>
</context-param>
```
Configure las modalidades en las que puede operar el validador:
- ALL: las solicitudes POST y GET serán validadas para la señal CSRF.
- POST (valor predeterminado): Las solicitudes GET no se validan para la señal CSRF. Las solicitudes POST/PUT/UPDATE/DELETE se validan para la señal CSRF.
- NONE: el validador no validará ninguna solicitud para la señal CSRF.
Puede especificar la modalidad del validador en el parámetro de contexto del archivo config.xml o del archivo web.xml (si la modalidad del validador no está ya presente en el archivo web.xml).

La modalidad toma el valor predeterminado POST si no se ha especificado ninguna modalidad o si el parámetro de contexto no se ha especificado para la modalidad de validación. IBM® recomienda utilizar la modalidad POST para validar solicitudes.

Ejemplo:
```
<context-param>
   <param-name>scui-csrf-validator-request-method</param-name>
   <param-value>POST</param-value>
</context-param>
```
Notas:
- De forma predeterminada, la mayoría de las aplicaciones están configuradas para utilizar únicamente POST como modalidad del validador. Por consiguiente, las solicitudes GET no se validan para la señal CSRF. Las solicitudes POST/PUT/UPDATE/DELETE se validan para la señal CSRF.
- Las solicitudes GET no están protegidas mediante CSRF. Por consiguiente, asegúrese de que las llamadas de acciones dinámicas sensibles no utilicen o permitan solicitudes GET. En su lugar, puede utilizar POST como método de solicitud.
- Si desea conservar la configuración del método de validador CSRF como ALL, existe un riesgo de exponer las señales CSRF en el URL para solicitudes GET lo cual puede registrarse en diversas capas intermitentes de servidores proxy y otras capas de red.
- La información confidencial en los URL se puede registrar en diversas ubicaciones, que incluyen el navegador del usuario, el servidor web y cualquier servidor proxy de reenvío o inverso entre los dos puntos finales. Los URL también se pueden visualizar en la pantalla, marcarse como favoritos o enviarse por correo electrónico por parte de los usuarios. Se pueden revelar a terceros a través de la cabecera del referenciador cuando se siguen enlaces fuera del sitio. Colocar señales CSRF y/o sesiones en el URL incrementa la vulnerabilidad a los ataques.
- La forma segura de utilizar la validación CSRF es utilizarla sólo para solicitudes POST (o una solicitud equivalente como PUT/DEL/UPDATE, etc.) y no para GET para que la señal CSRF siempre se pase como un parámetro POST y no en una serie de consulta de URL. Si desea habilitar la validación CSRF para TODOS los tipos de solicitudes, incluido GET, puede habilitarla cambiando el parámetro de modalidad de validador CSRF en web.xml por ALL. No obstante, no es aconsejable puesto que aumenta el riesgo de exponer la señal CSRF en el URL y, por consiguiente, en registros tal como se ha mencionado anteriormente. Por lo tanto, necesita analizar de forma adecuada los riesgos en juego antes de cambiar esta configuración.
- Si scui-csrf-validator-request-method se establece en "ALL", la señal CSRF estará disponible en registros.
Si es necesario, configure listas de inclusión y exclusión de URI (indicador de recursos universal) para el validador; para ello, siga estas directrices:
- Si un URI está en la lista de exclusión, no se validará para la señal CSRF.
- Si un URI está en la lista de inclusión y no en la de exclusión, se validará para la señal CSRF.
Utilice los siguientes parámetros de contexto del archivo web.xml para crear listas de inclusión y exclusión. Se puede proporcionar cualquier número de parámetros.
- csrf-include-uri
  Cualquier solicitud con un URI que sea igual que el valor se valida para la señal CSRF.
  
  Ejemplo (para web.xml):
```
<context-param>
   <param-name>csrf.include.uri.endswith.stk.1</param-name>
   <param-value>.do</param-value>
</context-param>
```
- csrf-include-uri-endswith
  Cualquier solicitud con un URI que finaliza con el valor se valida para la señal CSRF.
  
  Ejemplo (para web.xml):
```
<context-param>
  <param-name>csrf.include.uri.endswith.stk.2</param-name>
  <param-value>.xml</param-value>
</context-param>
```
- csrf-include-uri-regex
  Cualquier solicitud con un URI que coincida con regex (proporcionado como valor para el parámetro) se valida para la señal CSRF.
  
  Ejemplo (para web.xml):
```
<context-param>
  <param-name>csrf.include.uri.stk.1</param-name>
  <param-value>/stk/home.jsp</param-value>
</context-param>
```
- csrf-bypass-uri
  Cualquier solicitud con un URI que coincida con el valor se pasa por alto y no se comprueba para la señal CSRF.
  
  Ejemplo (para web.xml):
```
<context-param>
  <param-name>csrf.bypass.uri.stk.1</param-name>
  <param-value>/console/login.jsp</param-value>
</context-param>
```
- csrf-bypass-uri-endswith
  Cualquier solicitud con un URI que finaliza con el valor se pasa por alto.
  
  Ejemplo (para web.xml):
```
<context-param>
   <param-name>csrf.bypass.uri.endswith.stk.1</param-name>
   <param-value>.js</param-value>
</context-param>
```
- csrf-bypass-uri-regex
  Una solicitud con un URI que coincida con regex (proporcionado como valor para el parámetro) no se comprueba para la señal CSRF.
  
  Ejemplo (para web.xml):
```
<context-param>
   <param-name>csrf.bypass.uri.regex.stk.1</param-name>
   <param-value>[a-zA-Z0-0]*servlet/param-value> 
</context-param>
```
De manera predeterminada, todos los URI están en la lista de inclusión, incluso si no se proporciona un parámetro csrf-include. Debe especificar explícitamente que un URI está en la lista de exclusión. Si no se proporciona ninguna lista de inclusión, de forma predeterminada todos los URI se consideran que están en la lista de inclusión. La aplicación puede añadir URI específicos a una lista de inclusión para impedir que se validen todos los URI para la señal CSRF.

De forma predeterminada, la infraestructura ofrece una lista de exclusión para pasar por alto la validación CSRF para solicitudes de archivos de tipo gif, png, css o js.
La mayoría de los ataques CSRF replican las solicitudes POST y las convierten en sus GET equivalentes. Puesto que la mayoría de las aplicaciones no distingue entre las solicitudes POST y GET, los ataques normalmente funcionan. Para distinguir las solicitudes GET de las solicitudes POST, en las definiciones de acciones de Struts, configure las modalidades en las que puede funcionar el validador, utilizando el parámetro requestMethodSupported de la acción:
- POST: (valor predeterminado) sólo se permiten solicitudes POST.
  Si no se ha establecido requestMethodSupported o es un valor desconocido, toma el valor predeterminado de POST.
- ALL: se permiten las solicitudes GET y POST.
Ejemplo:
```
<action name="accountTransfer" class="com.AccountTransfer">
  <param name="requestMethodSupported">POST</param>
  <param name="resourceId">AccountTransfer_Action002</param>
</action> 
```
De forma predeterminada, la mayoría de las acciones en la aplicación están configuradas para permitir únicamente solicitudes POST y no GET. Algunas acciones tales como inicio de sesión, cierre de sesión, visualización de la página Acerca de y de las páginas de destino están configuradas para permitir también solicitudes GET. No obstante, estas acciones no son sensibles y no realizan ninguna operación de modificar/suprimir/actualizar en el programa de fondo, como parte de la solicitud. Por lo tanto, no son vulnerables a CSRF.
Si desea personalizar alguna de las pantallas que se han configurado para permitir solicitudes GET, debería asegurarse de que no haya ninguna operación de modificar/suprimir/actualizar en el programa de fondo en mashup, API, salida de usuario o servicio o cualquier capa posterior. De lo contrario, las acciones son vulnerables a CSRF.