Käyttäjien suojaaminen DOM-pohjaisilta XSS-hyökkäyksiltä

käyttäjien suojaaminen DOM-pohjaisilta XSS-hyökkäyksiltä

Cross-site scripting (XSS) on yksi yleisimmistä wayshackers-hyökkäyssivustoilta. XSS-haavoittuvuudet sallivat haitallisen käyttäjän käyttää mielivaltaisia JavaScript-palasia, kun muut käyttäjät vierailevat sivustossasi.

XSS on yleisin julkisesti raportoitu tietoturvahaavoittuvuus, ja osa jokaisen hakkerin työkalupakkia.

riskit

esiintyvyys harvinainen

hyödynnettävyys helppoa

vaikutus haitallista

DOM-pohjaisissa XSS-hyökkäyksissä on kaikki riskit, jotka liittyvät muuntyyppisiin XSS-hyökkäyksiin, lisäbonuksella, jota on mahdotonta havaita palvelinpuolelta.Mikä tahansa sivu, joka käyttää URI-fragmentteja, on mahdollisesti vaarassa XSS-hyökkäysten vuoksi.

suojaus

DOM-pohjaisilta XSS-hyökkäyksiltä suojautumisessa on kyse siitä, ettei JavaScript tulkitse URI-fragmentteja vaarallisella tavalla. On olemassa useita tapoja varmistaa tämä.

käytä JavaScript-kehystä

kehyksiä kuten AngularJS ja React käyttävät malleja, jotka tekevät ad-hoc-HTML: n rakentamisesta eksplisiittisen (ja harvinaisen) toiminnon. Tämä vie kehitystiimiäsi kohti parhaita käytäntöjä ja helpottaa vaarallisten toimintojen havaitsemista.

AngularJS

kulmissa mikä tahansa kihara suluissa kirjoitettu dynaaminen sisältö karkaa automaattisesti, joten seuraava on turvallinen:

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

varo koodia, joka sitoo dynaamisen sisällön innerHTML attributes, koska se ei karkaa automaattisesti:

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

Reactissa mikä tahansa kihara suluissa oleva dynaaminen sisältö poistuu automaattisesti, joten seuraava on turvallinen:

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

Reactin avulla voit kirjoittaa raakaa HTML: ää sitomalla sisältöä dangerouslySetInnerHTML – ominaisuuteen, joka on nimetty muistuttamaan tietoturvariskistä! Varo mitä tahansa koodia, joka näyttää seuraavilta:

render() { return <div dangerouslySetInnerHTML={ __html: dynamicContent } />}
Audit your Code Carefully

Sometimes a full JavaScript framework is too heavyweight for your site.In tässä tapauksessa sinun on säännöllisesti suoritettava koodikatselmuksia havaitaksesi sijaintipaikat, joiden viitenumero on window.location.hash. Harkitse sovittujen koodausstandardien keksimistä siitä, miten URI-fragmentteja kirjoitetaan ja tulkitaan, ja keskitä tämä logiikka ydinkirjastoon.

jos käytät jQuerya, tarkista huolellisesti kaikkihtml(...) – funktiota käyttävät koodit. Jos olet rakentamassa raakaa HTML-koodia asiakaspuolella epäluotettavan tulon takana, sinulla voi olla ongelma, olipa tulo peräisin URI-fragmentista tai ei. Käytä text(...) – toimintoa aina kun mahdollista.

jos käytät suoraa natiivia Dom-sovellusliittymää, vältä seuraavia ominaisuuksia ja toimintoja:

  • innerHTML
  • outerHTML
  • document.write

aseta sen sijaan tekstisisältö tageihin mahdollisuuksien mukaan:

  • textContent
jäsennä JSON huolellisesti

älä arvioi JSONIA muuttamaan sitä natiiveiksi JavaScript-objekteiksi – esimerkiksi käyttämällä eval(...) – funktiota. Käytä sen sijaan JSON.parse(...).

tunnista vaarallinen koodi kehitystyökaluilla

tietoturvayritys Portswiggerin tuottamaa Burp-sarjaa voidaan käyttää DOM-pohjaisten haavoittuvuuksien havaitsemiseen.

Älä käytä URI-fragmentteja lainkaan!

varmin koodi on koodi, jota ei ole. Jos sinun ei tarvitse käyttää URI fragmentteja, niin älä! Kirjoita yksikkötesti hakeaksesi Javascriptiltä mainintoja window.location.hash ja anna sen epäonnistua, jos kuvio löytyy. Kun on tarvetta käyttää URI-fragmentteja, voit keskustella siitä, miten varmistetaan niiden turvallinen käyttö.

Ota käyttöön Sisällönturvakäytäntö

nykyaikaiset selaimet tukevat Sisällönturvakäytäntöjä, joiden avulla web-sivun kirjoittaja voi valvoa, mistä JavaScript (ja muut resurssit)voidaan ladata ja suorittaa. XSS-hyökkäykset luottavat siihen, että hyökkääjä voi suorittaa haitallisia skriptejä käyttäjän web – sivulla-joko asettamalla inline <script> tagit jonnekin <html> – sivun tagiin tai huijaamalla selaimen lataamaan JavaScriptin haitalliselta kolmannen osapuolen verkkotunnukselta.

asettamalla content security policy in the response header, voit cantell selain koskaan suorittaa inline JavaScript, ja lukita mitkä verkkotunnukset voivat isännöidä JavaScript sivulle:

sisältö-turvallisuus-politiikka: skripti-src ’itse’ https://apis.google.com

asettamalla urit, joista skriptit voidaan ladata, ilmoitat epäsuorasti, että Inline JavaScript ei ole sallittua.

sisällön suojauskäytäntö voidaan asettaa myös <meta> tagille <head>elementin sivulla:

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

tämä lähestymistapa suojaa käyttäjiä erittäin tehokkaasti! Kuitenkin, se voi kestää huomattavan määrän kurinalaisuutta tehdä sivustosi valmis tällaisen otsikon.Inline scripts tageja pidetään huonona käytäntönä nykyaikaisessa web-kehityksessä-sisällön ja koodin sekoittaminen vaikeuttaa web-sovellusten ylläpitämistä – mutta ne ovat yleisiä vanhemmissa, perintöisissä sivustoissa.

siirtyäksesi pois inline-komentosarjoista vähitellen, harkitse tekemisiä käyttämällä ofCSP-rikkomusta Reports.By lisäämällä report-uri direktiivi oman politiikan otsikko, selain ilmoittaa sinulle mitään politiikan rikkomuksia, sen sijaan, että estettäisiin Inline JavaScriptfrom executing:

Content-Security-Policy-Report-Only: script-src’self’; raportti-uri http://example.com/csr-reports

tämä antaa sinulle varmuuden siitä,että ei ole viipyvä inline skriptejä, ennen kuin kiellät ne suoraan.

Further Reading

  • How Cross-site Scripting works
  • An Introduction to Content Security Policy
  • CSP (Content Security Policy) On the Mozilla Developer Network
  • dom Based Cross-site Scripting Vulnerability
  • Content Security Policy Explained
Cross-site Scripting

heijastunut XSS

Vastaa

Sähköpostiosoitettasi ei julkaista.