cross site scripting attack tutorial with examples
En komplet guide til Cross Site Scripting (XSS) Attack, hvordan man forhindrer det, og XSS-test.
Cross Site Scripting (XSS) er et af de mest populære og sårbare angreb, som alle avancerede tester kender. Det betragtes som et af de mest risikable angreb for webapplikationerne og kan også medføre skadelige konsekvenser.
XSS sammenlignes ofte med lignende klient-side-angreb, da klientsidesprog for det meste bruges under dette angreb. XSS-angreb betragtes dog som mere risikabelt på grund af dets evne til at beskadige endnu mindre sårbare teknologier.
Denne XSS-angrebsvejledning giver vi dig et komplet overblik over dens typer, værktøjer og forebyggende foranstaltninger med perfekte eksempler i enkle termer for din nemme forståelse.
Hvad du lærer:
- Introduktion til XSS Attack
- Hvordan udføres XSS?
- Typer af cross site scripting-angreb
- Sådan tester du mod XSS?
- XSS testværktøjer
- Sammenligning med andre angreb
- Måder at forhindre XSS
- Forebyggelse ifølge teknologier
- XSS snydeark
- Konklusion
- Anbefalet læsning
Introduktion til XSS Attack
Cross Site Scripting-angreb er en ondsindet kodeinjektion, som udføres i offerets browser. Ondsindet script kan gemmes på webserveren og udføres hver gang, når brugeren kalder den passende funktionalitet. Det kan også udføres med de andre metoder - uden noget gemt script på webserveren.
Hovedformålet med dette angreb er at stjæle den anden brugers identitetsdata - cookies, sessionstokener og anden information. I de fleste tilfælde bruges dette angreb til at stjæle den anden persons cookies. Som vi ved, hjælper cookies os med at logge ind automatisk. Derfor med stjålne cookies kan vi logge ind med de andre identiteter. Og dette er en af grundene til, at dette angreb betragtes som et af de mest risikable angreb.
XSS-angreb udføres på klientsiden. Det kan udføres med forskellige programmeringssprog på klientsiden. Imidlertid udføres dette angreb oftest med Javascript og HTML.
Anbefalet læsning=> HTML-injektionsvejledning
Hvordan udføres XSS?
Cross Site Scripting-angreb betyder at sende og indsprøjte ondsindet kode eller script. Ondsindet kode skrives normalt med programmeringssprog på klientsiden som Javascript, HTML, VBScript , Flash osv. Men Javascript og HTML bruges mest til at udføre dette angreb.
Dette angreb kan udføres på forskellige måder. Afhængigt af typen af XSS-angreb kan det ondsindede script blive reflekteret i offerets browser eller gemt i databasen og udført hver gang, når brugeren kalder den passende funktion.
Hovedårsagen til dette angreb er upassende brugers inputvalidering, hvor ondsindet input kan komme ind i output. En ondsindet bruger kan indtaste et script, der vil blive injiceret i webstedets kode. Derefter er browseren ikke i stand til at vide, om den udførte kode er skadelig eller ej.
Derfor udføres ondsindet script i offerets browser, eller der vises en falsk form for brugerne. Der er flere former, hvor XSS-angreb kan forekomme.
Hovedformer for Cross Site Scripting er som følger:
- Cross Site Scripting kan forekomme på det ondsindede script, der udføres på klientsiden.
- Falsk side eller form, der vises for brugeren (hvor offeret skriver legitimationsoplysninger eller klikker på et ondsindet link).
- På hjemmesider med viste reklamer.
- Ondsindede e-mails sendt til offeret.
Dette angreb opstår, når den ondsindede bruger finder de sårbare dele af webstedet og sender det som passende ondsindet input. Ondsindet script indsprøjtes i koden og sendes derefter som output til den endelige bruger.
Lad os analysere et simpelt eksempel: Overvej, at vi har et websted med et søgefelt.
Hvis søgefeltet er sårbart, når brugeren indtaster et hvilket som helst script, vil det blive udført.
Overvej, at en bruger indtaster et meget simpelt script som vist nedenfor:
alert(‘XSS’) 
Derefter efter at have klikket på 'Søg' knappen, vil det indtastede script blive udført.
Som vi ser i Eksempel ,scriptet, der er skrevet i søgefeltet, bliver udført. Dette viser bare sårbarheden ved XSS-angreb. Dog kan der også indtastes et mere skadeligt script.
Mange testere blander Cross Site Scripting-angreb med Javascript-injektion , som også udføres på klientsiden. I begge indsprøjtes angrebets ondsindede script. Imidlertid er tags i XSS-angreb ikke tags nødvendige for at udføre scriptet.
For eksempel :
;Det kan også være et script, der udføres på den anden begivenhed.
For eksempel:På en mus svæver.
Lad os analysere et andet eksempel:Overvej, vi har en side, hvor den seneste boganmeldelse vises på hjemmesiden.
Koden på denne side ser ud som vist nedenfor:
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 Denne kode skifter HTML-udslip for hele applikationen.
Hvis du vil skifte HTML, der undslipper til den relevante sideformular, skal koden skrives som følger:
Der er mange klare XSS-filtre i form af en .jar-fil. Jeg vil minde om, at .jar-filen skal føjes til dit projekt, og først derefter kan dens biblioteker bruges. Et sådant XSS-filter er xssflt.jar, som er et servletfilter. Denne .jar-fil kan nemt downloades fra internettet og føjes til dit projekt.
Dette filter kontrollerer enhver anmodning, der sendes til applikationen, og renser den fra en potentiel injektion.
hvordan man løser standard gateway ikke tilgængelig windows 10
Når en ekstern.jar-fil føjes til projektet, skal den også beskrives i web.xml-filen:
XSSFilter com.cj.xss.XSSFilter En anden mulig løsning er ESAPI-biblioteket. ESAPI-biblioteket er kompatibelt med mange programmeringssprog. Du kan finde ESAPI-biblioteker til Java- og PHP-programmeringssprog. Det er et open source og gratis bibliotek, som hjælper med at kontrollere applikationens sikkerhed.
XSS snydeark
XSS Cheat Sheets kan være meget nyttigt til forebyggelse på tværs af scripting. Det er en retningslinje for udviklerne om, hvordan man forhindrer XSS-angreb. Reglerne er meget nyttige og bør ikke glemmes under udviklingen. XSS Cheat Sheets kan findes i internetsamfund såsom OWASP (The Open Web Application Security Project).
Forskellige typer snydeark:
- XSS forebyggelse snydeark
- DOM XSS snydeark
- XSS-filterunddragelse snydeark
Den vigtigste retningslinje ville være XSS Prevention Cheat Sheet, da det indeholder almindelige regler for XSS angreb forebyggelse. Hvis du følger DOM XSS Cheat Sheet og XSS Filter Evasion Cheat Sheet regler, skal du stadig følge XSS Prevention Cheat Sheet.
Som nævnt kan XSS Prevention Cheat Sheet findes i OWASP-samfundet. Dette snydeark giver os en liste over regler, der kan hjælpe os med at reducere risikoen for mulige XSS-angreb. Det er ikke kun kodningsreglerne, men også sikkerhedssårbarhederne på et forebyggelsesgrundlag.
Få af reglerne inkluderer:
- Ikke-tillid til data bør ikke indsættes.
- HTML skal undslippes, før data, der ikke er tillid til, indsættes.
- Attributten skal undslippes inden indsættelse af de ikke-tillid til data osv.
Derfor kan Cheat Sheet være meget nyttigt til at forhindre denne type angreb.
Konklusion
Under test anbefales det stærkt at evaluere de risici, der medfører mulige XSS-angreb. XSS-angreb kan påvirke webapplikationer, der også synes at være sikre.
Det anses for at være et af de mest skadelige og risikable angreb. Derfor bør vi ikke glemme denne type test. Mens du udfører test mod XSS, er det vigtigt at have en god viden om dette angreb. Og dette er grundlaget for at analysere testresultaterne korrekt og vælge de passende testværktøjer.
Er du en tester, der har behandlet XSS-angreb på tværs af websteder? Har du nogle interessante fakta om XSS-angreb, der også kan hjælpe vores læsere? Del gerne dine oplevelser med os i kommentarfeltet nedenfor !!
Anbefalet læsning
- Dybdegående formørkelsesvejledninger til begyndere
- HTML-injektionsvejledning: Typer og forebyggelse med eksempler
- SQL Injection Testing Tutorial (Eksempel og forebyggelse af SQL Injection Attack)
- Hvad er DDoS Attack og hvordan man DDoS?
- Selen Grid Tutorial: Opsætning og eksempel på test af tværbrowser
- Java Reflection Tutorial med eksempler
- SVN Tutorial: Kildekodestyring ved hjælp af Subversion
- Python DateTime-tutorial med eksempler
