10 leggyakoribb webes biztonsági rés

Az OWASP vagy az Open Web Security Project egy non-profit jótékonysági szervezet, amely a szoftverek és webalkalmazások biztonságának javítására összpontosít.

A szervezet közzéteszi a legfontosabb webes biztonsági rések listáját a különböző biztonsági szervezetektől származó adatok alapján.

A webes biztonsági rések prioritása a kihasználhatóság, az észlelhetőség és a szoftverre gyakorolt ​​hatás függvényében történik.

• Kihasználhatóság –Mi szükséges a biztonsági rés kihasználásához? A legmagasabb kihasználhatóság, ha a támadás csak webböngészőt igényel, a legalacsonyabb pedig a fejlett programozás és eszközök.
• Észlelhetőség - Mennyire könnyű észlelni a fenyegetést? A legmagasabb az URL-en, az űrlapon vagy a hibaüzeneten megjelenő információ, a legalacsonyabb pedig a forráskód.
• Ütés vagy sérülés –Mekkora kár keletkezik, ha a biztonsági rést leleplezik vagy megtámadják? A legmagasabb a teljes rendszerösszeomlás, a legalacsonyabb pedig a semmi.

Az OWASP Top 10 fő célja, hogy felvilágosítsa a fejlesztőket, tervezőket, menedzsereket, építészeket és szervezeteket a legfontosabb biztonsági résekről.

Az OWASP Top 10 szerint a 10 legfontosabb biztonsági rés a következő:

SQL Injection

Description

Az injekció egy biztonsági rés, amely lehetővé teszi a támadók számára, hogy módosítsák a háttérrendszert SQL nyilatkozatokat a felhasználó által megadott adatok manipulálásával.

Az injektálás akkor történik, amikor a felhasználói bevitelt a parancs vagy lekérdezés részeként elküldik egy tolmácsnak, és az értelmezőt nem kívánt parancsok végrehajtására csalja ki, és hozzáférést biztosít jogosulatlan adatokhoz.

Az SQL parancs, amely webalkalmazás által végrehajtott futtatásakor a háttéradatbázist is megjelenítheti.

Következmény

• A támadó rosszindulatú tartalmat juttathat be a sebezhető mezőkbe.
• Az adatbázisból olyan érzékeny adatok is kiolvashatók, mint a felhasználói nevek, jelszavak stb.
• Az adatbázis adatai módosíthatók (Insert/Update/Delete).
• Adminisztráció OperaAz adatbázisban végrehajthatók

Sebezhető tárgyak

• Beviteli mezők
• Az adatbázissal kölcsönhatásba lépő URL-ek.

Példák:

• SQL injektálás a Bejelentkezési oldalon

Bejelentkezés egy alkalmazásba érvényes hitelesítő adatok nélkül.

Érvényes felhasználónév elérhető, jelszó pedig nem elérhető.

Teszt URL: http://demo.testfire.net/default.aspx

Felhasználónév: sjones

Jelszó: 1=1′ vagy pass123

Az SQL-lekérdezés létrejött és elküldve az Interpreternek az alábbiak szerint

SELECT * FROM Felhasználók WHERE Felhasználónév = sjones AND Jelszó = 1=1′ vagy pass123;

ajánlások

1. A beviteli mezők fehér listája
2. Kerülje a támadó számára hasznos részletes hibaüzenetek megjelenítését.

Webhelyközi szkriptek

Description

A Cross Site Scripting röviden XSS néven is ismert.

Az XSS sebezhetőségek az oldalakba beágyazott szkripteket célozzák, amelyek a kliens oldalon, azaz a felhasználói böngészőben futnak le, nem pedig a szerver oldalon. Ezek a hibák akkor fordulhatnak elő, ha az alkalmazás nem megbízható adatokat vesz el, és megfelelő ellenőrzés nélkül küldi el a webböngészőnek.

A támadók az XSS segítségével rosszindulatú szkripteket futtathatnak a felhasználókon, ebben az esetben az áldozat böngészőkben. Mivel a böngésző nem tudja, hogy a szkript megbízható-e vagy sem, a szkript lefut, és a támadó eltérítheti a munkamenet-sütiket, elronthatja a webhelyeket, vagy átirányíthatja a felhasználót egy nem kívánt és rosszindulatú webhelyre.

Az XSS egy támadás, amely lehetővé teszi a támadó számára, hogy végrehajtsa a szkripteket az áldozat böngészőjében.

Következmény:

• A biztonsági rést kihasználva a támadó szkripteket fecskendezhet be az alkalmazásba, munkamenet-cookie-kat lophat, webhelyeket károsíthat, és rosszindulatú programokat futtathat az áldozat gépein.

Sebezhető tárgyak

• Beviteli mezők
• URL-ek

Példák

1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script>

A fenti szkript böngészőben futtatva egy üzenetablak jelenik meg, ha a webhely sebezhető az XSS-sel szemben.

A komolyabb támadás akkor hajtható végre, ha a támadó munkamenet-cookie-kat akar megjeleníteni vagy tárolni.

2. http://demo.testfire.net/search.aspx?txtSearch <iframe> http://google.com szélesség = 500 magasság 500>

A fenti szkript futtatásakor a böngésző betölt egy láthatatlan keretet, amelyre mutat http://google.com.

A támadás súlyossá tehető, ha rosszindulatú szkriptet futtat a böngészőben.

ajánlások

1. Fehér lista beviteli mezői
2. Bemenet Kimenet kódolás

Törött hitelesítés és munkamenet-kezelés

Description

A webhelyek általában minden érvényes munkamenethez létrehoznak egy munkamenet cookie-t és munkamenet-azonosítót, és ezek a cookie-k érzékeny adatokat tartalmaznak, például felhasználónév, jelszó stb. legyen új süti.

Ha a sütiket nem érvénytelenítik, az érzékeny adatok a rendszerben jelen lesznek. Például egy nyilvános számítógépet (Cyber ​​Cafe) használó felhasználó a sebezhető webhely cookie-jai a rendszeren helyezkednek el, és ki vannak téve egy támadónak. Egy támadó egy idő után ugyanazt a nyilvános számítógépet használja, és az érzékeny adatok veszélybe kerülnek.

Ugyanígy a nyilvános számítógépet használó felhasználó a kijelentkezés helyett hirtelen bezárja a böngészőt. A támadó ugyanazt a rendszert használja, amikor ugyanazt a sebezhető webhelyet böngészi, az áldozat előző munkamenete nyílik meg. A támadó bármit megtehet, amit akar: ellopja a profiladatokat, a hitelkártyaadatokat stb.

Ellenőrizni kell a hitelesítés és a munkamenet-kezelés erősségét. A kulcsokat, munkamenet-tokeneket és cookie-kat megfelelően kell megvalósítani a jelszavak veszélyeztetése nélkül.

Sebezhető tárgyak

• Az URL-en közzétett munkamenet-azonosítók munkamenetrögzítési támadáshoz vezethetnek.
• A munkamenet-azonosítók azonosak kijelentkezés és bejelentkezés előtt és után.
• A munkamenet-időtúllépések nincsenek megfelelően implementálva.
• Az alkalmazás minden új munkamenethez ugyanazt a munkamenet-azonosítót rendeli hozzá.
• Az alkalmazás hitelesített részeit SSL védi, a jelszavakat pedig kivonatolt vagy titkosított formátumban tárolja.
• A munkamenetet egy alacsony jogosultsággal rendelkező felhasználó újra felhasználhatja.

Következmény

• A biztonsági rést kihasználva a támadó eltéríthet egy munkamenetet, jogosulatlan hozzáférést kaphat a rendszerhez, amely lehetővé teszi a jogosulatlan információk felfedését és módosítását.
• A munkamenetek lopott cookie-k segítségével vagy XSS-t használó munkamenetek segítségével emelhetők fel.

Példák

1. A légitársaság foglalási alkalmazás támogatja az URL átírását, és munkamenet-azonosítókat helyez el az URL-ben:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Jegyek eladása Maldív-szigetekre) Az oldal hitelesített felhasználója értesíteni szeretné barátait az eladásról, és e-mailt küld. A barátok megkapják a munkamenet-azonosítót, és felhasználhatók jogosulatlan módosításokra, vagy visszaélhetnek a mentett hitelkártyaadatokkal.
2. Egy alkalmazás sebezhető az XSS-el szemben, amellyel a támadó hozzáférhet a munkamenet-azonosítóhoz, és felhasználható a munkamenet eltérítésére.
3. Az alkalmazások időtúllépései nincsenek megfelelően beállítva. A felhasználó nyilvános számítógépet használ, kijelentkezés helyett bezárja a böngészőt, és elmegy. A támadó valamivel később ugyanazt a böngészőt használja, és a munkamenet hitelesítése megtörténik.

ajánlások

1. Az összes hitelesítési és munkamenet-kezelési követelményt az OWASP Application Security Verification Standard szerint kell meghatározni.
2. Soha ne tegyen közzé hitelesítő adatokat az URL-ekben vagy a naplókban.
3. Erőteljes erőfeszítéseket kell tenni az XSS hibák elkerülésére is, amelyek a munkamenet-azonosítók ellopására használhatók.

Nem biztonságos közvetlen objektum-hivatkozások

Description

Ez akkor fordul elő, amikor a fejlesztő hivatkozást tesz közzé egy belső megvalósítási objektumra, például egy fájlra, könyvtárra vagy adatbáziskulcsra URL-ben vagy FORM paraméterként. A támadó felhasználhatja ezeket az információkat más objektumok eléréséhez, és jövőbeli támadást hozhat létre a jogosulatlan adatok elérése érdekében.

Következmény

• A biztonsági rés használatával a támadók jogosulatlan belső objektumokhoz férhetnek hozzá, módosíthatják az adatokat vagy feltörhetik az alkalmazást.

Sebezhető tárgyak

• Az URL-ben.

Példák:

A „felhasználói azonosító” megváltoztatása a következő URL-ben arra késztetheti a támadót, hogy megtekintse más felhasználók adatait.

http://www.vulnerablesite.com/userid=123 Módosítva erre http://www.vulnerablesite.com/userid=124

A támadó a felhasználói azonosító értékének megváltoztatásával megtekintheti mások adatait.

Ajánlások:

1. Végezzen hozzáférés-ellenőrzést.
2. Kerülje az objektumhivatkozások felfedését az URL-ekben.
3. Ellenőrizze az összes referenciaobjektum jogosultságát.

Cross Site Request Forgery

Description

A Cross Site Request Forgery egy hamisított kérés, amely a keresztoldalról érkezett.

A CSRF-támadás olyan támadás, amely akkor történik, amikor egy rosszindulatú webhely, e-mail vagy program a felhasználó böngészőjét nem kívánt művelet végrehajtására készteti egy olyan megbízható webhelyen, amelyhez a felhasználó jelenleg hitelesítve van.

A CSRF-támadás arra kényszeríti a bejelentkezett áldozat böngészőjét, hogy hamisított HTTP-kérelmet küldjön egy sebezhető webalkalmazásnak, beleértve az áldozat munkamenet-cookie-ját és bármely más automatikusan bevitt hitelesítési információt.

A támadó linket küld az áldozatnak, amikor a felhasználó az URL-re kattint, amikor bejelentkezik az eredeti webhelyre, az adatokat ellopják a webhelyről.

Következmény

• A biztonsági rés támadóként való használata megváltoztathatja a felhasználói profil adatait, módosíthatja az állapotot, új felhasználót hozhat létre adminisztrátor nevében stb.

Sebezhető tárgyak

• Felhasználói profil oldal
• Felhasználói fiók űrlapjai
• Üzleti tranzakciós oldal

Példák

Az áldozat érvényes hitelesítő adatokkal van bejelentkezve egy bank webhelyére. Levelet kap egy támadótól, amely azt mondja: „Kérjük, kattintson ide, és áldozzon 1 dollárt valamilyen célra.”

Amikor az áldozat rákattint, érvényes kérés jön létre 1 dollár adományozására egy adott számlára.

http://www.vulnerablebank.com/transfer.do?account=cause&amount=1

A támadó rögzíti ezt a kérést, és létrehozza az alábbi kérelmet, és beágyazza a „Támolom az ügyet” feliratú gombot.

http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000

Mivel a munkamenet hitelesített, és a kérés a bank webhelyén keresztül érkezik, a szerver 1000 dollárt utalna át a támadónak.

Ajánlást

1. Kényes műveletek végrehajtása során előírja a felhasználó jelenlétét.
2. Olyan mechanizmusokat valósítson meg, mint a CAPTCHA, újrahitelesítési és egyedi kérési tokenek.

Biztonsági hibás konfiguráció

Description

A biztonsági konfigurációt meg kell határozni és telepíteni kell az alkalmazáshoz, keretrendszerekhez, alkalmazáskiszolgálóhoz, webszerverhez, adatbázis-kiszolgálóhoz és platformhoz. Ha ezek megfelelően vannak beállítva, a támadó jogosulatlanul hozzáférhet érzékeny adatokhoz vagy funkciókhoz.

Néha az ilyen hibák teljes rendszerkompromittációt eredményeznek. A szoftver naprakészen tartása szintén jó biztonságot jelent.

Következmény

• A biztonsági rést kihasználva a támadó felsorolhatja a mögöttes technológiai és alkalmazásszerver-verzióinformációkat, adatbázis-információkat, és információkat szerezhet az alkalmazásról, hogy további támadásokat hajtson végre.

Sebezhető tárgyak

• URL
• Űrlapmezők
• Beviteli mezők

Példák

1. Az alkalmazáskiszolgáló felügyeleti konzolja automatikusan telepítésre kerül, és nem távolítható el. Az alapértelmezett fiókok nem változnak. A támadó alapértelmezett jelszavakkal jelentkezhet be, és illetéktelen hozzáférést kaphat.
2. A címtárlista nincs letiltva a szerverén. A támadó felfedezi és egyszerűen felsorolja a könyvtárakat, hogy megtalálja a fájlokat.

ajánlások

1. Erős alkalmazásarchitektúra, amely jó elválasztást és biztonságot nyújt az összetevők között.
2. Módosítsa az alapértelmezett felhasználóneveket és jelszavakat.
3. Tiltsa le a címtárlistákat, és hajtson végre hozzáférés-ellenőrzést.

Nem biztonságos kriptográfiai tárhely

Description

A nem biztonságos kriptográfiai tárolás egy gyakori biztonsági rés, amely akkor fordul elő, ha az érzékeny adatokat nem tárolják biztonságosan.

A felhasználói hitelesítő adatok, profilinformációk, egészségügyi adatok, hitelkártya-információk stb. érzékeny adatok közé tartoznak a webhelyeken.

Ezeket az adatokat az alkalmazás adatbázisa tárolja. Ha ezeket az adatokat nem megfelelően tárolják a titkosítás vagy a kivonatolás* használata nélkül, az sebezhetővé válik a támadókkal szemben.

(*A kivonatolás a karakterlánc karaktereinek átalakítása rövidebb, rögzített hosszúságú karakterláncokká vagy kulccsá. A karakterlánc visszafejtéséhez rendelkezésre kell állnia a kulcs létrehozásához használt algoritmusnak)

Következmény

• A biztonsági rés használatával a támadó ellophatja, módosíthatja az ilyen gyengén védett adatokat, hogy személyazonosság-lopást, hitelkártya-csalást vagy más bűncselekményt kövessen el.

Sebezhető tárgyak

• Alkalmazási adatbázis.

Példák

Az egyik banki alkalmazásban a jelszóadatbázis sótlan kivonatokat * használ mindenki jelszavának tárolására. Az SQL-beillesztési hiba lehetővé teszi a támadó számára a jelszófájl lekérését. Az összes sótlan kivonat pillanatok alatt nyersen kikényszeríthető, míg a sózott jelszavak több ezer évig tartanának.

(*Sózatlan hashek – A só egy véletlenszerű adat, amelyet az eredeti adatokhoz fűznek. A sót a rendszer a kivonatolás előtt hozzáfűzi a jelszóhoz)

ajánlások

1. Biztosítson megfelelő erős szabványos algoritmusokat. Ne hozzon létre saját kriptográfiai algoritmusokat. Csak jóváhagyott nyilvános algoritmusokat használjon, például AES-t, RSA nyilvános kulcsú titkosítást és SHA-256-ot stb.
2. Győződjön meg arról, hogy a külső helyszínről készült biztonsági másolatok titkosítva vannak, de a kulcsok kezelése és biztonsági mentése külön-külön történik.

Az URL-hozzáférés korlátozásának elmulasztása

Description

A webalkalmazások a védett hivatkozások és gombok megjelenítése előtt ellenőrzik az URL-hozzáférési jogokat. Az alkalmazásoknak minden alkalommal hasonló hozzáférés-ellenőrzést kell végrehajtaniuk, amikor ezekre az oldalakra lépnek.

A legtöbb alkalmazásban a privilegizált oldalak, helyek és erőforrások nem jelennek meg a jogosult felhasználók számára.

Intelligens találgatással a támadó hozzáférhet a jogosultsági oldalakhoz. A támadó hozzáférhet érzékeny oldalakhoz, funkciókat indíthat el, és bizalmas információkat tekinthet meg.

Következmény

• A biztonsági rés kihasználásával a támadó hozzáférhet a jogosulatlan URL-ekhez anélkül, hogy be kellene jelentkeznie az alkalmazásba, és kihasználná a biztonsági rést. A támadó hozzáférhet érzékeny oldalakhoz, funkciókat indíthat el, és bizalmas információkat tekinthet meg.

Sebezhető objektumok:

• URL-ek

Példák

1. A támadó észreveszi, hogy az URL a „/user/getaccounts” szerepkört jelzi. „/admin/getaccounts”-ként módosítja.
2. A támadó szerepkört fűzhet az URL-hez.

http://www.vulnerablsite.com szerint módosítható http://www.vulnerablesite.com/admin

ajánlások

1. Végezzen erős hozzáférés-ellenőrzést.
2. A hitelesítési és engedélyezési politikáknak szerepalapúaknak kell lenniük.
3. Korlátozza a hozzáférést a nem kívánt URL-ekhez.

Nem megfelelő szállítási rétegvédelem

Description

A felhasználó (kliens) és a szerver (alkalmazás) közötti információcserével foglalkozik. Az alkalmazások gyakran továbbítanak érzékeny információkat, például hitelesítési adatokat, hitelkártyaadatokat és munkamenet-tokeneket a hálózaton keresztül.

Gyenge algoritmusok, lejárt vagy érvénytelen tanúsítványok használata, illetve az SSL használatának mellőzése lehetővé teszi, hogy a kommunikáció nem megbízható felhasználók elé kerüljön, ami kompromittálhatja a webalkalmazásokat és/vagy bizalmas információkat lophat el.

Következmény

• Ezt a webes biztonsági rést kihasználva a támadók beszippanthatják a jogos felhasználó hitelesítő adatait, és hozzáférhetnek az alkalmazáshoz.
• Ellophatja a hitelkártya adatait.

Sebezhető tárgyak

• A hálózaton keresztül küldött adatok.

ajánlások

1. Engedélyezze a biztonságos HTTP-t, és csak HTTPS-en keresztül érvényesítse a hitelesítő adatok átvitelét.
2. Győződjön meg arról, hogy a tanúsítványa érvényes és nem járt le.

Példák:

1. Egy SSL-t nem használó alkalmazás esetén a támadó egyszerűen figyeli a hálózati forgalmat, és megfigyel egy hitelesített áldozati munkamenet cookie-t. A támadó ellophatja ezt a cookie-t, és Man-in-the-Middle támadást hajthat végre.

Nem érvényesített átirányítások és továbbítások

Description

A webalkalmazás kevés módszert használ a felhasználók átirányítására és más oldalakra való átirányítására, a kívánt célra.

Ha nem történik meg a megfelelő érvényesítés a más oldalakra való átirányítás során, a támadók kihasználhatják ezt, és átirányíthatják az áldozatokat adathalász vagy rosszindulatú webhelyekre, vagy továbbítást használhatnak a jogosulatlan oldalak eléréséhez.

Következmény

• A támadó olyan URL-t küldhet a felhasználónak, amely egy valódi URL-t tartalmaz, amelyhez kódolt rosszindulatú URL-cím van hozzáfűzve. A felhasználó, ha csak a támadó által küldött URL eredeti részét látja, böngészheti azt, és áldozattá válhat.

Példák

1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com

Módosítva erre

http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com

ajánlások

1. Egyszerűen kerülje az átirányítások és továbbítások használatát az alkalmazásban. Ha használja, ne használjon felhasználói paramétereket a cél kiszámításához.
2. Ha a célparaméterek nem kerülhetők el, győződjön meg arról, hogy a megadott érték érvényes és engedélyezett a felhasználó számára.