Cours de sécurité accéléré no. 3 - XSS

Cet article a été écrit par Damien Metzger, et publié sur le blog de PrestaShop le 26 septembre 2011.

Ce serait une erreur de croire qu'il faut un accès au code d'un site Internet pour le pirater. En effet, même au niveau de l'affichage HTML, il est nécessaire de bien protéger toutes les données qui apparaissent.

Une faille XSS consiste à exploiter l'interprétation HTML / JavaScript par le navigateur lors l'affichage des données. Si vous affichez dans la page une donnée non protégée – c'est-à-dire sans prendre le soin de convertir les caractères qui sont interprétés-, alors le navigateur pourra interpréter les variables affichées comme du HTML ou du JavaScript.

<script type="text/javascript">alert('kikoo');</script>

On peut bien évidemment faire bien plus en JavaScript qu'un message d'alerte : redirection vers un autre site, vol de cookies...

Comment s'en protéger ?

Ce n'est pas très compliqué : tout ce qui apparaît dans vos pages HTML doit être protégé avec une fonction comme htmlspecialchars() ou htmlentities(). Selon les cas, vous pourrez également être amené à utiliser des fonctions complémentaires telles que strip_tags() qui enlève toutes les balises HTML d'une chaine de caractères, ou encore un simple addslashes() si vous faites du JavaScript.

La vraie difficulté n'est donc pas de se protéger, mais plutôt de ne pas en oublier. Les raisons principales d'un oubli sont :

• La quantité de variables impliquées. Il y a tout simplement énormément de variables affichées aux utilisateurs, et il en suffit d'une « bien placée » pour permettre d'exploiter une faille XSS.
  Dans le même esprit, il faut bien penser, à la conception du site Internet, à quel moment vous allez protéger ces variables. Directement dans le modèle pour que ce soit déjà fait ? C'est peu performant et inefficace. Dans les contrôleurs ? Facile d'en oublier. Dans la vue ? Si on considère que la sécurité est un travail d'intégrateur alors peut-être. Et bien évidemment, il est hors de question de le faire à plusieurs niveaux, car on ne peut pas cumuler ces fonctions de protection, sous peine d'avoir un résultat illisible. Il n'y a pas de réponse miracle à cette question : un contrôle systématique doit être fait sur chaque page, car tout le monde est impliqué.

• Le type de variables impliquées. Les XSS ne concernent pas exclusivement les données POST ou GET ! Il est par exemple très facile de se forger un referrer pour exploiter un bouton « précédent » mal protégé. Vos données en base ne sont peut-être pas aussi sécurisées que vous le croyez, que ce soit volontairement après une attaque ou involontairement en utilisant des caractères interprétés (ce ne sera pas alors une XSS, mais l'affichage sera cassé).

Bref : aucune donnée ne doit être épargnée, car il n'y a pas de donnée complètement fiable.