cross site scripting attack tutorial with examples
En komplett guide til Cross Site Scripting (XSS) Attack, hvordan du kan forhindre det, og XSS testing.
Cross Site Scripting (XSS) er et av de mest populære og sårbare angrepene som er kjent av alle avanserte tester. Det regnes som et av de mest risikable angrepene for webapplikasjonene og kan også medføre skadelige konsekvenser.
XSS sammenlignes ofte med lignende angrep på klientsiden, siden språk på klientsiden hovedsakelig blir brukt under dette angrepet. Imidlertid anses XSS-angrep som mer risikabelt på grunn av dets evne til å skade enda mindre sårbare teknologier.
Denne XSS-angrepsveiledningen vil vi gi deg en fullstendig oversikt over dens typer, verktøy og forebyggende tiltak med perfekte eksempler i enkle termer for enkel forståelse.
Hva du vil lære:
- Introduksjon til XSS Attack
- Hvordan utføres XSS?
- Typer av skriptangrep på tvers av nettsteder
- Hvordan teste mot XSS?
- XSS testverktøy
- Sammenligning med andre angrep
- Måter å forhindre XSS
- Forebygging i henhold til teknologier
- XSS Cheat Sheets
- Konklusjon
- Anbefalt lesing
Introduksjon til XSS Attack
Cross Site Scripting-angrep er en skadelig kodeinjeksjon, som vil bli utført i offerets nettleser. Ondsinnet skript kan lagres på webserveren og utføres hver gang når brukeren kaller riktig funksjonalitet. Det kan også utføres med de andre metodene - uten noe lagret skript på webserveren.
Hovedformålet med dette angrepet er å stjele identiteten til den andre brukeren - informasjonskapsler, sesjonstokener og annen informasjon. I de fleste tilfeller blir dette angrepet brukt til å stjele den andres informasjonskapsler. Som vi vet hjelper informasjonskapsler oss med å logge inn automatisk. Derfor med stjålne informasjonskapsler kan vi logge inn med de andre identitetene. Og dette er en av grunnene til at dette angrepet blir ansett som et av de mest risikable angrepene.
XSS-angrep utføres på klientsiden. Den kan utføres med forskjellige programmeringsspråk på klientsiden. Imidlertid utføres dette angrepet som oftest med Javascript og HTML.
Anbefalt lesing=> HTML-injeksjonsveiledning
Hvordan utføres XSS?
Cross Site Scripting-angrep betyr å sende og injisere skadelig kode eller skript. Ondsinnet kode skrives vanligvis med programmeringsspråk på klientsiden som Javascript, HTML, VBScript , Flash osv. Imidlertid brukes Javascript og HTML mest for å utføre dette angrepet.
Dette angrepet kan utføres på forskjellige måter. Avhengig av typen XSS-angrep, kan det ondsinnede skriptet gjenspeiles i offerets nettleser eller lagres i databasen og utføres hver gang, når brukeren kaller riktig funksjon.
Hovedårsaken til dette angrepet er upassende validering av brukerens input, der ondsinnet input kan komme inn i utdataene. En ondsinnet bruker kan angi et skript som vil bli injisert i nettstedets kode. Da kan ikke nettleseren vite om den utførte koden er skadelig eller ikke.
Derfor utføres ondsinnet skript i offerets nettleser, eller det vises en falsk form for brukerne. Det er flere former der XSS-angrep kan forekomme.
Hovedformer for Cross Site Scripting er som følger:
- Cross Site Scripting kan forekomme på det ondsinnede skriptet som utføres på klientsiden.
- Forfalsket side eller skjema som vises for brukeren (der offeret skriver legitimasjon eller klikker på en ondsinnet lenke).
- På nettsteder med annonser som vises.
- Ondsinnede e-postmeldinger sendt til offeret.
Dette angrepet skjer når den ondsinnede brukeren finner de sårbare delene av nettstedet og sender det som passende ondsinnet innspill. Ondsinnet skript blir injisert i koden og deretter sendt som utdata til sluttbrukeren.
La oss analysere et enkelt eksempel: Tenk at vi har et nettsted med et søkefelt.
Hvis søkefeltet er sårbart, når brukeren skriver inn et hvilket som helst skript, vil det bli utført.
Tenk på at en bruker skriver inn et veldig enkelt skript som vist nedenfor:
alert(‘XSS’) 
Deretter etter å ha klikket på 'Søk' knappen, vil det angitte skriptet bli utført.
Som vi ser i Eksempel ,skriptet som er skrevet inn i søkefeltet blir utført. Dette viser bare sårbarheten til XSS-angrepet. Et mer skadelig skript kan imidlertid også skrives inn.
Mange testere blander sammen Cross Site Scripting-angrep med Javascript Injection , som også utføres på klientsiden. I begge blir angrepene skadelig skript injisert. Imidlertid er det ikke nødvendig med tagger i XSS-angrep for å utføre skriptet.
For eksempel :
;Det kan også være et skript som er utført på den andre hendelsen.
For eksempel:På en mus svever.
La oss analysere et annet eksempel:Tenk, vi har en side der den siste bokanmeldelsen vises på nettstedet.
Koden på denne siden vil se ut 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 koden vil bytte HTML-rømning for hele applikasjonen.
Hvis du vil bytte HTML-rømning for den aktuelle sideskjemaet, bør koden skrives som følger:
Det er mange klare XSS-filtre i form av en .jar-fil. Jeg vil minne om at .jar-filen må legges til i prosjektet ditt, og bare da kan bibliotekene brukes. Et slikt XSS-filter er xssflt.jar, som er et servletfilter. Denne .jar-filen kan enkelt lastes ned fra internett og legges til prosjektet ditt.
Dette filteret sjekker hver forespørsel som sendes til applikasjonen og renser den fra en potensiell injeksjon.
selen webdriver med agurkeksempel i formørkelse
Når en ekstern.jar-fil legges til i prosjektet, må den også beskrives i web.xml-filen:
XSSFilter com.cj.xss.XSSFilter En annen mulig løsning er ESAPI-biblioteket. ESAPI-biblioteket er kompatibelt med mange programmeringsspråk. Du kan finne ESAPI-biblioteker for programmeringsspråk Java og PHP. Det er en åpen kildekode og et gratis bibliotek, som hjelper til med å kontrollere applikasjonens sikkerhet.
XSS Cheat Sheets
XSS Cheat Sheets kan være veldig nyttig for forebygging av scripting på tvers av nettsteder. Det er en retningslinje for utviklerne om hvordan du kan forhindre XSS-angrep. Reglene er veldig nyttige og bør ikke glemmes mens du utvikler deg. XSS Cheat Sheets finnes i internetsamfunn som OWASP (The Open Web Application Security Project).
Ulike typer jukseark:
- XSS Prevention Cheat Sheet
- DOM XSS Cheat Sheet
- XSS Filter Evasion Cheat Sheet
Hovedretningslinjen vil være XSS Prevention Cheat Sheet, da det gir vanlige regler for XSS angrepsforebygging. Hvis du følger DOM XSS Cheat Sheet og XSS Filter Evasion Cheat Sheet regler, må du fortsatt følge XSS Prevention Cheat Sheet.
Som nevnt kan XSS Prevention Cheat Sheet finnes i OWASP-samfunnet. Dette juksearket gir oss en liste over regler som vil hjelpe oss med å redusere risikoen for mulige XSS-angrep. Det er ikke bare kodingsreglene, men også sikkerhetssårbarhetene på et forebyggende grunnlag.
Få av reglene inkluderer:
- Ikke-klarerte data skal ikke settes inn.
- HTML bør unngås før du setter inn upålitelige data.
- Attributtet skal slippes før du setter inn de upålitelige dataene osv.
Derfor kan Cheat Sheet være svært nyttig for å forhindre denne typen angrep.
Konklusjon
Under testing anbefales det sterkt å evaluere risikoen som medfører mulige XSS-angrep. XSS-angrep kan påvirke webapplikasjoner, som også ser ut til å være sikre.
Det regnes som et av de mest skadelige og risikable angrepene. Derfor bør vi ikke glemme denne typen testing. Mens du utfører testing mot XSS, er det viktig å ha god kunnskap om dette angrepet. Og dette er grunnlaget for å analysere testresultatene riktig og velge passende testverktøy.
Er du en tester som har behandlet XSS-angrep på tvers av nettsteder? Har du noen interessante fakta om XSS-angrep som også kan hjelpe leserne våre? Del gjerne dine erfaringer med oss i kommentarfeltet nedenfor !!
Anbefalt lesing
- In-Depth Eclipse Tutorials For Beginners
- HTML Injection Tutorial: Typer og forebygging med eksempler
- SQL Injection Testing Tutorial (Eksempel og forebygging av SQL Injection Attack)
- Hva er DDoS Attack og hvordan gjør jeg DDoS?
- Selenium Grid Tutorial: Setup and Example of Cross Browser Testing
- Java Reflection Tutorial med eksempler
- SVN Tutorial: Source Code Management Using Subversion
- Python DateTime Tutorial med eksempler
