Ez a cikk foglalkozik a jól ismert Oauth sebezhetőségekkel. Az olvasók megismerik, hogyan kell biztonságos és biztonságos engedélyt végrehajtani a webes alkalmazásban.
Az Oauth megbízható protokoll, de a biztonság mértéke nagymértékben függ a webfejlesztők tudatosságától az engedélyezés végrehajtása során. Ez teszi ezt a témát, ami rendkívül fontos az információbiztonsági szakemberek számára. A felhasználók számára magas szintű védelmet kell biztosítaniuk. Itt az ideje, hogy megismerjék a hatékony szakembereket, akik segítenek csökkenteni a szegény értékesítési OAuth-t.
BevezetésAz Oauth 2.0 protokollt jelenleg széles körben használják különböző alkalmazásokban. Használata, egy kényelmes felhasználói felület elérhetővé válik, könnyebb hitelesítés és engedélyezés a hagyományos módszerekhez képest a felhasználónév és a jelszó megadásához. A megfelelő és átgondolt kivitelezés, az OAuth protokoll biztonságosabb lesz, mint a hagyományos engedélyt, mivel a felhasználóknak nem kell, hogy osszák meg a számviteli adatokat egy harmadik fél által készített alkalmazás eléréséhez egy adott erőforrás. A felhasználók gyakran inkább bejelentkeznek a Google Fiókja, Facebook vagy LinkedIn használatával, ahelyett, hogy új fiókot hozna létre minden alkalommal, amikor regisztrálnia kell egy webhelyen. Így az Oauth protokoll nagymértékben leegyszerűsíti az életünket.
Általában a népszerű Oauth szolgáltatók nagyon megbízhatóak. Jelentkezzen be a Google-val vagy a Facebook-fiókkal egy bizonyos biztonságérzetet inspirálja, és helyes. A protokollt a szakértők gondosan tesztelik. Minden rendelkezésre álló sebezhetőséget mindig gyorsan javítja a fejlesztői csapat. Azonban érdemes megjegyezni, hogy a teljes biztonság érzése hamis lehet.
Az OAuth szolgáltatók sok okból sok okot hagytak az alkalmazásfejlesztők számára, hogy megvédjék programjaik biztonságát. Valójában az eredetileg védett OATH szolgáltatás, amely helytelenül megvalósult a telepítés folyamatában, könnyű célkitűzhet a behatolók számára. Az ilyen aggodalom a felhasználók személyes adatainak lopásához vezet.
Ezután figyelembe kell vennie az Oauth-jegyzőkönyvet végrehajtó harmadik fél által okozott leggyakoribb sebezhetőségeket, amelyek a felhasználók engedélyezésére szolgálnak. Emlékeztetni kell arra, hogy maga a jegyzőkönyv biztonságos és megbízható. Csak a helytelen megvalósítás után sebezhetővé válik a hacker támadásokhoz.
Oauth tockey lopás a hivatkozási fejléc segítségévelHa az alkalmazás engedélyezi az Engedélyt a felhasználó nevében az Oauth szerveren, akkor egy személy megkapja a kódot, hogy belépjen és küldjön vissza a kiszolgálóra a későbbi ellenőrzéshez. Ha a munka során a felhasználó átirányításra kerül egy másik oldalra, akkor a kód a HTTP kérés "referer" fejlécében látható. Így a kód esik a külső weboldalra, amely veszélyezteti az Oauth szerveren regisztrált felhasználói adatokat.
Megjegyzés: A Hivatkozás fejléce egy HTTP lekérdezés fejléc továbbítja az URL host, ahonnan a kérést.
A sérülékenység következményeinek enyhítéséhez a fejlesztőnek biztosítania kell, hogy webes alkalmazása ne tartalmazzon HTML injekciót. Ha az injekciókat észlelték, a támadó könnyedén beállíthatja a képcímkét a webszerverére, és megtalálja a módját a felhasználó átirányítására. Így meg fogja kapni a lehetőséget, hogy ellopja a kódot a HTTP kérés "referer" fejlécéről.
Outh ToCyKey lopás az Redirect_URI paraméter használatávalAz alkalmazás megindítja az engedélyezési folyamatot az Oauth szerverre vonatkozó kérés elküldésével:
https://www.example.com/signin/authorize = [/signin] [/Redirect_uri=htpps://demo.example.com/loginsuccessful.
A lekérdezés mindig tartalmazza az Oauth kiszolgáló által használt "redirect_uri" paramétert, hogy küldjön tokeneket az alkalmazáshoz, miután a felhasználó hozzájárult. Ha a paraméter értékét nem ellenőrzik vagy nem ellenőrzik, a támadó könnyen megváltoztathatja és átirányítja a kérelmet a webhelyére, ahol különleges programot használ a token feldolgozására és korlátozott erőforráshoz való hozzáféréshez.
https://www.example.com/signin/authorize _...]&redirect_uri=htpps://localhost.evil.com.
Néha hasonló URL-eket blokkolnak. A támadó átirányíthatja a kapott adatokat a nyitott URL-ről, így:
https://www.example.com/oauth20_authorize.srf? [.... [/acredirect_uri=htpps://accounts.google.com/backtoouthsubtarget?next=httpset://evil.com.
Vagy ez:
https://www.example.com/oauth2/authorize? [...]% IRECT_URI = https% 3a% 2f% 2fapps.facebook.com% 2Fattacker% 2f.
Az Oauth végrehajtásakor soha nem tartalmazhat teljes domaineket a fehér listában. Csak néhány URL-t kell hozzáadni a "Redirect_uri" -ra, amely nem irányítja az átirányítás megnyitására irányuló kérést.
Cross-line kérések hamisításaAz Intersight kérés hamisítása akkor fordulhat elő, ha egy támadó sikerül, hogy az áldozatot kattints az ő linkjére, és így hozza létre azt a kérést, hogy nem fog generálni. Hamis keresztvonalban kérések általában lágyított a CSRF token, amely kapcsolatban van a felhasználói munkamenet. Segít az alkalmazásnak, hogy ellenőrizze a kérelmet küldött személy személyét. Az Oauth protokoll "State" paramétere CSRF tokenként szolgál.
Érdemes megnézni, hogy a CSRF támadást az Oauth-en végezzük, és az "állam" paraméter használható a sérülékenység hatásainak enyhítésére.
A Hacker megnyitja a webes alkalmazást, és elindítja az engedélyezési folyamatot a szolgáltatóhoz Oauth használatával. Az alkalmazás kéri a szolgáltatót, amely hozzáférést kell biztosítani. A hacker átirányítja a szolgáltató webhelyét, ahol általában be kell írnia a felhasználónevét és jelszavát a hozzáférés engedélyezéséhez. Ehelyett a hacker elkapja és megakadályozza ezt a kérést, és megmenti az URL-jét. Hacker valahogy az áldozat megnyitja ezt az URL-t. Ha az áldozat fiókjával lépett be a Szolgáltató rendszerbe, akkor a hitelesítő adatait az engedélyezési kód kiadására használják. Az engedélyezési kód hozzáférést biztosít a hozzáférési tokenhez. Most a kérelemben szereplő Hacker-fiók engedélyezett. Hozzáférhet az áldozat számlájához.
Szóval, hogyan akadályozhatom ezt a helyzetet az "állam" paraméterrel?
Az alkalmazásnak olyan értéket kell létrehoznia, amely valahogy a forrásszámla alapján (például használja a Felhasználói Session HASH kulcsot). Nem olyan fontos, hogy mi az, a legfontosabb dolog az, hogy az érték egyedülálló és privát információkat készít az eredeti felhasználóról. Az "állam" paraméterhez van rendelve.
Ezt az értéket átirányításkor továbbítják a Szolgáltatónak. Most a hacker felkéri az áldozatot, hogy kinyitja az URL-t, amelyet megtartott.
Az engedélyezési kódot az ülésen az Ügyfélnek az "Állam" paraméterrel kell elküldeni.
Az ügyfél paraméterértéket generál egy munkamenet-információ alapján, és összehasonlítja azt az "állami" értékkel, amelyet az engedélyezési kérelemből a Szolgáltatónak küldtek. Ez az érték nem egyezik az "állami" paraméterrel a lekérdezésben, mivel csak az aktuális munkamenetről szóló információk alapján jött létre. Ennek eredményeképpen a kapott értéket a rendszer nem fogadja el.
Az OAuth végrehajtása során más sérülékenységek közé tartozik az XSS (Cross-site scripting) végrehajtásának képessége az "Redirect_uri" paraméterrel, az Oauth privát kulcs beállítása (a kulcsot néha a mobilalkalmazás dekomplexálásakor) és az Engedélyezési kód szabálysértése esetén (amikor Az engedélyezési kód több mint egyszer használható több hozzáférési token kiadására). Ezek a sérülékenységek kevésbé gyakoriak, mint a fent leírtak, de nem tesz kevésbé veszélyesnek. A fejlesztőnek ismernie kell az összes szükséges gyakorlatot, hogy biztosítsa a webes alkalmazás megbízható működését.
A lefordított cikk szerzője: Simon Saliba.
Fontos! Kizárólag tudományos célokra. Kérjük, tartsa be a jogszabályokat, és ne alkalmazza ezt az információt illegális célokra.
További érdekes anyag a Cisoclub.ru-n. Feliratkozás ránk: Facebook | VK | Twitter | Instagram | Telegram | Zen | Messenger | ICQ új | YouTube | Impulzus.