a webhelyek közötti szkriptelés (XSS) az egyik leggyakoribb wayshacker-támadás. Az XSS biztonsági rései lehetővé teszik a rosszindulatú felhasználók számáravégezze el a JavaScript tetszőleges darabjait, amikor más felhasználók meglátogatják az Ön webhelyét.
az XSS a leggyakoribb nyilvánosan jelentett biztonsági rés, amely minden hacker eszközkészletének része.
kockázatok
a DOM-alapú XSS támadások minden kockázattal járnak, amelyek más típusú XSS támadásokkal járnak, hozzáadott bónusszal, amelyet a szerver oldalról lehetetlen felismerni.Minden olyan oldal, amely URI-töredékeket használ, potenciálisan veszélyben van az XSS támadásoktól.
védelem
a DOM-alapú XSS támadások elleni védelem annak ellenőrzése, hogy a JavaScript nem értelmezi-e az URI-töredékeket nem biztonságos módon. Számos módja van ennek biztosítására.
JavaScript keretrendszer használata
az olyan keretrendszerek, mint az AngularJS és a React olyan sablonokat használnak, amelyek explicit (és ritka) cselekvéssé teszik az ad-hoc HTML felépítését. Ez a Fejlesztőcsapatot a legjobb gyakorlatok felé tereli, és megkönnyíti a nem biztonságos műveletek felismerését.
AngularJS
a szögletes bármilyen dinamikus tartalom írt ki göndör zárójelben automatikusan megszökött, így a következő biztonságos:
<div>{{dynamicContent}}</div>legyen óvatos minden olyan kóddal, amely a dinamikus tartalmat a innerHTML attribútumhoz köti, mivel ez nem kerül automatikusan:
<div ="dynamicContent"></div> <div innerHTML="{{dynamicContent}}"></div>React
a Reactben minden göndör zárójelben írt dinamikus tartalom automatikusan megszökik, így a következők biztonságosak:
render() { return <div>{dynamicContent}</div>}a React lehetővé teszi a nyers HTML kiírását úgy, hogy tartalmat köt a dangerouslySetInnerHTML tulajdonsághoz, amelynek neve emlékeztet a biztonsági kockázatra! Vigyázzon minden olyan kódra, amely a következőképpen néz ki:
render() { return <div dangerouslySetInnerHTML={ __html: dynamicContent } />}gondosan ellenőrizze a kódját
néha a teljes JavaScript keretrendszer túl nehéz a site.In ebben az esetben rendszeresen el kell végeznie a kód-felülvizsgálatokat, hogy észrevegye a window.location.hashhivatkozást. Fontolja meg az elfogadott kódolási szabványok kidolgozását az URI-töredékek írására és értelmezésére vonatkozóan, és központosítsa ezt a logikát egy központi könyvtárban.
ha JQuery-t használ, gondosan ellenőrizze ahtml(...) funkciót használó kódokat. Ha nyers HTML-t készít a kliens oldalon a nem megbízható bemenet hátoldalán, akkor problémája lehet, függetlenül attól, hogy a bemenet URI-töredékből származik-e vagy sem. Használja a text(...) funkciót, amikor csak lehetséges.
ha közvetlenül használja a natív Dom API-kat, kerülje a következő tulajdonságok és funkciók használatát:
innerHTMLouterHTMLdocument.write
ehelyett állítsa be a szöveges tartalmat a címkéken belül, ahol csak lehetséges:
textContent
gondosan elemezze a JSON-t
ne értékelje a JSON – t, hogy natív JavaScript-objektumokká konvertálja-például a eval(...) függvény használatával. Ehelyett használja JSON.parse(...).
nem biztonságos kód észlelése Fejlesztőeszközök segítségével
a PortSwigger biztonsági cég által készített Burp Suite használható a DOM-alapú biztonsági rések észlelésére.
ne használjon URI töredékek egyáltalán!
a legbiztonságosabb kód az a kód, amely nincs ott. Ha nem kell használni URI töredékek, akkor ne! Írjon egy unit tesztet, hogy átvizsgálja a JavaScriptet a window.location.hash megemlítésére, és sikertelen legyen, ha a minta megtalálható. Ha szükség van URI töredékek használatára, akkor megvitathatja, hogyan lehet biztosítani azok biztonságos használatát.
tartalombiztonsági irányelv végrehajtása
a Modern böngészők támogatják a tartalombiztonsági irányelveket, amelyek lehetővé teszik a weboldal készítőjének, hogy szabályozza, Honnan tölthető be és futtatható a JavaScript (és más erőforrások). Az XSS támadások arra támaszkodnak, hogy a támadó képes rosszindulatú szkripteket futtatni a felhasználó weboldalán – vagy az inline <script> címkék beillesztésével valahol az oldal <html> címkéjén belül, vagy a böngészőt becsapva a JavaScript betöltésére egy rosszindulatú harmadik fél domainjéből.
ha a válaszfejlécben tartalombiztonsági házirendet állít be, akkorMondja meg a böngészőnek, hogy soha ne hajtson végre inline Javascriptet, valamint zárja le, hogy mely tartományok tárolhatják a JavaScriptet egy Oldalhoz:
azzal, hogy engedélyezed az URI-kat, ahonnan a szkriptek betölthetők, implicit módon kijelented, hogy az inline JavaScript nem engedélyezett.
a tartalombiztonsági házirend <meta> címkében is beállítható az oldal <head> elemében:
<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://apis.google.com">ez a megközelítés nagyon hatékonyan védi a felhasználókat! Előfordulhat azonban, hogy jelentős mennyiségű fegyelem szükséges ahhoz, hogy webhelye készen álljon egy ilyen fejlécre.Az Inline szkriptek címkéit rossz gyakorlatnak tekintik a modern webfejlesztésben-A tartalom és a kód keverése megnehezíti a webes alkalmazások karbantartását -, de a régebbi, régebbi webhelyeken gyakoriak.
az inline szkriptek fokozatos eltávolításához fontolja meg az ofCSP megsértésének használatát Reports.By ha report-uri irányelvet ad hozzá a házirend fejlécéhez, a böngésző értesíti Önt az irányelvek megsértéséről, ahelyett, hogy megakadályozná az inline JavaScriptet a végrehajtásban:
ez megnyugtatja Önt, hogy nincsenek elhúzódó inline szkriptek,mielőtt egyenesen betiltaná őket.
további olvasmányok
- hogyan működik a webhelyek közötti szkriptelés
- Bevezetés a tartalombiztonsági politikába
- CSP (tartalombiztonsági Szabályzat) a Mozilla Developer Network-en
- DOM alapú webhelyek közötti szkriptelési biztonsági rés
- tartalombiztonsági Szabályzat magyarázata