cross site scripting attack tutorial with examples
Un guide complet sur l'attaque XSS (Cross Site Scripting), comment l'empêcher et les tests XSS.
Cross Site Scripting (XSS) est l'une des attaques les plus populaires et les plus vulnérables connue de tous les testeurs avancés. Elle est considérée comme l'une des attaques les plus risquées pour les applications Web et peut également avoir des conséquences néfastes.
XSS est souvent comparé à des attaques similaires côté client, car les langages côté client sont principalement utilisés pendant cette attaque. Cependant, l'attaque XSS est considérée comme plus risquée, en raison de sa capacité à endommager des technologies encore moins vulnérables.
Ce tutoriel d'attaque XSS, nous vous donnerons un aperçu complet de ses types, outils et mesures préventives avec des exemples parfaits en termes simples pour votre compréhension facile.
Ce que vous apprendrez:
- Introduction à XSS Attack
- Comment XSS est-il exécuté?
- Types d'attaques de script intersite
- Comment tester contre XSS?
- Outils de test XSS
- Comparaison avec d'autres attaques
- Moyens de prévenir XSS
- Prévention selon les technologies
- Feuilles de triche XSS
- Conclusion
- lecture recommandée
Introduction à XSS Attack
L'attaque de type Cross Site Scripting est une injection de code malveillant qui sera exécutée dans le navigateur de la victime. Un script malveillant peut être enregistré sur le serveur Web et exécuté à chaque fois que l'utilisateur appelle la fonctionnalité appropriée. Elle peut également être effectuée avec les autres méthodes - sans aucun script enregistré sur le serveur Web.
Le but principal de cette attaque est de voler les données d’identité de l’autre utilisateur - cookies, jetons de session et autres informations. Dans la plupart des cas, cette attaque est utilisée pour voler les cookies de l’autre personne. Comme nous le savons, les cookies nous aident à nous connecter automatiquement. Par conséquent, avec les cookies volés, nous pouvons nous connecter avec les autres identités. Et c'est l'une des raisons pour lesquelles cette attaque est considérée comme l'une des attaques les plus risquées.
Une attaque XSS est en cours du côté client. Il peut être réalisé avec différents langages de programmation côté client. Cependant, le plus souvent, cette attaque est effectuée avec Javascript et HTML.
Lecture recommandée=> Tutoriel d'injection HTML
Comment XSS est-il exécuté?
L'attaque Cross Site Scripting consiste à envoyer et à injecter du code ou un script malveillant. Le code malveillant est généralement écrit avec des langages de programmation côté client tels que Javascript, HTML, VBScript , Flash, etc. Cependant, Javascript et HTML sont principalement utilisés pour effectuer cette attaque.
Cette attaque peut être effectuée de différentes manières. Selon le type d’attaque XSS, le script malveillant peut être reflété sur le navigateur de la victime ou stocké dans la base de données et exécuté à chaque fois, lorsque l’utilisateur appelle la fonction appropriée.
La principale raison de cette attaque est la validation des entrées utilisateur inappropriée, où des entrées malveillantes peuvent entrer dans la sortie. Un utilisateur malveillant peut saisir un script qui sera injecté dans le code du site Web. Ensuite, le navigateur n'est pas en mesure de savoir si le code exécuté est malveillant ou non.
Par conséquent, un script malveillant est exécuté sur le navigateur de la victime ou tout formulaire falsifié est affiché pour les utilisateurs. Il existe plusieurs formes dans lesquelles une attaque XSS peut se produire.
Les principales formes de scripts intersites sont les suivantes:
- Le Cross Site Scripting peut se produire sur le script malveillant exécuté côté client.
- Fausse page ou formulaire affiché à l'utilisateur (où la victime saisit ses informations d'identification ou clique sur un lien malveillant).
- Sur les sites Web avec des publicités affichées.
- E-mails malveillants envoyés à la victime.
Cette attaque se produit lorsque l'utilisateur malveillant trouve les parties vulnérables du site Web et les envoie comme une entrée malveillante appropriée. Un script malveillant est injecté dans le code, puis envoyé en sortie à l'utilisateur final.
Analysons un exemple simple: Considérez que nous avons un site Web avec un champ de recherche.
Si le champ de recherche est vulnérable, lorsque l'utilisateur entre un script, il sera exécuté.
Considérez, un utilisateur entre un script très simple comme indiqué ci-dessous:
alert(‘XSS’)
Puis après avoir cliqué sur le 'Chercher' bouton, le script saisi sera exécuté.
Comme nous le voyons dans le Exemple ,le script saisi dans le champ de recherche est exécuté. Cela montre simplement la vulnérabilité de l'attaque XSS. Cependant, un script plus dangereux peut également être saisi.
De nombreux testeurs confondent l'attaque de type Cross Site Scripting avec Injection Javascript , qui est également en cours du côté client. Dans les deux cas, le script malveillant des attaques est injecté. Cependant, dans le cas d'une attaque XSS, les balises ne sont pas nécessaires pour exécuter le script.
Par exemple :
;
Il peut également s'agir d'un script exécuté sur l'autre événement.
Par exemple:Sur un survol de la souris.
Analysons un autre exemple:Considérez, nous avons une page, où la dernière critique de livre est affichée sur le site Web.
Le code de cette page ressemblera à celui ci-dessous:
print '' print '. If this vulnerability is present in the web application, an indicated text will be inserted intags. Trying to pass some code through HTTP request as this is also a method to check if this attack is possible.
Generally, while testing for possible XSS attack, input validation should be checked and the tester should be conscious while checking the website’s output. Also if a code review is being performed, it is important to find how input can get into the output.
XSS Testing Tools
As Cross Site Scripting attack is one of the most popular risky attacks, there are a plenty of tools to test it automatically. We can find various scanners to check for possible XSS attack vulnerabilities – like, Nesus and Nikto. Both of which are considered as quite reliable.
From my software testing career, I would like to mention SOAP UI tool. SOAP UI can be considered as a quite strong tool for checking against the possible XSS attacks. It contains ready templates for checking against this attack. It really simplifies the testing process.
However, in order to test for this vulnerability with SOAP UI tool, API level testing should already be automated with that tool. Another solution to test against XSS can be browser plugins. However, plugins are considered as quite a weak tool to check against this type of attack.
Even while testing automatically, the tester should have good knowledge of this attack type and should be able to analyze the results appropriately.
Good knowledge is also helpful while selecting the testing tool. Also, it is important to know, that while performing scanning for security vulnerabilities with an automatic tool, testing manually is also a good practice and this way the tester will be able to see the results and analyze them.
Recommended Tool:
#1) Kiuwan

Find and fix vulnerabilities in your code at every stage of the SDLC.
Kiuwan is compliant with the most stringent security standards including OWASP, CWE, SANS 25, HIPPA, and more. Integrate Kiuwan in your IDE for instant feedback during development.
Kiuwan supports all major programming languages and integrates with leading DevOps tools.
=> Scan your code for free
Comparison with Other Attacks
XSS is considered to be one of the riskiest attacks, as its main purpose is to steal the website’s or system’s user identities. Also, XSS attack can be performed with different client-side languages like Javascript, HTML, VBScript, Flash, etc. And this makes it more harmful and widespread than the other possible attacks.
Testing for XSS attack is quite similar to testing for the other possible client-side attacks. However, it is important to remember what additional cases should be checked while testing for XSS.
Another thing, that makes this attack riskier is the possibility to be stored in the web service – this way it can affect many users for a longer period of time. XSS sometimes can be performed to even less vulnerable systems and its vulnerabilities are sometimes difficult to be found.
Also, while comparing with the other attacks, XSS has many ways to be performed and affect the website as well.
Ways to Prevent XSS
Though this type of attack is considered to be one of the most dangerous and risky one, still a preventing plan should be prepared. Because of the popularity of this attack, there are quite many ways to prevent it.
Commonly used main prevention methods include:
- Data validation
- Filtering
- Escaping
The first step in the prevention of this attack is Input validation . Everything, that is entered by the user should be precisely validated, because the user’s input may find its way to the output. Data validation can be named as the basis for ensuring the system’s security. I would remind, that the idea of validation is not to allow inappropriate input.
Therefore it just helps to reduce the risks, but may not be enough to prevent the possible XSS vulnerability.
Another good prevention method is user’s input filtering. The idea of the filtering is to search for risky keywords in the user’s input and remove them or replace them by empty strings.
Those keywords may be:
- tags
- Javascript commands
- HTML markup
Input filtering is quite easy to practice. It can be performed in different ways too.
Like:
- By developers who have written server-side code.
- Appropriate programming language’s library is being used.
In this case, some developers write their own code to search for appropriate keywords and remove them. However, the easier way would be to select appropriate programming languages library to filter the user’s input. I would like to comment, that using libraries is a more reliable way, as those libraries were used and tested by many developers.
Another possible prevention method is characters escaping . In this practice, appropriate characters are being changed by special codes. For Example, Meanwhile, good testing should not be forgotten as well. It should be invested in good software testers knowledge and reliable software testing tools. This way good software quality will be better assured.
Prevention According to Technologies
As already discussed, filtering and characters escaping are the main prevention methods. However, it can be performed differently in different programming languages. Some programming languages have appropriate filtering libraries and some do not.
It should be mentioned, that filtering can be performed quite easily in Java and PHP programming languages, as they have appropriate libraries for it.
Java technology is quite widely used, therefore there are many solutions to it. If you are using Spring technology and if you would like to escape HTML for the whole application, then you have to write the appropriate code in the project’s web.xml file.
defaultHtmlEscape true
Ce code basculera l'échappement HTML pour l'ensemble de l'application.
Si vous souhaitez modifier l'échappement HTML pour les formulaires de la page appropriés, le code doit être rédigé comme suit:
Il existe de nombreux filtres XSS prêts sous la forme d'un fichier .jar. Je rappelle que le fichier .jar doit être ajouté à votre projet et que ses bibliothèques peuvent alors être utilisées. Un de ces filtres XSS est xssflt.jar, qui est un filtre de servlet. Ce fichier .jar peut être facilement téléchargé depuis Internet et ajouté à votre projet.
Ce filtre vérifie chaque demande envoyée à l'application et la nettoie d'une injection potentielle.
types de métadonnées dans l'entrepôt de données
Lorsqu'un fichier external.jar est ajouté au projet, il doit également être décrit dans le fichier web.xml:
XSSFilter com.cj.xss.XSSFilter
Une autre solution possible est la bibliothèque ESAPI. La bibliothèque ESAPI est compatible avec de nombreux langages de programmation. Vous pouvez trouver des bibliothèques ESAPI pour les langages de programmation Java et PHP. C'est une bibliothèque open source et gratuite, qui permet de contrôler la sécurité de l'application.
Feuilles de triche XSS
Les Cheat Sheets XSS peuvent être très utiles pour la prévention des scripts intersites. C'est une directive pour les développeurs sur la façon de prévenir les attaques XSS. Les règles sont très utiles et ne doivent pas être oubliées lors du développement. Les feuilles de triche XSS peuvent être trouvées dans les communautés Internet telles que OWASP (The Open Web Application Security Project).
Différents types de feuilles de triche:
- Aide-mémoire sur la prévention XSS
- Aide-mémoire DOM XSS
- Aide-mémoire XSS Filter Evasion
La principale directive serait XSS Prevention Cheat Sheet, car elle fournit des règles communes pour la prévention des attaques XSS. Si vous suiviez les règles DOM XSS Cheat Sheet et XSS Filter Evasion Cheat Sheet, vous devrez toujours suivre XSS Prevention Cheat Sheet.
Comme indiqué, XSS Prevention Cheat Sheet peut être trouvé dans la communauté OWASP. Cette feuille de triche nous fournit une liste de règles qui nous aideraient à réduire les risques d'attaques XSS possibles. Ce ne sont pas seulement les règles de codage mais aussi les failles de sécurité sur une base de prévention.
Peu de règles incluent:
- Les données non fiables ne doivent pas être insérées.
- Le HTML doit être échappé avant d'insérer des données non fiables.
- L'attribut doit être échappé avant d'insérer les données non fiables, etc.
Par conséquent, Cheat Sheet peut être très utile pour prévenir ce type d'attaques.
Conclusion
Lors des tests, il est fortement recommandé d'évaluer les risques qui entraînent d'éventuelles attaques XSS. L'attaque XSS peut affecter les applications Web, qui semblent également sécurisées.
Elle est considérée comme l'une des attaques les plus dangereuses et les plus risquées. Par conséquent, nous ne devons pas oublier ce type de test. Lors de l'exécution de tests contre XSS, il est important d'avoir une bonne connaissance de cette attaque. Et c'est la base pour analyser correctement les résultats des tests et choisir les outils de test appropriés.
Êtes-vous un testeur qui a traité des attaques XSS de scripts intersites? Avez-vous des faits intéressants sur les attaques XSS qui pourraient également aider nos lecteurs? N'hésitez pas à partager vos expériences avec nous dans la section commentaires ci-dessous !!
lecture recommandée
- Tutoriels Eclipse détaillés pour les débutants
- Tutoriel d'injection HTML: types et prévention avec des exemples
- Didacticiel de test d'injection SQL (exemple et prévention des attaques par injection SQL)
- Qu'est-ce que l'attaque DDoS et comment DDoS?
- Didacticiel Selenium Grid: configuration et exemple de test de navigateur croisé
- Tutoriel de réflexion Java avec des exemples
- Tutoriel SVN: Gestion du code source à l'aide de Subversion
- Tutoriel Python DateTime avec des exemples