Beskytte Brukerne Mot DOM-Baserte XSS-angrep

Beskytte Brukerne Mot DOM-Baserte XSS-angrep

Cross-site scripting (XSS) Er en av de vanligste wayshackers angrep nettsteder. Xss sårbarheter tillater en ondsinnet bruker åutfør vilkårlige biter Av JavaScript når andre brukere besøker nettstedet ditt.

XSS ER det vanligste offentlig rapporterte sikkerhetsproblemet, og en del avhver hackers verktøykasse.

Risikoer

Prevalens Sjeldne

Utnyttbarhet Lett

Impact Skadelig

DOM-baserte xss-angrep har alle risikoene forbundet med andre TYPER xss-angrep, medlagt til bonus at de er umulige å oppdage fra serversiden.Enhver side som bruker URI-fragmenter, er potensielt utsatt for xss-angrep.

Beskyttelse

Beskyttelse mot DOM-baserte xss-angrep handler om å kontrollere at dinjavascript ikke tolker URI-fragmenter på en usikker måte. Det finnes en rekke måter å sikre dette på.

Bruk Et JavaScript-Rammeverk

Rammeverk Som AngularJS og React bruker maler som gjør bygging av ad hoc HTML til en eksplisitt (og sjelden) handling. Dette vil presse utviklingsteamet mot beste praksis, og gjøre usikre operasjoner enklere å oppdage.

AngularJS

I Vinkel vil ethvert dynamisk innhold skrevet ut i krøllete parenteser automatisk bli rømt, så følgende er trygt:

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

vær forsiktig med kode som binder dynamisk innhold til innerHTML attributesince som ikke vil bli rømt automatisk:

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

I React vil ethvert dynamisk innhold skrevet ut i krøllete parenteser automatisk bli rømt, så følgende er trygt:

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

React lar deg skrive ut rå HTML ved å binde innhold til egenskapen dangerouslySetInnerHTML, som er oppkalt for å minne deg om sikkerhetsrisikoen! Se opp for noen kode som ser ut som følgende:

render() { return <div dangerouslySetInnerHTML={ __html: dynamicContent } />}
Kontroller Koden Nøye

noen Ganger er et Fullt JavaScript-rammeverk for tungvekt for Din site.In i så fall må du regelmessig gjennomføre kodevurderinger for å finne steder som referanse window.location.hash. Vurder å komme opp med avtalte kodingsstandarder for hvordan URI-fragmenter skal skrives og tolkes, og sentralisere denne logikken i et kjernebibliotek.

hvis Du bruker JQuery, sjekk nøye hvilken kode som bruker funksjonenhtml(...). Hvis du bygger rå HTML på klientsiden på baksiden av uklarert inngang, kan det hende du har et problem, om inngangen kommer fra ET URI-fragment eller ikke. Bruk text(...) – funksjonen når det er mulig.

hvis du bruker direct de opprinnelige DOM-Apiene, må du unngå å bruke følgendeegenskaper og funksjoner:

  • innerHTML
  • outerHTML
  • document.write

i Stedet angi tekstinnhold i koder der det er mulig:

  • textContent
Analyser JSON Nøye

ikke evaluer JSON for å konvertere DEN til innfødte JavaScript-objekter, for eksempel ved å bruke funksjonen eval(...). Bruk i stedet JSON.parse(...).

Oppdag Usikker Kode Ved Hjelp Av Utviklingsverktøy

Burp-Pakken, produsert av sikkerhetsfirmaet PortSwigger,kan brukes til å oppdage DOM-baserte sårbarheter.

Ikke Bruk URI-Fragmenter i Det hele tatt!

den sikreste koden er koden som ikke er der. Hvis DU ikke trenger Å bruke URI fragmenter, så ikke! Skriv en enhet test for å skanne JavaScript for nevner av window.location.hash, og har det mislykkes hvis mønsteret er funnet. NÅR DET er behov FOR Å bruke uri-fragmenter, kan du diskutere hvordan du sikrer sikker bruk.

Implementer En Policy For Innholdssikkerhet

Moderne nettlesere støtter Retningslinjer For Innholdssikkerhet Som tillater forfatteren av en nettside å kontrollere hvor JavaScript (og andre ressurser) kan lastes og kjøres fra. XSS-angrep er avhengige av at angriperen kan kjøre ondsinnede skript på en brukers nettside-enten ved å injisere inline <script> – tagger et sted innenfor <html> – taggen på en side, eller ved å lure nettleseren til å laste JavaScript fra et skadelig tredjepartsdomene.

ved å angi en sikkerhetspolicy for innhold i svaroverskriften, kan dufortell nettleseren om å aldri kjøre Innebygd JavaScript, og å låse ned hvilke domener Som Kan være Vert For JavaScript For en side:

Innhold-Sikkerhet-Policy: script-src ‘selv’ https://apis.google.com

ved å hviteliste Uri – ene som skript kan lastes inn fra, sier du implisitt at Inline JavaScript ikke er tillatt.

sikkerhetspolicyen for innhold kan også angis i en <meta> – kode i <head> – elementet på siden:

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

denne tilnærmingen vil beskytte brukerne svært effektivt! Det kan imidlertid taen betydelig mengde disiplin for å gjøre nettstedet ditt klart for en slik overskrift.Inline skript koder anses dårlig praksis i moderne web-utvikling-blande innhold og kode gjør web-applikasjoner vanskelig å vedlikeholde – men arecommon i eldre, eldre områder.

for å migrere vekk fra inline-skript trinnvis, bør du vurdere å bruke csp-Brudd Reports.By når du legger til et report-uri – direktiv i policyoverskriften, vil nettleseren varsle deg om eventuelle brudd på retningslinjene, i stedet for å forhindre Inline Javascriptfra å utføre:

Innhold-Sikkerhet-Policy-Bare Rapport: script-src’self’; rapport-uri http://example.com/csr-reports

Dette vil gi deg forsikring om at det ikke er dvelende inline skript, før du forby dem direkte.

Videre Lesing

  • Hvordan Skripting på tvers av nettsteder fungerer
  • En Introduksjon Til Sikkerhetspolicy for Innhold
  • CSP (Sikkerhetspolicy For Innhold) På Mozilla Developer Network
  • Dom-Basert Skripting På Tvers Av nettsteder
  • Sikkerhetspolicy For Innhold Forklart
Skripting på tvers av nettsteder

Reflektert XSS

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.