Hur man hittar XSS-sårbarhet

Cross-site scripting (XSS) är en typ av säkerhetsrisk som finns i webbplatser och webbapplikationer.

XSS-sårbarhetermöjliggöra för illvilliga aktörer att injicera skadlig kod (skript på klientsidan) på webbsidor som användarna tittar på. När den väl har körts av användarens webbläsare kan den här koden utföra åtgärder som att ändra beteendet eller utseendet på webbplatsen, stjäla känslig data, utföra åtgärder för användarens räkning och mer

Grundorsaken till XSS-sårbarheten härrör från misslyckandet med att korrekt validera eller undvika användarinmatning eller dynamiskt innehåll, vilket gör att JavaScript på klientsidan kan injiceras på ett sätt som gör det möjligt att köra det. Därför löper din applikation risk för XSS-sårbarhet varhelst den hanterar användarinmatning. XSS finns i många olika former, som kan kategoriseras i följande grupper:

• Reflekterad (icke-beständig) XSS: Precis som namnet antyder, uppstår reflekterad XSS när de injicerade skadliga skriptresultaten dyker upp eller omedelbart reflekteras av användaren utan att sanera innehållet på lämpligt sätt.

• Lagrad (beständig) XSS: Det här är en mer förödande variant av ett skriptfel på flera webbplatser. Det inträffar när data som tillhandahålls av angriparen sparas av servern och sedan permanent visas på 'normala' sidor som returneras till andra användare under regelbunden surfning, utan att korrekt HTML escapes.
• DOM-baserad XSS: DOM-baserad XSS uppstår när den injicerade skadliga koden inte når webbservern. Istället reflekteras det av JavaScript-kod på klientsidan på klientsidan.

XSS är en av de vanligaste sårbarheterna som upptäcks i webbapplikationer. Om XSS lämnas oparpad kan din applikation utsättas för olika säkerhetsrisker som negativt påverkar organisationen och slutanvändarna. En XSS-sårbarhet som gör att en angripare kan ändra kundproduktkvantitetssaldo eller bankkontosaldo kan påverka ett företags rykte eller försvaga konsumenternas förtroende. Detta är något du inte har råd att ignorera. Därför är det viktigt att identifiera och ta bort denna sårbarhet från din webbapplikation innan den utsätter den för allvarliga säkerhetsproblem. Den här artikeln kommer att förklara hur du hittar XSS i webbapplikationer, inklusive vad du kan göra för att förhindra det.

Manuell kodgranskning och testning

Kodgranskning syftar till att identifiera säkerhetsbrister i applikationer, tillsammans med de exakta grundorsakerna. Det involverar granskning av källkoden för ett program för att säkerställa att det är självförsvar i sin givna miljö. Enligt OWASP, 'Om koden inte har granskats för säkerhetshål är sannolikheten att applikationen har problem praktiskt taget 100 %”. Verktyg kan användas för att utföra denna uppgift. Ändå förstår de tyvärr inte sammanhanget (mänsklig verifiering krävs alltid), och det är här manuell säkerhetskodgranskning kommer in i bilden.

Om manuell kodgranskning görs korrekt, bör ett penetrationstest efteråt med automatiserade verktyg upptäcka få eller inga sårbarheter. Intressant nog ger OWASP en detaljerad guide för manuell granskning kod för XSS-sårbarheter , inklusive en komplett manuell testguide för reflekterade XSS , lagrad XSS , och DOM-baserade XSS-sårbarheter för din kännedom. Följande manuella processer kan användas för att identifiera vanliga XSS-sårbarheter:

Identifiera kod som matar ut användarinmatning: Koder som matar ut användarindata utan korrekt sanering riskerar XSS-sårbarhet. Tryck på Ctrl + U för att visa sidutgångskällan från webbläsaren för att se om din kod är placerad i ett attribut. Om så är fallet, injicera följande kod och testa för att se resultatet:'onmouseover= alert('hej');'

Du kan testa för att se utdata med det här skriptet:;

Men om koden du granskar filtrerar eftertecken, testa sedan med följande skript istället: &{alert(‘hej’);}

Kontrollera att utgången är kodad: Kontrollera att HtmlEncode används för att koda HTML-utdata som innehåller alla typer av indata. Kontrollera också att UrlEncode används för att koda URL-strängar. Indata kan komma från frågesträngar, formulärfält, cookies, HTTP-rubriker och indata som läses från en databas, särskilt om andra applikationer delar databasen. Om dessa kodningar saknas riskerar din applikation att bli XSS-sårbarhet. Genom att koda data förhindrar du dessutom webbläsaren från att behandla HTML som ett körbart skript.

Identifiera kod som hanterar webbadresser: Kod som styr webbadresser kan riskera XSS och andra sårbarheter. Granska din kod och dina system enligt följande:

• Kontrollera att din webbserver är uppdaterad. Om din webbserver inte är uppdaterad med de senaste säkerhetskorrigeringarna kan den vara sårbar för katalogövergångsattacker :

• Om din kod filtrerar efter '/' kan en angripare enkelt kringgå filtret genom att använda URL-kodning (procentkodning ) för samma karaktär. Till exempel är procentkodningen för '/' '%c0f%af', som kan användas för att kringgå filtret som visas i följande URL: http://www.abc.com/..%c0f%af ../winnt.

• Om din kod behandlar frågesträngsinmatning, kontrollera att den begränsar indata och utför gränskontroller. Kontrollera också att koden inte är sårbar om en angripare injicerar en enorm mängd data via en frågesträngsparameter som URL:en som visas här: http://www.abc.com/test.aspx?var=InjectHugeAmountOfDataHere.

Enhetstesta dina koder: Enhetstestning är en mjukvarutestmetod genom vilken individuella enheter av källkod testas för att avgöra om de är lämpliga för användning. Enhetstestning syftar till att isolera varje del av programmet och visa att de enskilda komponenterna är korrekta. Använd enhetstestning för att se till att en viss databit är korrekt escaped. Enhetstestning hjälper till att identifiera XSS och andra brister tidigt i utvecklingscykeln. Om möjligt, enhetstesta varje plats där användarlevererad data visas. När du har hittat och fixat ett XSS-fel i din kod, överväg att lägga till ett regressionstest för det.

Utför dessa grundläggande tester på din ansökan : Skapa en testanvändarprofil och använd den profilen för att interagera med din applikation. Infoga strängar som innehåller HTML- och JavaScript-metatecken som >’>”>i alla programinmatningar, såsom formulär, URL-parametrar, dolda fält eller cookievärden.

Om din applikation inte korrekt undkommer denna sträng, kommer du att se en varning och vet att något inte står rätt till. Varhelst din applikation hanterar webbadresser som tillhandahålls av användaren anger du följande javascript-kod: alert(0) eller data:text/html,. Alla dessa kan hjälpa till att identifiera lagrade XSS-buggar.

Automatiserad applikationstestning

Standard tekniker och verktyg för säkerhetstestning kan användas för att testa och upptäcka XSS-sårbarheter i webbapplikationer. Några av de populära testteknikerna som kan användas inkluderar:

• Statisk applikationssäkerhetstestning (SAST): SAST används för att säkra applikationer genom att granska källkoden för att identifiera sårbarheter eller bevis på kända osäkra metoder när den inte körs. En betydande fördel med statisk kodanalys är att du inte behöver vänta tills applikationen distribueras i en iscensättningsmiljö med testdata. Istället kan du bara testa koden. Detta ger inspektionen för sårbarheter 100 % kodtäckning och gör det snabbare och billigare att hitta sårbarheter. SAST-verktyg använder en teststrategi med vit låda som skannar källkoden för applikationer och deras komponenter för att identifiera potentiella säkerhetsbrister.
• Dynamic Application Security Testing (DAST): DAST verktyg kommunicerar med applikationer för att identifiera potentiella säkerhetsbrister via front-end. DAST-verktyg inte har tillgång till källkoder; istället utför de attacker med black-box-strategin för att upptäcka sårbarheter. Med dynamisk analys utförs säkerhetskontroller under körning eller exekvering av koden eller applikationen som granskas. En teknik som kallas fuzzing används i dynamiska tester för att skicka in slumpmässiga, felaktiga data som indata till applikationen för att avgöra om den kommer att avslöja XSS-brister.
• Interactive Application Security Testing (IAST): IAST kombinerar det bästa från SAST och DAST. Den analyserar kod för XSS och andra säkerhetsbrister medan appen körs av alla aktiviteter som interagerar med applikationens funktionalitet.

Med teknikerna som beskrivs ovan kan du snabbt testa och upptäcka XSS-sårbarheter i dina webbapplikationer. Webb sårbarhetsskannrar som t.exOövervinnerlig,Acunetix, Veracode , Checkmarx , och andra är kraftfulla verktyg som kan genomsöka hela din webbplats eller applikation och automatiskt söker efter XSS och andra säkerhetsbrister. Även om de ofta inte är optimerade för just din applikation, låter de dig snabbt och enkelt hitta de mer uppenbara sårbarheterna. Dessutom implementerar de de flesta av testteknikerna för webbapplikationer som diskuterats ovan och gör det möjligt för dig att tillämpa dessa tekniker för att skanna din webbapplikation efter sårbarheter. Den kommer sedan att generera en rapport om de upptäckta sårbarheterna och försöka åtgärda dem automatiskt. Både Invicti och Acunetix erbjuder gratis demos.

Invincible Access Demo

Acunetix Access Demo

Vad du kan göra för att förhindra XSS

Det här avsnittet ger några rekommendationer om hur du kan minimera XSS-sårbarheter. De är inte på något sätt uttömmande; de bör dock vara en bra utgångspunkt för att säkra applikationer. Ingenting är idiotsäkert. Tekniken förändras mycket snabbt och attackerna blir mer sofistikerade. Det som fungerar idag kanske inte fungerar fullt ut imorgon. Men genom att förstå grunderna kan du vara beredd att förhindra framtida attacktekniker när de utvecklas. Här är några av de saker du kan göra för att förhindra XSS.

Använd säker kodningsmetoder: Som med de flesta injektionssårbarheter är nyckeln till att säkra din webbapplikation och förhindra XSS-attacker att följa för att säkerställa kodningsmetoder. Ett användarinmatningsscenario att vara uppmärksam på i dina applikationer är när din applikation accepterar input från användare och använder den inmatningen för att skapa utdata för andra användare. Det är här de gyllene reglerna för användarinmatning kommer till spel. Den första gyllene regeln för användarinmatning säger att all information är misstänkt tills motsatsen bevisats. Den andra gyllene regeln för användarinmatning säger att data måste filtreras när den passerar gränsen mellan opålitliga och pålitliga domäner. I det ögonblick du försummar dessa regler öppnar du dörren för XSS och andra injektionsattacker. OWASP tillhandahåller ett teknikagnostiskt dokument som definierar en uppsättning generell programvara säkerhetskodningsmetoder i ett checklistformat som kan integreras i din mjukvaruutvecklingslivscykel. Genomförandet av dessa metoder kommer att mildra de vanligaste sårbarheterna i applikationer, inklusive XSS.

Filtrera användarinmatningar: Ett av de enklaste sätten att förhindra XSS-sårbarhet är att skicka all extern data (användarinmatning) genom ett filter. Ett sådant filter skulle ta bort farliga taggar och attribut som t.exi HTML på en sida kommer skriptet att köras. Men om du inkluderar teckenkoderna i HTML-koden för en sida som visas här:

Det kommer att skriva ut texten '”, men det kommer faktiskt inte att köra skriptet. Genom att fly

Du kan göra all flykt genom att skriva koden själv. Det är dock extremt svårt att skriva din kod för att undvika användarinmatning och tillämpa den på ett adekvat och konsekvent sätt. Därför rekommenderar vi att använda befintliga bibliotek som t.ex OWASP ESAPI , Microsoft AntiXSS (bäst lämpad för Microsoft-miljö), eller webbutvecklingsramverk eller mallar som ger kontextmedveten auto-escape. Om du använder mallar för att skapa HTML i JavaScript, Stängningsmallar och Vinkel tillhandahålla inbyggda flyktmöjligheter.

Andra saker du kan göra för att förhindra XSS-sårbarhet eller minimera risken för XSS-attacker inkluderar:

• Lär dig de bästa tillvägagångssätten för din server- och klientsida-teknik, som att använda HTML-desinfektionsmedel eller konfigurera din webbläsare för att använda en proxy som skannar och fångar upp trafik som t.ex Burp proxy och råttproxy för att hjälpa till att identifiera problem.
• Använda ett webbmallsystem eller ett webbutvecklingsramverk med kontextmedveten auto-escape.
• Manuell escape av användarinmatning (om mallsystem med kontextmedveten automatisk escape inte är möjligt)
• Förstå vanliga webbläsarbeteenden som leder till XSS.

Slutsats

Det finns ingen silverkula för att upptäcka XSS i webbapplikationer. Att hitta XSS-sårbarheter kräver istället en kombination av mänsklig ansträngning (manuella kodgranskningar) och tekniskt stöd (automatiserade verktyg som sårbarhetsskannrar). En utvecklare och en applikationssäkerhetsgranskare kontrollerar koder manuellt med en textredigerare i ena änden av skalan. Ett expertsäkerhetsteam med verktyg för avancerad statisk analys (SAST) finns i andra änden av skalan.

Verktyg är bra på att bedöma stora mängder kod och peka ut möjliga problem. Ändå måste en person verifiera varje resultat för att avgöra om det är exploaterbart och möjligen utvärdera risken för organisationen. Mänskliga granskare måste fylla i de betydande blinda fläckarna, som automatiserade verktyg helt enkelt inte kan kontrollera. Ingen testmetod är idiotsäker; Så om du utför en kombination av manuella kodgranskningar och automatiska tester minskar oddsen för en XSS-sårbarhet i din applikation.

Vanliga frågor om skript över webbplatser

Var kan du vanligtvis hitta XSS-sårbarheter?

Skriptattacker över webbplatser implementeras genom användarinmatningsfält på webbplatser. Så det är viktigt att blockera automatiska inlägg på en webbplats. Anslagstavlor och kommentarsavsnitt på webbsidor är de mest mottagliga webbfunktionerna för XSS-sårbarheter.

Hur upptäcks XSS?

Det enklaste sättet att upptäcka XSS-sårbarheter är att använda en sårbarhetsskanner. Du kan implementera manuella kodkontroller på en webbsida. Om du inte är en kodningsexpert kanske du tycker att den här uppgiften är svår. Open Web Application Security Project (OWASP) rekommenderar följande:

• Se till att indata inte utförs i samma HTTP-svar som HTML eller JavaScript.
• Koda all data för överföring såvida det inte är referensvärden som har kommit från din egen databas och du är säker på att den inte kunde ha manipulerats.
• Var försiktig med hur data införs i dokumentobjektmodellen (DOM). packa data i något av följande API:er:
  
  • Node.textContent
  • document.createTextNode
  • Element.setAttribute (endast den andra parametern)

Kan WAF upptäcka XSS?

Du kan förvänta dig att en webbapplikationsbrandvägg (WAF) kommer att upptäcka och blockera en XSS-attack. Men om en sådan inträffar betyder det att din webbplats har kodningssvagheter som gör XSS-attacker möjliga och de kommer att upprepas tills du skriver om dessa processer för att stänga av sårbarheten. Använd en sårbarhetsskanner för att upptäcka säkerhetsbrister som gör skriptattacker över flera webbplatser möjliga, då behöver du inte oroa dig för eventuella försök som kan inträffa eftersom de alltid ska misslyckas.