cross site scripting attack tutorial with examples
En komplett guide till Cross Site Scripting (XSS) Attack, hur man förhindrar det och XSS-test.
Cross Site Scripting (XSS) är en av de mest populära och sårbara attackerna som alla avancerade testare känner till. Det anses vara en av de mest riskfyllda attackerna för webbapplikationerna och kan också få skadliga konsekvenser.
XSS jämförs ofta med liknande attacker på klientsidan, eftersom språk på klientsidan oftast används under denna attack. XSS-attack anses dock vara mer riskfylld på grund av dess förmåga att skada ännu mindre utsatta tekniker.
Denna XSS-attackhandledning ger dig en fullständig översikt över dess typer, verktyg och förebyggande åtgärder med perfekta exempel i enkla termer för din enkla förståelse.
Vad du kommer att lära dig:
- Introduktion till XSS Attack
- Hur utförs XSS?
- Typer av skriptattacker över flera webbplatser
- Hur testar jag mot XSS?
- XSS testverktyg
- Jämförelse med andra attacker
- Sätt att förhindra XSS
- Förebyggande enligt teknik
- XSS fuskark
- Slutsats
- Rekommenderad läsning
Introduktion till XSS Attack
Cross Site Scripting-attack är en skadlig kodinjektion som kommer att utföras i offrets webbläsare. Skadligt skript kan sparas på webbservern och köras varje gång när användaren ringer till lämplig funktion. Det kan också utföras med andra metoder - utan något sparat skript på webbservern.
Huvudsyftet med denna attack är att stjäla den andra användarens identitetsdata - cookies, sessionstoken och annan information. I de flesta fall används denna attack för att stjäla den andras kakor. Som vi vet hjälper cookies oss att logga in automatiskt. Därför kan vi med stulna kakor logga in med de andra identiteterna. Och detta är en av anledningarna till varför denna attack betraktas som en av de mest riskabla attackerna.
XSS-attack utförs på klientsidan. Det kan utföras med olika programmeringsspråk på klientsidan. Oftast utförs dock denna attack med Javascript och HTML.
Rekommenderad läsning=> HTML-injektionshandledning
Hur utförs XSS?
Cross Site Scripting-attack innebär att skicka och injicera skadlig kod eller skript. Skadlig kod skrivs vanligtvis med programmeringsspråk på klientsidan som Javascript, HTML, VBScript , Flash, etc. Javascript och HTML används dock mest för att utföra denna attack.
Denna attack kan utföras på olika sätt. Beroende på typen av XSS-attack kan det skadliga skriptet återspeglas i offrets webbläsare eller lagras i databasen och köras varje gång när användaren ringer till lämplig funktion.
Den främsta anledningen till denna attack är olämplig användares inmatningsvalidering, där skadlig input kan komma in i utdata. En skadlig användare kan skriva in ett skript som kommer att injiceras i webbplatsens kod. Då kan webbläsaren inte veta om den exekverade koden är skadlig eller inte.
Därför körs skadligt skript i offrets webbläsare eller någon falsk form visas för användarna. Det finns flera former där XSS-attack kan inträffa.
Huvudsakliga former för Cross Site Scripting är följande:
- Cross Site Scripting kan förekomma på det skadliga skriptet som körs på klientsidan.
- Falsk sida eller formulär som visas för användaren (där offret skriver inloggningsuppgifter eller klickar på en skadlig länk).
- På webbplatserna med annonser som visas.
- Skadliga e-postmeddelanden skickade till offret.
Denna attack inträffar när den skadliga användaren hittar de utsatta delarna av webbplatsen och skickar den som lämplig skadlig inmatning. Skadligt skript injiceras i koden och skickas sedan som utdata till slutanvändaren.
Låt oss analysera ett enkelt exempel: Tänk på att vi har en webbplats med ett sökfält.
Om sökfältet är sårbart, när användaren skriver in något skript, kommer det att köras.
Tänk på att en användare anger ett mycket enkelt skript som visas nedan:
alert(‘XSS’) 
Sedan efter att ha klickat på 'Sök' knappen kommer det angivna skriptet att köras.
Som vi ser i Exempel ,skriptet som skrivs in i sökfältet körs. Detta visar bara sårbarheten i XSS-attacken. Ett mer skadligt manus kan dock skrivas också.
Många testare blandar Cross Site Scripting-attack med Javascript-injektion , som också utförs på klientsidan. I båda injiceras attackerna skadliga skript. I XSS-attackerna är det dock inte nödvändigt med taggar för att utföra skriptet.
Till exempel :
;Det kan också vara ett skript som körs på den andra händelsen.
Till exempel:På musen.
Låt oss analysera ett annat exempel:Tänk, vi har en sida där den senaste bokrecensionen visas på webbplatsen.
Koden på denna sida ser ut som visas nedan:
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 Den här koden byter HTML-utsläpp för hela applikationen.
Om du vill byta HTML-undantag för lämplig sidformulär ska koden skrivas enligt följande:
Det finns många färdiga XSS-filter i form av en .jar-fil. Jag vill påminna om att .jar-filen måste läggas till i ditt projekt och först då kan dess bibliotek användas. Ett sådant XSS-filter är xssflt.jar, vilket är ett servletfilter. Denna .jar-fil kan enkelt laddas ner från internet och läggas till i ditt projekt.
Detta filter kontrollerar varje begäran som skickas till applikationen och rensar den från en potentiell injektion.
exempel på klientserverapplikation och webbaserad applikation
När en extern.jar-fil läggs till i projektet måste den också beskrivas i web.xml-filen:
XSSFilter com.cj.xss.XSSFilter En annan möjlig lösning är ESAPI-biblioteket. ESAPI-biblioteket är kompatibelt med många programmeringsspråk. Du hittar ESAPI-bibliotek för Java- och PHP-programmeringsspråk. Det är en öppen källkod och ett gratis bibliotek som hjälper till att kontrollera applikationens säkerhet.
XSS fuskark
XSS Cheat Sheets kan vara till stor hjälp för att förhindra skript på flera platser. Det är en riktlinje för utvecklarna om hur man förhindrar XSS-attacker. Reglerna är mycket hjälpsamma och bör inte glömmas bort när de utvecklas. XSS Cheat Sheets finns i internetgemenskaper som OWASP (Open Web Application Security Project).
Olika typer av fuskark:
- XSS Prevention Cheat Sheet
- DOM XSS fuskark
- XSS Filter Evasion Cheat Sheet
Huvudriktlinjen skulle vara XSS Prevention Cheat Sheet, eftersom det innehåller vanliga regler för XSS-attackförebyggande. Om du följer DOM XSS Cheat Sheet och XSS Filter Evasion Cheat Sheet regler, måste du fortfarande följa XSS Prevention Cheat Sheet.
Som sagt kan XSS Prevention Cheat Sheet hittas i OWASP-communityn. Detta fuskblad ger oss en lista med regler som hjälper oss att minska riskerna för möjliga XSS-attacker. Det är inte bara kodningsreglerna utan också säkerhetssårbarheten på ett förebyggande sätt.
Få av reglerna inkluderar:
- Otillförlitliga data ska inte infogas.
- HTML bör undvikas innan du sätter in otillförlitliga data.
- Attributet bör undvikas innan de otillförlitliga uppgifterna sätts in etc.
Därför kan Cheat Sheet vara till stor hjälp för att förhindra denna typ av attacker.
Slutsats
Under testning rekommenderas det att utvärdera de risker som medför möjliga XSS-attacker. XSS-attack kan påverka webbapplikationer, som också verkar vara säkra.
Det anses vara en av de mest skadliga och riskabla attackerna. Därför bör vi inte glömma denna typ av testning. När du testar mot XSS är det viktigt att ha god kunskap om denna attack. Och detta är grunden för att analysera testresultaten korrekt och välja lämpliga testverktyg.
Är du en testare som har hanterat XSS-attacker över flera webbplatser? Har du några intressanta fakta om XSS-attacker som kan hjälpa våra läsare också? Dela gärna dina erfarenheter med oss i kommentarfältet nedan !!
Rekommenderad läsning
- Fördjupade förklaringar om förmörkelser för nybörjare
- HTML-injektionshandledning: Typer och förebyggande med exempel
- SQL Injection Testing Tutorial (Exempel och förebyggande av SQL Injection Attack)
- Vad är DDoS Attack och hur man DDoS?
- Selenium Grid Tutorial: Installation och exempel på testning av webbläsare
- Java Reflection Tutorial med exempel
- SVN-handledning: Källkodshantering med subversion
- Python DateTime-handledning med exempel
