Comment prévenir les XSS avec HTML/PHP ?

Question

Comment éviter les XSS (cross-site scripting) en utilisant uniquement HTML et PHP ?

J'ai vu de nombreux autres articles sur ce sujet, mais je n'en ai pas trouvé un qui explique de manière claire et concise comment prévenir les XSS.

Answer 1

En gros, vous devez utiliser la fonction htmlspecialchars() lorsque vous voulez envoyer au navigateur quelque chose qui provient de l'entrée de l'utilisateur.

La manière correcte d'utiliser cette fonction est la suivante :

echo htmlspecialchars($string, ENT_QUOTES, 'UTF-8');

L'université du code Google propose également des vidéos très instructives sur la sécurité du Web :

• Comment casser un logiciel Web - Un regard sur les vulnérabilités de sécurité dans les logiciels web

• Ce que chaque ingénieur doit savoir sur la sécurité et où l'apprendre

Answer 2

Un de mes préférés OWASP Les références sont les suivantes Cross-Site Scripting explication car s'il existe un grand nombre de vecteurs d'attaque XSS, le respect de quelques règles permet de se défendre grandement contre la majorité d'entre eux !

C'est Aide-mémoire sur la sécurité en PHP

Answer 3

L'une des étapes les plus importantes consiste à assainir toute entrée utilisateur avant qu'elle ne soit traitée et/ou rendue au navigateur. PHP dispose de quelques " filtre "Les fonctions qui peuvent être utilisées.

La forme que prennent généralement les attaques XSS consiste à insérer un lien vers un javascript hors site qui contient des intentions malveillantes pour l'utilisateur. Pour en savoir plus aquí .

Vous voudrez également tester votre site Je peux recommander le module complémentaire Firefox [XSS Me]. . On dirait que XSS facile est maintenant la voie à suivre.

Answer 4

Publication croisée de ce document en tant que référence consolidée de la version bêta de la documentation de l'OS, qui est mise hors ligne.

Problème

Le cross-site scripting est l'exécution involontaire de code à distance par un client web. Toute application web peut s'exposer au XSS si elle prend en compte les données d'un utilisateur et les affiche directement sur une page web. Si l'entrée comprend du HTML ou du JavaScript, du code distant 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 produit directement une chaîne de caractères qui lui est passée :

<?php
echo '<div>' . $_GET['input'] . '</div>';

Si un paramètre GET non coché 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 suis en train de fonctionner" sur la page Web.

Solution

En règle générale, ne faites jamais confiance aux données provenant d'un client. Chaque paramètre GET, contenu POST ou PUT et valeur de cookie peut être n'importe quoi et doit donc être validé. Lorsque vous produisez l'une de ces valeurs, échappez-la afin qu'elle ne soit pas évaluée de manière inattendue.

N'oubliez pas que même dans les applications les plus simples, les données peuvent être déplacées et qu'il sera difficile de garder la trace de toutes les sources. C'est pourquoi il est préférable de toujours sortie de secours.

PHP fournit plusieurs façons d'échapper à la sortie, selon le contexte.

Fonctions de filtrage

Fonctions de filtrage de PHPs permettre aux données d'entrée du script de php d'être aseptisé o validé en de nombreuses façons . Ils sont utiles lors de la sauvegarde ou de l'édition des données du client.

Encodage HTML

htmlspecialchars convertira tous les "caractères spéciaux HTML" dans leur encodage HTML, ce qui signifie qu'ils seront alors no être traitées 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>';

La sortie se ferait :

<div>&lt;script src=&quot;http://example.com/runme.js&quot;&gt;&lt;/script&gt;</div>

Tout ce qui se trouve à l'intérieur de la <div> L'étiquette sera no être 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>

Codage de l'URL

Lors de l'affichage d'une URL générée dynamiquement, PHP fournit la fonction urlencode pour afficher en toute sécurité des URL valides. Ainsi, par exemple, si un utilisateur est en mesure 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 URL codé.

Utilisation de bibliothèques externes spécialisées ou de listes OWASP AntiSamy

Parfois, vous voudrez envoyer des entrées HTML ou d'autres types de code. Vous devrez tenir à jour une liste de mots autorisés (liste blanche) et non autorisés (liste noire).

Vous pouvez télécharger les listes standard disponibles à l Site web de l'OWASP AntiSamy . Chaque liste est adaptée à un type d'interaction spécifique (api ebay, tinyMCE, etc...). Et c'est une source ouverte.

Il existe des bibliothèques pour filtrer le HTML et prévenir les attaques XSS pour le cas général et qui sont au moins aussi performantes que les listes AntiSamy avec une utilisation très facile. Par exemple, vous avez Purificateur HTML

Answer 5

De nombreux frameworks permettent de gérer les XSS de différentes manières. Si vous développez votre propre framework ou si vous avez des inquiétudes concernant le XSS, vous pouvez vous appuyer sur tableau de filtres d'entrée (disponible en PHP 5 >= 5.2.0, PHP 7.) En général, j'ajoute cet extrait à mon SessionController, car tous les appels passent par là avant que tout autre contrôleur n'interagisse avec les données. De cette manière, toutes les entrées de l'utilisateur sont nettoyées à un endroit central. Si cette opération est effectuée au début d'un projet ou avant que votre base de données ne soit empoisonnée, vous ne devriez pas avoir de problèmes au moment de la sortie... il n'y a plus de déchets à l'entrée, plus de déchets à la sortie.

/* Prevent XSS input */
$_GET   = filter_input_array(INPUT_GET, FILTER_SANITIZE_STRING);
$_POST  = filter_input_array(INPUT_POST, FILTER_SANITIZE_STRING);
/* I prefer not to use $_REQUEST...but for those who do: */
$_REQUEST = (array)$_POST + (array)$_GET + (array)$_REQUEST;

Ce qui précède supprimera TOUTES Balises HTML et script. Si vous avez besoin d'une solution qui autorise les balises sûres, sur la base d'une liste blanche, consultez le site suivant Purificateur HTML .

---

Si votre base de données est déjà empoisonnée ou si vous voulez traiter les XSS au moment de la sortie, OWASP recommande de créer une fonction d'enveloppe personnalisée pour echo et l'utiliser PARTOUT où vous produisez des valeurs fournies par l'utilisateur :

//xss mitigation functions
function xssafe($data,$encoding='UTF-8')
{
   return htmlspecialchars($data,ENT_QUOTES | ENT_HTML401,$encoding);
}
function xecho($data)
{
   echo xssafe($data);
}