Körülbelül egy éve indítottuk el a DataLine szolgáltatást informatikai alkalmazások sérülékenységeinek felkutatására és elemzésére. A szolgáltatás a Qualys felhő megoldásra épül, melynek működéséről . A megoldással való munka évében 291 vizsgálatot végeztünk különböző webhelyek után, és statisztikákat gyűjtöttünk a webalkalmazások gyakori sebezhetőségeiről.
Az alábbi cikkben pontosan bemutatom, hogy a weboldalakon milyen biztonsági rések rejtőznek a különböző szintű kritikusság mögött. Nézzük meg, milyen sebezhetőségeket talált a szkenner különösen gyakran, miért fordulhatnak elő, és hogyan védekezhet.
A Qualys az összes webalkalmazás sebezhetőségét három súlyossági szintre osztja: alacsony, közepes és magas. Ha megnézi a "súlyosság" megoszlását, úgy tűnik, hogy nem minden olyan rossz. Kevés magas szintű kritikus sérülékenység létezik, alapvetően az összes nem kritikus:
De a kritikátlan nem azt jelenti, hogy ártalmatlan. Komoly károkat is okozhatnak.
Legfőbb "nem kritikus" sérülékenységek
- Vegyes tartalommal kapcsolatos biztonsági rések.
A webhely biztonsági szabványa az adatok átvitele a kliens és a szerver között HTTPS protokoll használatával, amely támogatja a titkosítást és megvédi az információkat az elfogástól.
Egyes webhelyek használnak vegyes tartalom: az adatok egy részének átvitele a nem biztonságos HTTP protokollon keresztül. Leggyakrabban így van passzív tartalom - csak az oldal megjelenítését érintő információk: képek, css-stílusok. De néha átadják aktív tartalom: szkriptek, amelyek a webhely viselkedését szabályozzák. Ilyenkor egy speciális szoftver segítségével elemezhetjük a szerverről érkező aktív tartalommal rendelkező információkat, menet közben módosíthatjuk a válaszainkat, és úgy tudjuk működésbe hozni a gépet, ahogyan azt nem tervezték.
Az újabb böngészők figyelmeztetik a felhasználókat, hogy a vegyes tartalmú webhelyek nem biztonságosak, és blokkolják a tartalmat. A webhelyfejlesztők figyelmeztetéseket is kapnak a konzolon lévő böngészőtől. Például így néz ki :
Mi a veszélyes: A támadók egy nem biztonságos protokollt használnak a felhasználóra vonatkozó információk elfogására, szkriptek cseréjére és kérések küldésére a webhelynek a nevében. Még ha az oldal látogatója nem is adott meg adatokat, ez nem védi meg attól adathalászat - Bizalmas információk kihalászása csalárd módszerekkel. Például egy szkript segítségével átirányíthatja a felhasználót egy nem biztonságos webhelyre, amely a felhasználó számára ismerősnek álcázza magát. Egyes esetekben a rosszindulatú webhely még az eredetinél is jobban néz ki, és a felhasználó maga is kitöltheti az űrlapot, és kényes adatokat küldhet be.Amit webfejlesztőként emlékezni kell: Még akkor is, ha a webhely rendszergazdája telepített és konfigurált egy SSL/TLS-tanúsítványt, a sérülékenységet akkor is emberi hiba okozhatja. Például, ha az egyik oldal nem relatív hivatkozással volt beállítva, hanem egy abszolút http-vel, és ezen kívül nem lett beállítva a http-ről https-re történő átirányítás.
A vegyes tartalmat böngésző segítségével észlelheti az oldalon: keressen az oldal forráskódjában, olvassa el az értesítéseket a fejlesztői konzolban. A fejlesztőnek azonban hosszú és unalmas ideig kell turkálnia a kódban. Felgyorsíthatja a folyamatot automatizált elemző eszközökkel, például: , ingyenes szoftver Lighthouse vagy fizetős szoftver Screaming Frog SEO Spider.
Ezenkívül sebezhetőség adódhat a legacy-kóddal – az örökölt kóddal – kapcsolatos problémák miatt. Például, ha az oldalak egy része a régi sablon szerint jön létre, amely nem veszi figyelembe a webhelyek https-re való átállását.
- Cookie-k a "HTTOnly" és a "secure" jelzők nélkül.
A "HTTOnly" attribútum megvédi a cookie-kat a szkriptek általi feldolgozástól, amelyeket a támadók felhasználói adatok ellopására használnak. A "secure" jelző nem teszi lehetővé a cookie-k egyértelmű átadását. A kommunikáció csak akkor engedélyezett, ha a biztonságos HTTPS protokollt használják a cookie-k küldésére.
Mindkét attribútum be van írva a cookie tulajdonságaiba:
Set-Cookie: Secure; HttpOnlyMi a veszélyes: Ha a webhely fejlesztője nem adta meg ezeket az attribútumokat, a támadó elkaphatja a felhasználó adatait a cookie-ból, és felhasználhatja azokat. Ha cookie-kat használnak a hitelesítéshez és az engedélyezéshez, akkor képes lesz feltörni a felhasználó munkamenetét, és az ő nevében műveleteket végezni az oldalon.
Amit webfejlesztőként emlékezni kell: Általános szabály, hogy a népszerű keretrendszerekben ezek az attribútumok automatikusan beállításra kerülnek. De mindenképpen ellenőrizze a webszerver konfigurációját, és állítsa be a jelzőt: Set-Cookie HttpOnly; biztonságos.
A "HTTOnly" attribútum azonban láthatatlanná teszi a cookie-t a saját JavaScriptje számára is.
- Path-Based Vulnerabilities ("útvonal" sebezhetőségek).
A lapolvasó akkor jelent ilyen biztonsági rést, ha nyilvánosan elérhető fájlt vagy webhelykönyvtárat talál potenciálisan érzékeny információkkal. Például észleli az egyes fájlokat rendszerkonfigurációval vagy hozzáféréssel a teljes fájlrendszerhez. Ez a helyzet akkor lehetséges, ha a hozzáférési jogok helytelenül vannak beállítva az oldalon.
Mi a veszélyes: Ha a fájlrendszer kilóg, a támadó beeshet az operációs rendszer felületére, és megpróbálhat jelszót tartalmazó mappákat keresni, ha azok tiszta szövegben vannak tárolva (ezt ne tedd!). Vagy ellophatja a jelszókivonatokat, és brutálisan kényszerítheti a jelszót, valamint megpróbálhatja növelni a rendszer jogosultságait, és mélyebbre lépni az infrastruktúrában.
Amit webfejlesztőként emlékezni kell: Ne feledkezz meg a jogosultságokról, és állítsd be a platformot, webszervert, webalkalmazást úgy, hogy ne tudj "elmenekülni" a webkönyvtárból.
- Űrlapok bizalmas adatok beviteléhez az automatikus kitöltéssel.
Ha a felhasználó gyakran tölt ki űrlapokat a webhelyeken, böngészője az automatikus kitöltési funkció segítségével menti el ezeket az információkat.
A webhelyeken található űrlapok érzékeny információkat, például jelszavakat vagy hitelkártyaszámokat tartalmazó mezőket tartalmazhatnak. Az ilyen mezőknél érdemes magán az oldalon letiltani az űrlapok automatikus kitöltési funkcióját.
Mi a veszélyes: Ha a felhasználó böngészője bizalmas információkat ment el, a támadó később elkaphatja azokat, például adathalászattal. Valójában egy webfejlesztő, aki megfeledkezett erről az árnyalatról, keretezi a felhasználóit.
Amit webfejlesztőként emlékezni kell: Ebben az esetben klasszikus konfliktusunk van: kényelem kontra biztonság. Ha egy webfejlesztő a felhasználói kényelemre gondol, akkor tudatosan az automatikus kiegészítést választja. Például ha fontos követni – ajánlások a fogyatékkal élő felhasználók tartalom-hozzáférhetőségére vonatkozóan.
A legtöbb böngészőben kikapcsolhatja az automatikus kiegészítést az autocompete="off" attribútummal, például:
<body> <form action="/hu/form/submit" method="get" autocomplete="off"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> </form> </body>De Chrome esetén ez nem fog működni. Ezt a JavaScript megkerüli, a recept egy változata megtalálható .
- Az X-Frame-Options fejléc nincs beállítva a webhely kódjában.
Ez a fejléc a keret-, iframe-, beágyazás- vagy objektumcímkékre vonatkozik. Ezzel teljesen megtilthatja webhelyének beágyazását a keretbe. Ehhez meg kell adni az X-Frame-Options: deny értéket. Vagy megadhatja az X-Frame-Options: sameorigin beállítást, akkor az iframe beágyazás csak az Ön domainjén lesz elérhető.
Mi a veszélyes: Az ilyen fejléc hiánya rosszindulatú webhelyeken használható clickjacking. Egy ilyen támadáshoz a támadó egy átlátszó keretet hoz létre a gombok tetején, és megtéveszti a felhasználót. Például: csalók kereteznek közösségi oldalakat egy webhelyen. A felhasználó úgy gondolja, hogy egy gombra kattint ezen az oldalon. Ehelyett a rendszer elfogja a kattintást, és elküldi a felhasználó kérését arra a közösségi hálózatra, ahol aktív munkamenet van. A támadók így küldenek spamet a felhasználó nevében, vagy felszámolják a feliratkozókat és a kedveléseket.
Ha nem tiltja le ezt a funkciót, a támadó elhelyezheti az alkalmazás gombját egy rosszindulatú webhelyen. Érdekelheti ajánlóprogramja vagy felhasználói.
Amit webfejlesztőként emlékezni kell: A biztonsági rés akkor fordulhat elő, ha a webszerveren vagy a terheléselosztón ütköző értékű X-Frame-Options van beállítva. Ebben az esetben a kiszolgáló és a kiegyenlítő egyszerűen átírja a fejlécet, mivel magasabb prioritásúak, mint a háttér-részkód.
Az X-Frame-Options fejléc deny és sameorigin értékei zavarják a Yandex webvisor működését. Az iframe webböngészőben való használatának engedélyezéséhez külön szabályt kell írni a beállításokban. Például nginx esetén a következőképpen konfigurálhatja:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - PRSSI (Path-relative stylesheet import) biztonsági rések.
Ez egy stílussal kapcsolatos biztonsági rés a webhelyen. Ez akkor fordul elő, ha a relatív hivatkozások, például a href="/hu/somefolder/styles.css/" stílusfájlokra hivatkoznak. A támadó ezt kihasználja, ha megtalálja a módját, hogy a felhasználót egy rosszindulatú oldalra vigye. Az oldal egy relatív hivatkozást helyettesít az URL-jében, és stílushívást imitál. Egy olyan kérést fog kapni, mint a badsite.ru/…/somefolder/styles.css/, amely a stílus leple alatt rosszindulatú műveleteket hajthat végre.
Mi a veszélyes: A támadó kihasználhatja ezt a biztonsági rést, ha újabb biztonsági rést talál. Ennek eredményeként lehetséges a felhasználói adatok ellopása cookie-kból vagy tokenekből.
Amit webfejlesztőként emlékezni kell: Fejléc beállítása X-Content-Type-Options: nosniff. Ebben az esetben a böngésző ellenőrzi a tartalomtípust a stílusok szempontjából. Ha a típus nem text/css, a böngésző blokkolja a kérést.
Kritikus sérülékenységek
- A jelszómezőt tartalmazó oldalt a szerver egy nem biztonságos csatornán továbbítja (a jelszómező(ke)t tartalmazó HTML űrlap HTTP-n keresztül kerül továbbításra.
A kiszolgáló titkosítatlan csatornán keresztül érkező válasza sebezhető a "Man in the middle" támadásokkal szemben. A támadó elfoghatja a forgalmat és elfoghatja az ügyfél és a szerver közötti forgalmat, miközben az oldal a szerverről az ügyfélre halad.
Mi a veszélyes: A csaló megváltoztathatja az oldalt, és űrlapot küldhet a felhasználónak a bizalmas adatokhoz, amelyek a támadó szerverére kerülnek.
Amit webfejlesztőként emlékezni kell: Egyes webhelyek jelszó helyett egyszeri kódot küldenek a felhasználóknak e-mailben/telefonon. Ebben az esetben a sérülékenység nem olyan kritikus, de a mechanizmus megnehezíti a felhasználók életét.
- Űrlap beküldése bejelentkezési névvel és jelszóval nem biztonságos csatornán keresztül (a bejelentkezési űrlapot nem küldik el HTTPS-n keresztül).
Ebben az esetben egy felhasználónévvel és jelszóval ellátott űrlapot küld a felhasználó a szerverre egy titkosítatlan csatornán keresztül.
Mi a veszélyes: Az előző esettől eltérően ez már egy kritikus sérülékenység. Az érzékeny adatok rögzítése egyszerűbb, mert ehhez még kódot sem kell írnia.
- JavaScript-könyvtárak használata ismert sebezhetőségekkel.
A vizsgálat során a jQuery a leggyakrabban használt könyvtár lett, változatos változatokkal. Mindegyik verzió legalább egy vagy több ismert biztonsági réssel rendelkezik. A hatás a sebezhetőség természetétől függően igen eltérő lehet.
Mi a veszélyes: Vannak olyan ismert sebezhetőségek kihasználása, mint például:
Amit webfejlesztőként emlékezni kell: Rendszeresen visszatér a ciklushoz: ismert sebezhetőségek felkutatása - javítás - ellenőrzés. Ha tudatosan használ örökölt könyvtárakat, például régebbi böngészők támogatására vagy pénzmegtakarítás céljából, keresse meg az ismert biztonsági rések kijavításának módjait. - Webhelyek közötti szkriptelés (XSS).
A Cross-Site Scripting (XSS) egy webalkalmazás elleni támadás, amelynek eredményeként rosszindulatú programok jelennek meg az adatbázisban. Ha a Qualys ilyen sebezhetőséget talál, akkor a potenciális támadó rosszindulatú műveletek végrehajtása érdekében befecskendezheti vagy már befecskendezte saját js-szkriptjét a webhely kódjába.Tárolt XSS veszélyesebbek, mivel a szkript a szerverre kerül, és minden alkalommal lefut, amikor a támadott oldalt megnyitják a böngészőben.
Tükrözött XSS könnyebb megtenni, mivel rosszindulatú szkriptet lehet beadni a HTTP-kérésbe. Az alkalmazás HTTP kérést kap, nem érvényesíti az adatokat, csomagolja be, és azonnal elküldi. Ha egy támadó elfogja a forgalmat és beszúr egy szkriptet, mint pl
<script>/*+что+то+плохое+*/</script>akkor egy rosszindulatú kérés távozik az ügyfél nevében.
Kiváló példa az XSS-re: js-szippantó, amely utánozza az oldalakat a CVC megadásához, a kártya lejáratához stb.
Amit webfejlesztőként emlékezni kell: A Content-Security-Policy fejlécben használja a script-src attribútumot, hogy az ügyfélböngészőt csak megbízható forrásból származó kód letöltésére és végrehajtására kényszerítse. Például a script-src 'self' csak a webhelyünkről származó összes szkriptet engedélyezőlistára helyezi.
A legjobb gyakorlat a soron belüli kód: Csak a nem biztonságos beágyazott értékkel rendelkező inline javascript engedélyezése. Ez az érték lehetővé teszi a soron belüli js/css használatát, de nem tiltja meg a js fájlok felvételét. A script-src 'self'-el kombinálva megakadályozzuk a külső szkriptek végrehajtását.Mindenképpen naplózzon mindent egy report-uri-val, és nézze meg a webhelyre való bejuttatási kísérleteket.
- SQL injekciók.
A biztonsági rés azt jelzi, hogy SQL-kódot lehet beilleszteni a webhelyre, amely közvetlenül hozzáfér a webhely adatbázisához. Az SQL-befecskendezés akkor lehetséges, ha a felhasználótól származó adatok nincsenek kihagyva: nem ellenőrzik a helyességét, és azonnal felhasználják a lekérdezésben. Ez például akkor fordul elő, ha a webhelyen lévő űrlap nem ellenőrzi, hogy a bemenet megfelel-e az adattípusnak.Mi a veszélyes: Ha egy támadó SQL-lekérdezést ad meg ebben az űrlapban, eldobhatja az adatbázist, vagy bizalmas információkat adhat ki.
Amit webfejlesztőként emlékezni kellV: Ne bízzon abban, ami a böngészőből származik. Meg kell védenie magát mind a kliens, mind a szerver oldalon.
Az ügyféloldalon írja be a mező érvényesítését JavaScripttel.
A népszerű keretrendszerek beépített funkciói szintén segítenek elkerülni a szerveren lévő gyanús karaktereket. Javasoljuk továbbá a paraméterezett adatbázis-lekérdezések használatát a szerveren.
Határozza meg pontosan, hogy a webalkalmazáson belül hol zajlik az adatbázissal való interakció.
Interakció akkor történik, amikor bármilyen információt kapunk: kérés azonosítóval (azonosító módosítása), új felhasználó létrehozása, új megjegyzés, új bejegyzések az adatbázisban. Itt fordulhatnak elő sql injekciók. Hiába töröljük a bejegyzést az adatbázisból, lehetséges az sql injekció.
Általános ajánlások
Ne találja fel újra a kereket – használjon bevált kereteket. Általában a népszerű keretrendszerek biztonságosabbak. .NET esetén ASP.NET MVC és ASP.NET Core, Python esetében Django vagy Flask, Ruby esetében Ruby on Rails, PHP esetében Symfony, Laravel, Yii, JavaScript esetében Node.JS-Express .js, Java számára – tavaszi MVC.
Kövesse nyomon a szállító frissítéseit, és rendszeresen frissítse. Találnak egy sebezhetőséget, majd exploitot írnak, nyilvánosságra hozzák, és minden új módon megismétlődik. Feliratkozás a szoftvergyártó stabil kiadásainak frissítéseire.
Ellenőrizze az engedélyeket. Szerver oldalról mindig úgy kezelje a kódját, mintha az első betűtől az utolsóig a leggyűlöltebb ellensége írta volna, aki fel akarja törni az oldalát, megsérti adatainak integritását. Ráadásul ez néha igaz is.
Használjon klónokat, teszthelyeket, majd öntse rá a termelést. Ez egyrészt segít elkerülni a baklövést és a zűrzavart egy produktív környezetben: a produktív környezet pénzt hoz, az egyszerű produktív környezet kritikus. Bármilyen probléma hozzáadásakor, javításakor vagy lezárásakor érdemes tesztkörnyezetben dolgozni, majd ellenőrizni a talált funkcionalitást és sebezhetőséget, majd produktív környezettel tervezni a munkát.
Védje meg webalkalmazását ezzel és integrálja vele a sebezhetőség-ellenőrző jelentéseit. Például a DataLine-ban a Qualys és a FortiWeb szolgáltatáscsomagként használatos.
Forrás: will.com