Kolmanda osapoole skriptid: kinnitage, piirake või eemaldage

Iga kolmanda osapoole skript teie kassa-, sisselogimis- või admin-lehel töötab samade õigustega nagu kasutaja, kes selle laadis. Kui skripti serveeriv host satub ründaja kätte, saab ründaja needsamad õigused, nagu XSS-i puhul. Lahendus algab teadmisest, millised skriptid üldse laetakse: eemaldage, mida saate, ja ülejäänud kinnitage või piirake.

Teadke, mis tundlikel lehtedel töötab

OWASP-i cheat sheet kolmanda osapoole JavaScripti kohta nimetab kolm riski: kontrolli kaotus kliendirakenduse muudatuste üle, suvalise koodi täitmine klientide süsteemides ja tundliku teabe lekkimine kolmandatele osapooltele. Näidetena toob see välja 2018. aasta Ticketmasteri intsidendi ja ClearSky Magecart-uuringu makseandmete varguse kohta.

Koostage nimekiri leht lehe haaval, alustades kassast, sisselogimisest ja administ. Märkige iga skripti kohta URL, ärivaldkonna vastutaja, olemasolu põhjus ja see, kuidas skript lehele jõuab. OWASP kirjeldab kolme tarneteed: müüja kood on kleebitud otse lehele, <script src> viitab müüja serverile või skript tuleb kaudselt tag manageri kaudu.

Tag manager on neist kõige vähem nähtav. See võib tagastada skripte mitmelt müüjalt ning töötajad saavad veebiliidese kaudu muuta, mida see tagastab, ilma et teie koodi puudutataks. Muudatused jõuavad kasutajateni järgmise lehelaadimisega ja kood on tavaliselt obfuskeeritud.

HTML-i lähtekoodis neid skripte ei näe. Avage arendajatööriistad, minge vahekaardile Network, käige läbi kassa ja sisselogimine ning kirjutage üles iga host, mis skripte serveerib.

Esmalt eemaldage, seejärel peegeldage

Küsige iga kirje vastutajalt, kas seda skripti on sellel lehel üldse vaja. Turundusmärgendile sisselogimislehel või admin-paneelis on harva head vastust.

Skriptide jaoks, mis jäävad, nimetab OWASP kaitsemeetmena omaenda peegeldust (mirroring). Hoiate üle vaadatud koopiat ise, nii et kolmas osapool ei saa seda muuta ning müüja ei saa enam külastaja IP-aadressi, referrerit ega küpsiseid. Hinnaks on hooldus: peegeldatud koopia ei saa müüja parandusi, seega peab keegi vastutama selle uuesti ülevaatamise ja värskendamise eest.

Hüljatud müüjad on eraldi probleem. Kui skripti majutava domeeni registreering aegub, sest müüja läks pankrotti või loobus projektist, saab keegi domeeni uuesti registreerida ja avaldada pahatahtlikku koodi. Surnud müüja teie nimekirjas on iseenesest leid.

Kinnitage säilitatavad skriptid Subresource Integrity'ga

Subresource Integrity (SRI) võimaldab lehel määrata räsi, millega fail peab ühtima. Brauser võrdleb allalaaditud faili selle räsiga enne skripti täitmist või stiilifaili rakendamist ning tagastab erinevuse korral võrguvea. MDN-i SRI juhend annab räsi genereerimiseks järgmise käsu:

cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A

Lisage väljundi ette sha384- ja paigutage see elementi:

<script src="https://cdn.example.com/script.js"
  integrity="sha384-..."
  crossorigin="anonymous"></script>

Märgendile esitatakse mõned nõuded:

• Atribuut crossorigin on kohustuslik. Brauser keeldub SRI-st no-cors päringute puhul, seega ilma selleta märgend alati ebaõnnestub.
• CDN peab saatma päise Access-Control-Allow-Origin. Paljud saadavad väärtuse *.
• Räsisid võib loetleda mitu. Brauser kasutab ainult kõige tugevama olemasoleva algoritmi räsisid (SHA-256, SHA-384, SHA-512 kasvavas järjekorras) ja aktsepteerib faili, kui ükskõik milline neist ühtib. Nii saate uuenduse ajal lubada kaht versiooni. W3C spetsifikatsioon kirjeldab sama käitumist.

SRI sobib failidele, mis püsivad samasugused, kuni te neid ise muudate. Skript, mida müüja oma suva järgi muudab, ebaõnnestub kontrollis pärast iga muudatust, ja tag manageri konteiner on just selline skript. Piirake, kes saab sinna avaldada, ning hoidke see oma kõige tundlikumatelt lehtedelt eemal.

Piirake Content Security Policy'ga

SRI määrab, mida konkreetne fail peab sisaldama. Content Security Policy (CSP) määrab, kust skriptid üldse tulla tohivad. MDN-i CSP juhend soovitab edastada seda päises Content-Security-Policy kõigis vastustes, mitte ainult põhidokumendis.

Tundliku lehe lähtepunkt loetleb hostid, mida te tegelikult kasutate:

Content-Security-Policy: script-src 'self' cdn.example.com; object-src 'none'

Kui direktiiv script-src või default-src on olemas, on inline JavaScript blokeeritud, kui te seda ei luba. MDN soovitab vältida väärtust 'unsafe-inline', sest see kahjustab CSP eesmärki suuresti. Kui vajate inline-skripte, kasutage nonce'i: see genereeritakse iga vastuse jaoks eraldi, on ettearvamatu ja lisatakse malli abil. Staatiliste lehtede jaoks soovitab MDN selle asemel räsisid ning siis vajavad ka välised skriptid atribuuti integrity.

OWASP ütleb selgelt, et data layer ei ole liivakast, sest tag manageri konteinerid võivad käivitada kohandatud JavaScripti ja HTML-i. Piirake avaldamisõigust ja vaadake muudatused üle nagu rakenduse koodi.

Leidke lüngad saiti lõhkumata

Päis Integrity-Policy paneb brauseri blokeerima skriptid, millel puudub atribuut integrity või mis laetakse režiimis no-cors. Alustage report-only versiooniga:

Integrity-Policy-Report-Only: blocked-destinations=(script), endpoints=(integrity-endpoint)

Lõpp-punkt vajab vastavat päist Reporting-Endpoints. Rikkumised saabuvad aruannetena tüübiga integrity-violation, kus on nimetatud blokeeritud URL. Kinnitatud skriptid aruannetest kaovad, seega need ei ole täielik skriptide nimekiri.

Kui aruandeid enam ei tule, on MDN-i sõnul blokeerimise lubamine ohutu ja kasutajatele nähtavaid tõrkeid ei teki. Tag manageri konteiner, mida te kinnitada ei saa, genereerib aruandeid edasi, seega jäävad lehed, mis sellist konteinerit laadivad, report-only režiimi. Oma lehtede saadetavaid päiseid saate vaadata meie HTTP päiste kontrollijaga.

Kust alustada

1. Koostage kassa-, sisselogimis- ja admin-lehtede nimekiri Network-vahekaardi põhjal ning märkige iga skripti juurde vastutaja, eesmärk ja tarnetee.
2. Eemaldage kirjed, mida keegi ei suuda põhjendada, eriti sisselogimis- ja admin-lehtedelt, ning märkige iga müüja, kelle domeen tundub hüljatud.
3. Peegeldage failid, mille eest olete valmis vastutama ja mida uuesti üle vaatama. Kinnitage iga skript, mille jätate: genereerige SHA-384 räsid, lisage integrity ja crossorigin="anonymous" ning testige staging-keskkonnas.
4. Võtke skriptide jaoks kasutusele Integrity-Policy-Report-Only ja lugege aruandeid. Jõustage Integrity-Policy alles siis, kui igal lehe skriptil on atribuut integrity, ning hoidke tag manageri lehed report-only režiimis.
5. Testige staging-keskkonnas päist Content-Security-Policy direktiividega script-src ja object-src 'none', sest see blokeerib inline-skriptid. Piirake, kes saab teie tag manageris avaldada. Välise kontrolli jaoks saab neid lehti hõlmata penetratsioonitest.