Scripts intersites dans WordPress Conseils pratiques pour sécuriser votre site

Dans cette série, nous examinons comment sécuriser nos projets WordPress à partir de XSS - ou script intersite. Dans le premier article de la série, nous avons défini le scripting intersite, compris son fonctionnement et expliqué pourquoi il est dangereux..

Nous avons également passé un certain temps à discuter de l’impact de ces modifications sur nos efforts de développement WordPress quotidiens et de ce que nous pouvons faire à ce sujet. Bien que WordPress dispose de certaines fonctions pour aider à valider et à nettoyer les données, nous pouvons effectuer davantage de travaux pour sécuriser nos projets..

Dans cet article final, nous allons examiner quelques conseils pratiques que nous pouvons suivre et quelques tests que nous pouvons administrer pour sécuriser notre travail contre les attaques XSS..


Les bases du test XSS

En règle générale, pour tester votre site afin de détecter les vulnérabilités de script intersite, vous devez rechercher n'importe où dans le site ou l'application qui accepte les entrées de l'utilisateur..

Évidemment, cela se présentera sous la forme de champs de saisie, textareas, etc..

Si le site ne procède pas à la désinfection et / ou à la validation, vous réussirez normalement à trouver des exploits; cependant, si le site est gérer correctement les données entrantes, vous ne verrez probablement aucun résultat pour vos efforts.

Examinons plusieurs cas que nous pouvons administrer sur nos propres sites (ou même d’autres, bien que cette à vos risques et périls!).

1. Localisation d'une vulnérabilité de script intersite

Une des premières choses que nous pouvons faire pour localiser une vulnérabilité est d’injecter du code qui déterminera l’existence ou non d’une vulnérabilité..

Le code en question est le suivant:

 '; alert (String.fromCharCode (88,83,83)) //'; alert (String.fromCharCode (88,83,83)) // "; alert (String.fromCharCode (88,83,83)) / /";alert(String.fromCharCode(88,83,83))//-->"> '>

Placez ce code dans n'importe quel champ de saisie et soumettez-le..

Si une vulnérabilité Est-ce que existe, le mot "XSS" sera affiché. Si ce n'est pas retourné, alors vous êtes probablement en sécurité (bien que cela ne puisse pas être garanti à 100%); cependant, si elle est générée, cela signifie probablement qu'il existe une vulnérabilité que vous (ou une personne plus malveillante) pouvez exploiter..

2. Tentative de cross-site

Dans le dernier article, nous avons discuté de la politique de même origine, qui stipule qu'un site ne doit pas pouvoir demander des actifs à partir d'un domaine autre que celui sur lequel il réside actuellement..

Pour tenter d’exécuter du code à partir d’un serveur distant - ou d’un serveur ne pas partie de la même origine - vous pouvez exécuter le code suivant:

 “>

Notez que le préfixe du cas de test est ne pas une faute de frappe. C'est nécessaire pour tester réellement la vulnérabilité. Si une vulnérabilité existe réellement, puis un cookie de navigateur du domaine distant sera affiché; sinon, vous ne verrez rien ou votre console peut renvoyer un message concernant la règle de même origine..

Des accessoires à Janne pour cette tactique particulière.

3. Attributs d'image

Enfin, l’une des vulnérabilités les plus connues consiste à exécuter du code JavaScript dans un attribut de type 'imgtag.

Par exemple, créer un élément tel que:

 

Révélerait une vulnérabilité qui afficherait une boîte de dialogue d'alerte avec le message 'XSS' plutôt qu'une image brisée.

Simple, n'est ce pas? Néanmoins, il ne faut qu'une vulnérabilité pour exposer un exploit.


Autres ressources

Un wiki d'attaques

La chose est, c'est juste la pointe de l'iceberg en ce qui concerne les tests XSS. En fait, il faudrait tout un wiki pour aider à documenter les diverses vulnérabilités existantes.

En fait, c’est exactement ce que le Open Web Application Security Ce projet a pour objectif de: documenter les différentes vulnérabilités XSS existantes et comment les tester. Vous pouvez visiter la liste complète, voir la définition des attaques, ainsi que la façon de les gérer..

Vulnérabilités HTML5

Mais ce n'est pas tout! À mesure que de nouvelles technologies apparaissent, telles que HTML5, de nombreux autres éléments doivent être pris en compte..

Bien qu'il puisse sembler un peu étrange qu'un langage de balisage soit sujet à des attaques de script intersite, il est logique de prendre en compte certains des attributs autorisés par les nouveaux éléments..

Exemple:

  • Les éléments de forme supportent un formaction attribut pouvant exécuter JavaScript
  • Les éléments d’entrée supportent un onfocus attribut qui peut aussi exécuter JavaScript
  • Le nouvel élément vidéo prend en charge une affiche attribut qui peut aussi exécuter JavaScript

Certes, elles ne sont pas toutes applicables à chaque navigateur, mais il est important de les connaître pour pouvoir tester correctement les navigateurs appropriés..

Cela dit, vous pouvez trouver une feuille de triche HTML5 complète avec les vulnérabilités connues et les navigateurs pertinents sur le site de sécurité HTML5..

Ha.ckers

Ha.ckers.org est l’un des plus anciens sites de ressources XSS sur le Web. Il dispose d’une calculatrice XSS particulièrement utile..

Autrement dit, en plus d'offrir un dictionnaire des vulnérabilités connues, leur calculatrice encodera automatiquement votre code XSS en plusieurs types de codage différents, tels que Hex, Decimal, Base64, etc., de sorte que vous puissiez également essayer d'injecter ceux traductions dans votre application.

Après tout, la moitié de la sécurité consiste à s’assurer que tous les types d’entrée sont correctement filtrés, échappés et validés - pas seulement le scénario de base..


Conclusion

Évidemment, le champ de script intersite est riche en vulnérabilités qui ne se limitent pas à un seul navigateur, et encore moins à une version de navigateur unique. Heureusement, il existe de nombreuses ressources, des feuilles de triche, des instructions, et du matériel pédagogique à notre disposition, non seulement pour nous tenir au courant de ce qui se passe, mais aussi pour nous permettre de le programmer de manière défensive.

Et même si cet article s’adresse spécifiquement à nous, développeurs WordPress, la tactique et les techniques transcendent WordPress et s’appliquent à tous ceux qui construisent des applications Web..

Enfin, j'aimerais remercier Janne Ahlberg d'avoir inspiré le contenu de cette série. C'est un spécialiste de la sécurité qui effectue beaucoup de travaux XSS et qu'il rend compte à Envato. Si ce sujet vous intéresse, notamment en ce qui concerne la promotion de votre travail sur l'un des marchés Envato, je vous recommande vivement de suivre son blog..