Articles

DOM-pohjainen Cross Site Scripting

Posted on

vähemmän tunnettu XSS-tekniikka

  • DOM tulee sanoista Document Object Model
  • XSS tulee sanoista cross-site scripting
  • suurin ero DOM-pohjaisen XSS: n ja muiden XSS-haavoittuvuuksien välillä on se, että hyötykuorma on upotettu asiakaspuolelle eikä palvelinpuolelle
  • DOM-pohjaiset XSS-haavoittuvuudet on siksi estettävä asiakaspuolella

Cross-site scripting (XSS) haavoittuvuudet ensin tuli tunnetuksi Cert Advisory CA-2000-02: n kautta (haittaohjelmia HTML-tunnisteita, jotka on upotettu asiakkaan Verkkopyyntöihin), vaikka näitä haavoittuvuuksia oli käytetty hyväksi aiemminkin. XSS on siis ollut olemassa jo jonkin aikaa. Ja kuten arvata saattaa, on jo ollut useita Labs artikkeleita aiheesta, kuten Cross Site Scripting – aliarvioitu vaara ja Cross-Site-Scripting ja estää Script Injection – lyhyt opas. Kuitenkin, tämä artikkeli keskittyy suurelta osin Dom perustuu cross-site scripting, termi keksi ensimmäisen kerran vuonna 2005 Amit Klein. Hän julkisti Dom-pohjaisen cross-site Scriptingin (XSS) määritelmän ja rajasi sen muista cross-site scripting-haavoittuvuuksista. Ymmärtääksesi DOM-pohjaista cross-site-skriptausta, tarvitset ensin syvemmän ymmärryksen Domista.

mitä Dom on?

Dokumenttiobjektimalli on ohjelmaliittymä, joka määrittelee dokumenttien rakenteen. Merkityksellistä meidän tarkoituksissamme on se, että DOM tarjoaa HTML-dokumenttien olio-orientoituneen esittämisen, erityisesti:

  • miten HTML-elementti esitetään objektina
  • mitä HTML-elementin attribuutit ovat
  • mitä menetelmiä voidaan käyttää HTML-elementin käyttämiseen
  • mitä HTML-elementin tapahtumia on

tämä tarkoittaa, että DOM määrittää, miten HTML-elementtejä voidaan löytää, lisätä, muuttaa tai poistaa selaimessa. Tämä tarkoittaa, että DOM tarjoaa mahdollisuuden manipuloida HTML-sivuja. Nykyään, JavaScript käytetään yleensä tällaista manipulointia.

on huomattava, että jokainen selain toteuttaa Dom-standardin eri tavalla. Tämä voi vaikuttaa siihen, toimiiko tietty Dom XSS-hyökkäys tietyssä selaimessa.

mikä on DOM-pohjainen XSS?

DOM-pohjainen XSS-haavoittuvuus syntyy, kun DOM: ää käytetään luomaan käyttäjän syötteitä sisältävää dynaamista sisältöä, jota voidaan käsitellä tarkistamatta. Tällainen hyökkäys toteutetaan JavaScriptin avulla käyttäjän selaimessa. Tässä paikat, jotka (haitallinen) käyttäjän tulo tuo DOM: iin, on nimetty lähteeksi. Paikat, joissa (haitallinen) käyttäjän syöttö voidaan suorittaa DOM: ssä, on nimetty sink: ksi.

esimerkki yksinkertaisesta cross-site scripting-haavoittuvuudesta:

<!DOCTYPE html><html> <body> <script> var source = "Hello " + decodeURIComponent(location.hash.split("#")); //Source var divElement = document.createElement("div"); divElement.innerHTML = source; //Sink document.body.appendChild(divElement); </script> </body></html>

haavoittuvuuden voi laukaista esimerkiksi seuraavalla GET-pyynnöllä:

GET www.vulnerable-website.example#<img src="test" onerror="alert('XSS')">

voimme nähdä, että tämä esimerkki edellytti decodeURIComponent – menetelmää. Tämä johtuu siitä, että nykyaikaiset selaimet koodaavat erikoismerkkejä URL-osoitteeseen, eikä hyökkäys toimisi ilman näiden erikoismerkkien dekoodausta. Muuttujan source sisältö lisätään div-elementtiin käyttämällä innerHTML. Tämä on koodin ongelmallinen elementti, koska sen osoittaminen arvoon innerHTML aiheuttaa sen mukana tulevan arvon tulkitsemisen HTML: ksi. Jos arvo sisältää JavaScriptin, tämäkin suoritetaan.

on huomattava, että tämä ei muuta palvelimen vastausta. Haitallinen muutos syntyy vain, kun JavaScript-koodi suoritetaan asiakkaan puolella, jota DOM myöhemmin muuttaa.

tunnetuimmat lähteet ja vajoamat on lueteltu alla. On huomattava, että tämä luettelo ei suinkaan ole tyhjentävä.

lähteet

  • asiakirja.URL
  • asiakirja.viite
  • sijainti
  • sijainti.href
  • sijainti.haku
  • sijainti.hash
  • sijainti.pathname

Niels

  • eval
  • setTimeout
  • setInterval
  • document.Kirjoita
  • Elementti.innerHTML

Dom-pohjaisen XSS: n estäminen

koska on tapauksia, joissa hyötykuorma ei koskaan pääse palvelimelle, tämän haavoittuvuuden estäminen ei ole palvelinpuolen tehtävä. Yllä oleva esimerkki on yksi tällainen tapaus. Syynä on se, että # – merkin jälkeen ilmestyvää sisältöä selain ei lähetä palvelimelle.

ensimmäinen ja tärkein suositus on välttää käyttäjän kontrolloimien tietojen käyttöä dynaamisessa sisällöntuotannossa aina, kun se on mahdollista. Jos tämä on täysin väistämätöntä, paras tapa estää DOM-pohjainen XSS on käyttää secure output methods (sink), jotka estävät suorittamasta mitään ilkeästi upotettu koodi. Yllä olevassa koodinpätkässä ainoa tapa tehdä koodista turvallinen on korvata .innerHTML koodilla .textContent. Tämä johtuu siitä-toisin kuin innerHtml – HTML-elementtejä textContent – menetelmässä ei suoriteta.

OWASP: n DOM-pohjaisella XSS Prevention-Lunttilapulla on runsaasti hyödyllisiä vinkkejä suojattujen dynaamisten verkkosivujen kehittämiseen Javascriptillä. Sieltä löydät myös kuvauksia kontekstista riippuvaisesta koodauksesta, jota tarvitaan aina, kun on mahdotonta siirtyä turvalliseen tulostusmenetelmään.

erot muihin XSS-haavoittuvuuksiin

tärkein ero on siinä, mihin hyökkäys on upotettu koodiin. Toisin kuin muissa cross-site scripting-haavoittuvuuksissa, koodia ei ole upotettu palvelinpuolelle, vaan pikemminkin asiakaspuolelle. Tämä tarkoittaa, että hyötykuormaa ei löydy vastauskoodista. DOM-pohjaiset XSS-haavoittuvuudet voi siis havaita vain ajonaikana tai tarkistamalla sivuston DOM.

useimmissa tapauksissa DOM-pohjaisten XSS-haavoittuvuuksien löytäminen ei ole helppoa. Yksi hyödyllinen lähestymistapa, joka käyttää staattisen koodin analyysi lähestymistapa on kuvattu artikkelissa Burp based-xss.

tekijästä

Andrea Hauser

Andrea Hauser valmistui Bachelor of Science FHO in information technology-yliopistosta Rapperswil-ammattikorkeakoulusta. Hän keskittää loukkaavaa työtään verkkosovellusten tietoturvatestaukseen ja social engineering-kampanjoiden toteuttamiseen. Hänen tutkimuskohteensa on syvärakenteiden luominen ja analysointi. (Örkki 0000-0002-5161-8658)

linkit

  • http://www.webappsec.org/projects/articles/071105.html
  • https://support.portswigger.net/customer/portal/articles/2325926-using-burp-scanner-to-test-for-dom
  • https://www.cert.org/historical/advisories/CA-2000-02.cfm
  • https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
  • https://www.w3.org/DOM/

Vastaa

Sähköpostiosoitettasi ei julkaista.