Skydda dina användare mot DOM-baserade XSS attacker

skydda dina användare mot DOM-baserade XSS attacker

Cross-site scripting (XSS) är en av de vanligaste wayshackers attack webbplatser. XSS-sårbarheter tillåter en skadlig användare att utföra godtyckliga bitar av JavaScript när andra användare besöker din webbplats.

XSS är den vanligaste offentligt rapporterade säkerhetsproblemet, och en del av varje hackers verktygslåda.

risker

prevalens sällsynt

Exploitability lätt

påverkan skadlig

DOM – baserade XSS-attacker har alla risker som är förknippade medandra typer av XSS-attacker, medaddad bonus som de är omöjliga att upptäcka från serversidan.Varje sida som använder Uri-fragment riskerar potentiellt från XSS-attacker.

skydd

skydd mot DOM-baserade XSS-attacker handlar om att kontrollera att yourJavaScript inte tolkar URI-fragment på ett osäkert sätt. Det finns ett antal sätt att säkerställa detta.

Använd ett JavaScript-ramverk

ramar som AngularJS och React använder mallar som gör konstruktion av ad hoc HTML till en explicit (och sällsynt) åtgärd. Detta kommer att driva ditt utvecklingsteam mot bästa praxis och göra osäkra operationer lättare att upptäcka.

AngularJS

i vinkel något dynamiskt innehåll som skrivs ut i lockiga parenteser kommer automatiskt att undkomma, så Följande är säkert:

 <div>{{dynamicContent}}</div>

var försiktig med någon kod som binder dynamiskt innehåll till attributet innerHTML eftersom det inte kommer att släppas automatiskt:

 <div ="dynamicContent"></div> <div innerHTML="{{dynamicContent}}"></div>
React

i React eventuellt dynamiskt innehåll som skrivs ut i lockiga parenteser kommer automatiskt att undkomma, så Följande är säkert:

render() { return <div>{dynamicContent}</div>}

React låter dig skriva ut rå HTML genom att binda innehåll till egenskapen dangerouslySetInnerHTML, som heter för att påminna dig om säkerhetsrisken! Se upp för någon kod som ser ut som följande:

render() { return <div dangerouslySetInnerHTML={ __html: dynamicContent } />}
granska din kod noggrant

ibland är ett fullständigt JavaScript-ramverk för tungt för din site.In i så fall måste du regelbundet genomföra kodrecensioner för att upptäcka platserden referensen window.location.hash. Överväg att komma med överenskomna kodningsstandarder för hur URI-fragment ska skrivas och tolkas och centralisera denna logik i ett kärnbibliotek.

om du använder JQuery, kontrollera noggrant vilken kod som använder funktionenhtml(...). Om du konstruerar raw HTML på klientsidan på baksidan av otillförlitlig inmatning kan du ha problem, oavsett om inmatningen kommer från ett URI-fragment eller inte. Använd funktionen text(...) när det är möjligt.

om du använder direct de inhemska DOM API: erna, undvik att använda följande egenskaper och funktioner:

  • innerHTML
  • outerHTML
  • document.write

Ställ istället in textinnehåll I taggar där det är möjligt:

  • textContent
analysera JSON noggrant

utvärdera inte JSON för att konvertera den till inbyggda JavaScript – objekt-till exempel genom att använda funktionen eval(...). Använd istället JSON.parse(...).

Upptäck osäker kod med hjälp av utvecklingsverktyg

Burp-sviten, som produceras av säkerhetsföretaget PortSwigger,kan användas för att upptäcka DOM-baserade sårbarheter.

Använd inte URI-fragment alls!

den säkraste koden är koden som inte finns där. Om du inte behöver använda URI-fragment, gör det inte! Skriv ett enhetstest för att skanna ditt JavaScript för omnämnanden av window.location.hash och få det att misslyckas om mönstret hittas. När det finns behov av att använda URI-fragment kan du diskutera hur man säkerställer säker användning.

implementera en Innehållssäkerhetspolicy

moderna webbläsare stöder Innehållssäkerhetspolitiksom gör det möjligt för författaren till en webbsida att styra var JavaScript (och andra resurser)kan laddas och köras från. XSS-attacker förlitar sig på att angriparen kan köra skadliga skript på en användares webbsida – antingen genom att injicera inline <script>-taggar någonstans inom taggen <html> på en sida, eller genom att lura webbläsaren att ladda JavaScript från en skadlig tredjepartsdomän.

genom att ställa in en innehållssäkerhetspolicy i svarshuvudet kan duberätta för webbläsaren att aldrig köra inline JavaScript och att låsa ner vilka domäner som kan vara värd för JavaScript för en sida:

innehåll-säkerhet-Policy: script – src ’self’ https://apis.google.com

genom att vitlista Uri: erna från vilka skript kan laddas anger du implicit att inline JavaScript inte är tillåtet.

innehållssäkerhetsprincipen kan också ställas in i en <meta> – tagg i elementet <head>på sidan:

<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://apis.google.com">

detta tillvägagångssätt skyddar dina användare mycket effektivt! Det kan dock taen stor mängd disciplin för att göra din webbplats redo för en sådan rubrik.Inline skript taggar anses dålig praxis i modern webbutveckling-blanda innehåll och kod gör webbapplikationer svåra att underhålla-men arecommon i äldre, äldre webbplatser.

för att migrera bort från inline-skript stegvis, överväga att använda ofCSP-överträdelse Reports.By om du lägger till ett report-uri – direktiv i din policyrubrik kommer webbläsaren att meddela dig om eventuella policyöverträdelser, snarare än att förhindra inline-javascript från att exekvera:

innehåll-säkerhet-Policy-endast rapport: script – src ’self’; rapport-uri http://example.com/csr-reports

detta kommer att ge dig försäkran om att det inte finns några kvardröjande inline skript,innan du förbjuda dem direkt.

Vidare läsning

  • hur Cross-site Scripting fungerar
  • en introduktion till Content Security Policy
  • CSP (Content Security Policy) på Mozilla Developer Network
  • DOM baserad Cross-site Scripting sårbarhet
  • Content Security Policy förklaras
Cross-site Scripting

reflekterad XSS

Lämna ett svar

Din e-postadress kommer inte publiceras.