Publication croisée en tant que référence consolidée à partir de la version bêta de la documentation SO qui est mise hors ligne.
Problème
Les scripts intersites sont l'exécution involontaire de code à distance par un client Web. Toute application Web peut s'exposer à XSS si elle prend l'entrée d'un utilisateur et la renvoie directement sur une page Web. Si la saisie inclut HTML ou JavaScript, le code à distance peut être exécuté lorsque ce contenu est rendu par le client Web.
Par exemple, si un côté tiers contient un fichier JavaScript:
// http://example.com/runme.js
document.write("I'm running");
Et une application PHP génère directement une chaîne qui lui est passée:
<?php
echo '<div>' . $_GET['input'] . '</div>';
Si un paramètre GET non contrôlé contient <script src="http://example.com/runme.js"></script>alors la sortie du script PHP sera:
<div><script src="http://example.com/runme.js"></script></div>
Le JavaScript tiers s'exécutera et l'utilisateur verra "Je cours" sur la page Web.
Solution
En règle générale, ne faites jamais confiance aux entrées provenant d'un client. Chaque valeur GET, POST et cookie peut être n'importe quoi et doit donc être validée. Lors de la sortie de l'une de ces valeurs, échappez-les afin qu'elles ne soient pas évaluées de manière inattendue.
Gardez à l'esprit que même dans les applications les plus simples, les données peuvent être déplacées et il sera difficile de garder une trace de toutes les sources. Par conséquent, il est recommandé de toujours échapper la sortie.
PHP fournit plusieurs façons d'échapper à la sortie en fonction du contexte.
Fonctions de filtrage
Phps Fonctions Filter permettent les données d'entrée du script php pour être désinfecté ou validé à bien des égards . Ils sont utiles lors de l'enregistrement ou de la sortie des entrées client.
Encodage HTML
htmlspecialcharsconvertira tous les "caractères spéciaux HTML" en leurs encodages HTML, ce qui signifie qu'ils ne seront alors pas traités comme du HTML standard. Pour corriger notre exemple précédent en utilisant cette méthode:
<?php
echo '<div>' . htmlspecialchars($_GET['input']) . '</div>';
// or
echo '<div>' . filter_input(INPUT_GET, 'input', FILTER_SANITIZE_SPECIAL_CHARS) . '</div>';
Produirait:
<div><script src="http://example.com/runme.js"></script></div>
Tout ce qui se trouve à l'intérieur de la <div>balise ne sera pas interprété comme une balise JavaScript par le navigateur, mais plutôt comme un simple nœud de texte. L'utilisateur verra en toute sécurité:
<script src="http://example.com/runme.js"></script>
Encodage d'URL
Lors de la sortie d'une URL générée dynamiquement, PHP fournit la urlencodefonction pour sortir en toute sécurité des URL valides. Ainsi, par exemple, si un utilisateur est capable de saisir des données qui font partie d'un autre paramètre GET:
<?php
$input = urlencode($_GET['input']);
// or
$input = filter_input(INPUT_GET, 'input', FILTER_SANITIZE_URL);
echo '<a href="http://example.com/page?input="' . $input . '">Link</a>';
Toute entrée malveillante sera convertie en un paramètre d'URL codé.
Utilisation de bibliothèques externes spécialisées ou de listes OWASP AntiSamy
Parfois, vous souhaiterez envoyer du HTML ou d'autres types d'entrées de code. Vous devrez maintenir une liste de mots autorisés (liste blanche) et non autorisés (liste noire).
Vous pouvez télécharger les listes standard disponibles sur le site Web OWASP AntiSamy . Chaque liste est adaptée à un type spécifique d'interaction (ebay api, tinyMCE, etc ...). Et c'est open source.
Il existe des bibliothèques pour filtrer le HTML et empêcher les attaques XSS pour le cas général et effectuer au moins ainsi que les listes AntiSamy avec une utilisation très facile. Par exemple, vous avez HTML Purifier