Protection contre les attaques CSRF

Vous pouvez mettre en place une protection contre les attaques CSRF.

Procédure

Ouvrez le fichier web.xml.
Pour valider le jeton qui permet de se protéger contre des attaques CSRF, créez un valideur de demandes qui doit être enregistré dans l'application (si le valideur n'est pas déjà présent dans le fichier de web.xml).
Exemple :
```
<context-param>
  <param-name>scui-request-validator-10</param-name>
  <param-value>
com.sterlingcommerce.ui.web.platform.security.SCUICSRFTokenValidator
  </param-value>
</context-param>
```
Configurez les modes dans lesquels le valideur peut fonctionner :
- ALL - Les demandes POST et GET sont validées pour le jeton CSRF.
- POST (par défaut) - Les demandes GET ne sont pas validées pour le jeton CSRF. Les demandes POST/PUT/UPDATE/DELETE sont validées pour le jeton CSRF.
- NONE - Le valideur ne valide aucune demande pour le jeton CSRF.
Vous pouvez définir le mode du valideur dans le paramètre de contexte du fichier config.xml ou web.xml (si le mode du valideur ne figure pas encore dans le fichier web.xml).

Par défaut, le mode est POST si aucun mode n'est indiqué ou si aucun paramètre de contexte n'est précisé pour le mode de valideur. IBM® recommande d'utiliser le mode POST pour la validation des demandes.

Exemple :
```
<context-param>
   <param-name>scui-csrf-validator-request-method</param-name>
   <param-value>POST</param-value>
</context-param>
```
Remarques :
- Par défaut, la plupart des applications sont configurées pour n'utiliser que POST comme mode de valideur. Par conséquent, les demandes GET ne sont pas validées pour le jeton CSRF. Les demandes POST/PUT/UPDATE/DELETE sont validées pour le jeton CSRF.
- Les demandes GET ne sont pas protégées contre les attaques CSRF. Par conséquent, vous devez vous assurer que les appels d'action dynamique sensible n'utilisent pas ou n'autorisent pas les demandes GET. A la place, vous pouvez utiliser POST comme méthode de demande.
- Si vous souhaitez conserver la configuration ALL pour la méthode de valideur CSRF, il existe un risque d'exposition des jetons CSRF dans l'URL pour les demandes GET éventuellement consignées dans diverses couches intermittentes de serveurs proxy et dans d'autres couches réseau.
- Les informations sensibles des URL peuvent être consignées dans divers emplacements, y compris le navigateur de l'utilisateur, le serveur Web et tout serveur proxy direct ou inversé entre les deux noeuds finaux. Les URL peuvent également être affichées à l'écran, enregistrées comme signets ou envoyées par courrier électronique par les utilisateurs. Elles peuvent être divulguées à des tiers via l'en-tête référenceur lorsque des liens hors site sont suivis. Le placement de jetons de session et/ou de jetons CSRF dans l'URL augmente la vulnérabilité aux attaques.
- La façon sécurisée d'utiliser la validation CSRF est de la réserver aux demandes POST (ou aux demandes équivalentes telles que PUT/DEL/UPDATE). Évitez-la pour GET. En effet, le jeton CSRF ne doit pas passer dans une chaîne de requête d'URL, mais doit toujours être transmis en tant que paramètre POST. Si vous souhaitez activer la validation CSRF pour tous les types de demandes dont GET, dans web.xml, reconfigurez sur ALL le paramètre de mode de valideur CSRF. Toutefois, cette configuration est déconseillée car elle augmente le risque d'exposition du jeton CSRF dans l'URL et, par conséquent, dans les journaux, comme indiqué précédemment. Par conséquent, vous devez analyser de manière appropriée les risques encourus avant de changer cette configuration.
- Si scui-csrf-validator-request-method est défini sur "ALL", le jeton CSRF sera disponible dans les journaux.
Si nécessaire, configurez des listes d'inclusion et d'exclusion d'URI (Universal Resource Indicator) pour le valideur en respectant les règles suivantes :
- Si un indicateur URI (Universal Resource Indicator) figure dans la liste d'exclusion, il ne sera pas validé pour le jeton CSRF.
- Si une URI figure dans la liste d'inclusion mais pas dans la liste d'exclusion, elle sera validée pour le jeton CSRF.
Utilisez les paramètres de contexte suivants dans le fichier web.xml pour créer des listes d'inclusion et d'exclusion. Vous pouvez spécifier autant de paramètres que souhaité.
- csrf-include-uri
  Les demandes présentant un indicateur URI identique à la valeur sont validées pour le jeton CSRF.
  
  Exemple (pour 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
  Toute demande associée à un identificateur URI qui se termine par la valeur indiquée est validée pour le jeton CSRF.
  
  Exemple (pour 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
  Toute demande avec un identificateur URI qui correspond à l'expression régulière (fournie comme valeur pour le paramètre) est validée pour le jeton CSRF.
  
  Exemple (pour 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
  Toute demande avec un identificateur URI qui correspond à la valeur est ignorée et n'est pas contrôlée pour le jeton CSRF.
  
  Exemple (pour 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
  Les requêtes présentant un indicateur URI finissant par la valeur sont ignorées.
  
  Exemple (pour 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
  Toute demande avec un identificateur URI qui correspond à l'expression régulière (fournie comme valeur pour le paramètre) n'est pas contrôlée pour le jeton CSRF.
  
  Exemple (pour 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>
```
Par défaut, tous les identificateurs URI figurent dans la liste d'inclusion, même si le paramètre csrf-include n'est pas fourni. Vous devez explicitement spécifier qu'un indicateur URI figure dans la liste d'exclusion. Si aucune liste d'inclusion n'est fournie, par défaut tous les identificateurs URI sont considérés comme figurant dans la liste d'inclusion. L'application peut ajouter des identificateurs URI spécifiques à une liste d'inclusion pour éviter que tous les identificateurs URI ne soient validés pour le jeton CSRF.

Par défaut, la structure fournit une liste d'exclusion pour ignorer la validation CSRF pour des demandes destinées à des fichiers de type gif, png, css ou js.
La plupart des attaques CSRF fonctionnent simplement en répliquant des demandes POST sous la forme de demandes GET équivalentes. Comme la plupart des applications ne font pas de distinction entre des demandes POST et GET, ces attaques fonctionnent généralement bien. Pour établir une distinction entre des demandes GET et POST, configurez les modes dans lesquels le valideur peut fonctionner dans les définitions d'action Struts en utilisant le paramètre requestMethodSupported de l'action :
- POST - (par défaut) Seules les demandes POST sont autorisées.
  Si requestMethodSupported n'est pas défini ou est associé à une valeur inconnue, la valeur par défaut est POST.
- ALL - Les demandes GET et POST sont autorisées.
Exemple :
```
<action name="accountTransfer" class="com.AccountTransfer">
  <param name="requestMethodSupported">POST</param>
  <param name="resourceId">AccountTransfer_Action002</param>
</action> 
```
Par défaut, dans l'application, la plupart des actions sont configurées pour autoriser uniquement les demandes POST (pas les demandes GET). Certaines actions telles que la connexion, la déconnexion, l'affichage de la page À propos et des pages d'arrivée sont configurées pour autoriser les demandes GET. Cependant, ces actions ne sont pas sensibles et n'exécutent aucune opération de modification/suppression/mise à jour en arrière plan, en tant qu'élément de la demande. Par conséquent, elles ne sont pas vulnérables aux attaques CSRF.
Si vous souhaitez personnaliser un écran configuré pour autoriser les demandes GET, assurez-vous qu'il n'existe aucune opération de modification/suppression/mise à jour en arrière-plan dans une application composite, une API, un exit utilisateur, un service ou dans les couches ultérieures. Sinon, les actions sont vulnérables aux attaques CSRF.