Beskyttelse af dine brugere mod DOM-baserede SSS-angreb

beskyttelse af dine brugere mod SSS-angreb

Cross-site scripting (SSS) er en af de mest almindelige måder at angribe hjemmesider på. Sårbarheder tillader en ondsindet bruger at udføre vilkårlige bidder af JavaScript, når andre brugere besøger din hjemmeside.

SSS er den mest almindelige offentligt rapporterede sikkerhedssårbarhed og en del afhver hackers værktøjskasse.

risici

prævalens sjælden

Udnyttelighed let

indvirkning skadelig

DOM – baserede angreb har alle de risici, der er forbundet med andre typer angreb, med den tilføjede bonus, som de er umulige at opdage fra serversiden.Enhver side, der bruger Uri-fragmenter, er potentielt i fare for angreb.

beskyttelse

beskyttelse mod DOM-baserede angreb er et spørgsmål om at kontrollere, at yourJavaScript ikke fortolker Uri-fragmenter på en usikker måde. Der er en række måder at sikre dette på.

brug en JavaScript-ramme

rammer som AngularJS og React bruger skabeloner, der gør konstruktion af ad hoc HTML til en eksplicit (og sjælden) handling. Dette vil skubbe dit udviklingsteam mod bedste praksis og gøre usikre operationer lettere at opdage.

AngularJS

i vinkel ethvert dynamisk indhold skrevet ud i krøllede parenteser vil automatiskblive undsluppet, så følgende er sikkert:

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

vær forsigtig med enhver kode, der binder dynamisk indhold til attributten innerHTML, da det ikke vil blive undsluppet automatisk:

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

i React vil ethvert dynamisk indhold, der er skrevet ud i krøllede parenteser, automatisk blive undsluppet, så følgende er sikkert:

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

React giver dig mulighed for at skrive rå HTML ved at binde indhold til egenskaben dangerouslySetInnerHTML, som er navngivet for at minde dig om sikkerhedsrisikoen! Pas på enhver kode, der ligner følgende:

render() { return <div dangerouslySetInnerHTML={ __html: dynamicContent } />}
gennemgå din kode omhyggeligt

nogle gange er en fuld JavaScript-ramme for tungvægt til din site.In i så fald skal du regelmæssigt foretage kodevurderinger for at få øje på lokaliteterden reference window.location.hash. Overvej at komme med aftalte kodningsstandarder for, hvordan URI-fragmenter skal skrives og fortolkes, og centraliser denne logik i et kernebibliotek.

hvis du bruger Jfor, skal du omhyggeligt kontrollere enhver kode, der bruger funktionen html(...). Hvis du konstruerer rå HTML på klientsiden på bagsiden af ikke-tillid til input, kan du have et problem, uanset om input kommer fra et Uri-fragment eller ej. Brug funktionen text(...), når det er muligt.

hvis du bruger direct the native DOM API ‘ er, skal du undgå at bruge følgendeegenskaber og funktioner:

  • innerHTML
  • outerHTML
  • document.write

Indstil i stedet tekstindhold inden for tags, hvor det er muligt:

  • textContent
Parse JSON omhyggeligt

Evaluer ikke JSON for at konvertere det til native JavaScript – objekter-for eksempel ved at bruge funktionen eval(...). Brug i stedet JSON.parse(...).

registrer usikker kode ved hjælp af udviklingsværktøjer

Burp Suite, produceret af sikkerhedsfirmaet Portsviger,kan bruges til at opdage DOM-baserede sårbarheder.

brug slet ikke Uri-fragmenter!

den mest sikre kode er den kode, der ikke er der. Hvis du ikke behøver at bruge Uri-fragmenter, skal du ikke gøre det! Skriv en enhedstest for at scanne dit JavaScript for omtale af window.location.hash, og få det til at mislykkes, hvis mønsteret findes. Når der er behov for at bruge Uri-fragmenter, kan du diskutere, hvordan du sikrer deres sikre brug.

Implementer en Indholdssikkerhedspolitik

moderne brugere understøtter Indholdssikkerhedspolitikker, der gør det muligt for forfatteren af en hjemmeside at kontrollere, hvor JavaScript (og andre ressourcer)kan indlæses og udføres fra. Angrebene er afhængige af, at angriberen kan køre ondsindede scripts på en brugers hjemmeside – enten ved at indtaste inline <script> tags et eller andet sted i <html> tagget på en side eller ved at narre brugeren til at indlæse JavaScript fra et ondsindet tredjepartsdomæne.

ved at indstille en indholdssikkerhedspolitik i svaroverskriften kan du ikke fortælle bro. ser til aldrig at udføre inline JavaScript og låse ned, hvilke domæner der kan være vært for JavaScript for en side:

indhold-sikkerhed-politik: script-src ‘self’ https://apis.google.com

ved at hvidliste de Uri ‘ er, hvorfra scripts kan indlæses, angiver du implicit, at inline JavaScript ikke er tilladt.

indholdssikkerhedspolitikken kan også indstilles i et <meta> tag i <head>elementet på siden:

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

denne tilgang vil beskytte dine brugere meget effektivt! Det kan dog tage en betydelig mængde disciplin at gøre din side klar til en sådan overskrift.Inline scripts-tags betragtes som dårlig praksis i moderne internetudvikling-blanding af indhold og kode gør internetapplikationer vanskelige at vedligeholde-men er almindelige på ældre, ældre sider.

for at migrere væk fra inline scripts trinvist, overveje makings brug ofCSP overtrædelse Reports.By tilføjelse af et report-uri direktiv i din politikhoved, vil bro. ser underrette dig om eventuelle overtrædelser af politikken snarere end at forhindre inline javaskript fra at udføre:

indhold-sikkerhed-politik-kun rapport: script-src’selv’; betænkning-uri http://example.com/csr-reports

dette vil give dig forsikring om,at der ikke er nogen dvælende inline scripts, før du forbyder dem direkte.

yderligere læsning

  • Sådan fungerer Scripting på tværs af steder
  • en introduktion til Indholdssikkerhedspolitik
  • CSP (Indholdssikkerhedspolitik) på Udviklernetværket
  • dom-baseret sårbarhed på tværs af steder
  • Indholdssikkerhedspolitik forklaret
Cross-site Scripting

reflekteret

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.