A CSRF ( angolul cross-site request forgery – „cross-site request forgery”, más néven XSRF) a webhely látogatói elleni támadás egy olyan típusa, amely a HTTP protokoll hiányosságait használja fel . Ha egy áldozat felkeres egy támadó által létrehozott webhelyet, akkor az áldozat nevében titokban kérést küldenek egy másik szerverre (például egy fizetési rendszer szerverére), amely valamilyen rosszindulatú műveletet hajt végre (például pénzt utal át a támadó kiszolgálójának). fiók). A támadás végrehajtásához az áldozatot hitelesíteni kell azon a szerveren, amelyre a kérést küldték, és ez a kérés nem igényelhet semmilyen megerősítést a felhasználótól., amelyet egy támadó szkript nem hagyhat figyelmen kívül vagy hamisíthat meg .
Ez a fajta támadás a közkeletű tévhittel ellentétben elég régen megjelent: az első elméleti megfontolások 1988 -ban jelentek meg [1] , az első sebezhetőségeket pedig 2000 -ben fedezték fel . Magát a kifejezést pedig Peter Watkins vezette be 2001 -ben .
A CSRF fő célja az, hogy az áldozat nevében bármilyen műveletet végrehajtsanak egy sebezhető webhelyen ( jelszó módosítása , titkos kérdés jelszó-helyreállításhoz, levelezés, rendszergazda hozzáadása stb.). A CSRF segítségével egy másik szerveren észlelt tükrözött XSS is kihasználható.
A támadást úgy hajtják végre, hogy egy hivatkozást vagy egy szkriptet helyeznek el egy weboldalon , amely olyan webhelyhez próbál hozzáférni, amelyen a támadott felhasználó ismert (vagy feltehetően már hitelesített). Például előfordulhat, hogy Alice felhasználó egy fórumot böngész, ahol egy másik felhasználó, Bob , üzenetet tett közzé. Hadd hozzon létre Bob egy <img> címkét , amelyben a kép forrásaként az URL -t adta meg , amikor rákattint egy műveletet hajt végre Alice bankjának webhelyén, például:
Bob: Szia Alice! Nézd, milyen aranyos ez a macska: <img src="http://bank.example.com/?account=Alice&amount=1000000&for=Bob">Ha Alice bankja sütiben tárolja Alice hitelesítési adatait , és ha a cookie még nem járt le, a kép letöltése során Alice böngészője cookie-t küld a Bob számlájára történő pénz utalására, amely megerősíti Alice hitelesítését. Így a tranzakció sikeresen lezárul, bár annak megerősítése Alice tudta nélkül fog megtörténni.
Minden olyan kérést, amely a szerveren lévő adatokat módosítja, valamint azokat a kéréseket, amelyek személyes vagy egyéb érzékeny adatokat adnak vissza, védeni kell.
Az ilyen típusú támadások elleni védekezés legegyszerűbb módja, ha megkövetelik a webhelyektől, hogy a legtöbb felhasználói művelet megerősítését kérjék, és ellenőrizze a HTTP_REFERER mezőt , ha a kérésben meg van adva. Ez a módszer azonban nem biztonságos és nem ajánlott [2] .
Egy másik elterjedt védelmi módszer egy olyan mechanizmus, amelyben minden felhasználói munkamenethez egy további titkos egyedi kulcsot rendelnek, amelyet a kérések teljesítésére terveztek. A titkos kulcsot ne adjuk át tisztán, például POST kéréseknél a kulcsot a kérés törzsében kell átadni, nem az oldal címében. A felhasználó böngészője elküldi ezt a kulcsot az egyes kérések paramétereinek részeként, és a szerver ellenőrzi ezt a kulcsot, mielőtt bármilyen műveletet végrehajtana. Ennek a mechanizmusnak az előnye a hivatkozó ellenőrzéshez képest, hogy garantált védelmet nyújt a CSRF támadásokkal szemben. A hátrányok közé tartozik a felhasználói munkamenetek megszervezésének lehetősége, a webhelyoldalak HTML-kódjának dinamikus generálására vonatkozó követelmény, valamint az XSS és más támadások elleni védelem szükségessége, amelyek lehetővé teszik a támadó számára, hogy egyedi kulcsot szerezzen be.
A HTTP/1.1 protokoll specifikáció [3] olyan biztonságos kérési módszereket határoz meg, mint például a GET, HEAD, amelyek nem módosíthatják a szerveren lévő adatokat. Az ilyen kérésekhez, amíg a szerver megfelel a specifikációnak, nincs szükség CSRF-védelem alkalmazására.
Érdemes lehet biztonságosan lejátszani, és minden kéréshez hozzá kell adni egy kulcsot, de ne feledje, hogy a HTTP/1.1 specifikáció [3] lehetővé teszi a törzs jelenlétét bármely kérésnél, de bizonyos kérési módoknál (GET, HEAD, DELETE) a kérés törzsének szemantikája nincs meghatározva, és figyelmen kívül kell hagyni. Ezért a kulcs csak magában az URL-ben vagy a HTTP-kérés fejlécében adható át. Meg kell védenie a felhasználót attól, hogy a kulcsot véletlenül egy URL részeként terjeszthesse, például egy olyan fórumon, ahol a kulcs elérhetővé válhat egy támadó számára. Ezért az URL-ben kulcsot tartalmazó kéréseket nem szabad címként használni, vagyis kerülni kell, hogy ilyen címre kerüljön ügyfélszkript, szerver átirányítás, űrlapművelet, az oldalon lévő hiperhivatkozás stb. az URL-ben szereplő kulcs. Csak belső kérésként használhatja őket egy XMLHttpRequest -et használó szkript vagy egy burkoló, például az AJAX .
Lényeges, hogy a kulcsot (CSRF token) ne egy konkrét kérésre vagy űrlapra szánják, hanem általában az összes felhasználói kérésre. Ezért elég egy egyszerű műveletet végrehajtó vagy egyáltalán nem végrehajtó URL-ről kiszivárogtatni egy CSRF tokent, így minden művelet, nem csak az, amelyhez a most ismert URL társítva van, elveszíti a kéréshamisítás elleni védelmet.
Létezik egy merevebb változata az előző mechanizmusnak, amelyben minden művelethez egyedi egyszeri kulcs tartozik. Ez a módszer nehezebben kivitelezhető és erőforrásigényes. A módszert egyes oldalak és portálok használják, mint például a Livejournal , a Rambler stb. 2016-ra vonatkozóan nem volt információ a merevebb opció előnyeiről az egyes munkamenetekhez egyetlen titkos kulcsot használó opcióhoz képest [4] .