Meilleures Pratiques Java pour empêcher le Script Intersite [fermé]
J'ai parcouru les dix principales vulnérabilités d'OWASP et j'ai constaté que le script intersite est celui que nous devons prendre des notes. Il y avait peu de solutions recommandées. On a déclaré que ne pas utiliser la validation "liste noire" pour détecter XSS en entrée ou pour coder la sortie. Rechercher et remplacer seulement quelques caractères (< et > et d'autres caractères ou phrases similaires tels que script) est faible et a été attaqué avec succès. Même une balise “<b>” non cochée est dangereuse dans certains contextes. XSS a un nombre surprenant de variantes qui facilitent le contournement de la validation de la liste noire. Une autre solution a dit que l'encodage de sortie forte. Assurez-vous que toutes les données fournies par l'utilisateur sont encodées de manière appropriée (HTML ou XML selon le mécanisme de sortie) avant le rendu. Alors, quel est le meilleur moyen d'empêcher les scripts intersite pour valider et remplacer l'entrée ou encoder la sortie ?
3 answers
La pratique normale consiste à HTML-échapper toute données contrôlées par l'utilisateur pendant redisplayingdans JSP, pas pendant traitementles données soumises dans servlet ni pendant stockage dans DB. Dans JSP, vous pouvez utiliser le JSTL (pour l'installer, il suffit de déposer jstl-1.2.jar dans /WEB-INF/lib) <c:out> tag ou fn:escapeXml la fonction de ce. Par exemple
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
...
<p>Welcome <c:out value="${user.name}" /></p>
Et
<%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
...
<input name="username" value="${fn:escapeXml(param.username)}">
C'est tout. Pas besoin de liste noire. Notez que contrôlé par l'utilisateur les données couvrent tout ce qui arrive par une requête HTTP: les paramètres de la requête, le corps et les en-têtes(!!).
Si vous l'échappez HTML pendant le traitement des données soumises et/ou le stockage dans la base de données, tout est réparti sur le code métier et/ou dans la base de données. Ce n'est que des problèmes de maintenance et vous risquerez des doubles échappements ou plus lorsque vous le ferez à différents endroits (par exemple, {[5] } deviendrait &amp; au lieu de & de sorte que l'utilisateur final verrait littéralement & au lieu de & en vue. Le code métier et la base de données ne sont à leur tour pas sensibles pour XSS. Seule la vue est. Vous ne devriez alors y échapper que juste là en vue.
Voir aussi:
Utilisez les deux. En fait, référez-vous à un guide comme le OWASP XSS Prevention cheat sheet, sur les cas possibles d'utilisation de l'encodage de sortie et de la validation d'entrée.
La validation d'entrée aide lorsque vous ne pouvez pas compter sur l'encodage de sortie dans certains cas. Par exemple, il est préférable de valider les ENTRÉES apparaissant dans les URL plutôt que d'encoder les URL elles-mêmes (Apache ne servira pas d'URL codée par URL). Ou d'ailleurs, validez les entrées qui apparaissent en JavaScript expression.
En fin de compte, une règle simple vous aidera - si vous ne faites pas suffisamment confiance aux entrées utilisateur ou si vous pensez que certaines sources peuvent entraîner des attaques XSS malgré l'encodage de sortie, validez-la par rapport à une liste blanche.
Jetez un œil au code sourceOWASP ESAPI sur la façon dont les encodeurs de sortie et les validateurs d'entrée sont écrits dans une bibliothèque de sécurité.
Ma préférence est d'encoder tous les caractères non alphaumériques en tant qu'entités de caractères numériques HTML. Étant donné que presque, sinon toutes les attaques nécessitent des caractères non alphunériques (comme
Le format est & # N;, où N est la valeur numérique du caractère (vous pouvez simplement convertir le caractère en int et le concaténer avec une chaîne pour obtenir une valeur décimale). Par exemple:
// java-ish pseudocode
StringBuffer safestrbuf = new StringBuffer(string.length()*4);
foreach(char c : string.split() ){
if( Character.isAlphaNumeric(c) ) safestrbuf.append(c);
else safestrbuf.append(""+(int)symbol);
Vous devrez également être sûr que vous encodez immédiatement avant de sortir vers le navigateur, pour éviter le double encodage, ou l'encodage pour HTML mais l'envoi à un emplacement différent.