Körülbelül egy évvel ezelőtt a DataLine indított az IT-alkalmazások sebezhetőségeinek keresésére és elemzésére. A szolgáltatás alapja a Qualys felhőalapú megoldás, amelynek működéséről . Az egy évnyi működés alatt 291 vizsgálatot végeztünk különböző weboldalak számára, és statisztikát gyűjtöttünk a webalkalmazásokban előforduló gyakori sebezhetőségekről.
Az alábbi cikkben bemutatom, hogy milyen biztonsági hiányosságok rejtőznek a különböző kritikus szintű weboldalak mögött. Megnézzük, hogy a scanner milyen sebezhetőségeket talált különösen gyakran, miért fordulhatnak elő, és hogyan védhetjük meg magunkat.
A Qualys az webalkalmazások minden sebezhetőségét három kritikai szintre osztja: alacsony, közepes és magas. Ha a 'súlyosság' alapján nézzük, úgy tűnik, hogy a helyzet nem olyan rossz. Magas kritikai szintű sebezhetőségből kevés van, főként minden nem kritikus:
De a nem kritikus nem jelenti azt, hogy ártalmatlan. Ezek is komoly kárt okozhatnak.
A leggyakoribb „nem kritikus” sebezhetőségek
- A kevert tartalomhoz kapcsolódó sebezhetőségek.
A weboldalak biztonságának szabványa a kliens és a szerver közötti adatátvitel HTTPS protokollon keresztül, amely titkosítást biztosít és védi az információkat a lehallgatástól.
Néhány weboldal kevert tartalmat: az adatokat részben védtelen HTTP protokollon keresztül továbbítják. Gyakran így továbbítanak passzív tartalmat : az információkat, amelyek csak a weboldal megjelenítésére hatnak: képek, css-stílusok. De néha aktív tartalmat is továbbítanak : a szkripteket, amelyek irányítják a weboldal működését. Ebben az esetben speciális szoftver segítségével elemezheted a szervertől érkező, aktív tartalommal rendelkező információt, módosíthatod a válaszokat valós időben, és arra kényszerítheted a gépet, hogy úgy viselkedjen, ahogyan azt a készítői nem szánták.Az új verziós böngészők figyelmeztetik a felhasználókat, hogy a kevert tartalommal rendelkező weboldalak nem biztonságosak, és blokkolják a tartalmat. A webfejlesztők szintén figyelmeztetéseket kapnak a böngészőtől a konzolon. Például így néz ki ez
Miért veszélyes :
: A támadók a védtelen protokollt használják a felhasználói információk lehallgatására, a szkriptek manipulálására, és a weboldalon keresztül történő kérések elküldésére annak nevében. Még ha a weboldal látogatója nem is adott meg adatokat, ez nem védi meg őta phishingtől célzott adathalászat – a bizalmas információk csalási módszerekkel való megszerzése. Például egy szkript segítségével a felhasználót egy olyan biztonságtalan oldalra lehet átirányítani, amely a felhasználó számára ismerősnek tűnik. Egyes esetekben a rosszindulatú oldal még jobbnak is tűnhet, mint az eredeti, és a felhasználó saját magától kitöltheti az űrlapot, és átadhatja a bizalmas adatokat.Amire a webfejlesztőnek érdemes emlékeznie: Még ha a webhely adminisztrátora telepítette és beállította is az SSL/TLS tanúsítványt, a sérülékenység a humán tényező miatt felmerülhet. Például, ha a webhely egyes lapjain nem relatív linket használtak, hanem absolute-ot http-vel, és emellett nem állították be az átirányítást http-ről https-re.
A vegyes tartalom észlelhető a webhelyen böngésző segítségével: a lap forráskódjában keresve, valamint a fejlesztői konzolon megjelenő értesítéseket olvasva. Azonban a fejlesztőnek hosszú és fáradságos kódolásban kell részt vennie. A folyamatot felgyorsíthatják automatizált elemző eszközökkel, például: , ingyenes Lighthouse szoftverrel vagy a fizetős Screaming Frog SEO Spider alkalmazással.
Sérülékenység léphet fel öröklött kód miatt is, azaz legacy-code miatt. Például ha a lapok egy része régi mintát követ, amely nem veszi figyelembe a webhelyek HTTPS-re való áttérését.
- Kenyérsütő sütik HTTPOnly és secure zászló nélkül.
A HTTPOnly attribútum megvédi a sütifájlokat a rosszindulatú szkriptek általi feldolgozástól, amelyeket a támadók használnak a felhasználói adatok ellopásához. A secure zászló megakadályozza a sütik nyílt küldését. Az adatok átvitele csak akkor engedélyezett, ha a sütik küldéséhez védett HTTPS protokolt használnak.
Mindkét attribútum a sütik tulajdonságaiban van megadva:
Set-Cookie: Secure; HttpOnly: A támadók a védtelen protokollt használják a felhasználói információk lehallgatására, a szkriptek manipulálására, és a weboldalon keresztül történő kérések elküldésére annak nevében. Még ha a weboldal látogatója nem is adott meg adatokat, ez nem védi meg őt: Ha a webhely fejlesztője nem adta meg ezeket az attribútumokat, a támadó megszerezheti a felhasználó információit a sütiből, és azt felhasználhatja. Ha a sütik az azonosításra és a hitelesítésre szolgálnak, ellophatja a felhasználói munkamenetet, és a felhasználó nevében tevékenykedhet a webhelyen.
Amire a webfejlesztőnek érdemes emlékeznie: Általában a népszerű keretrendszerekben ezeket az attribútumokat automatikusan beállítják. De mindenképp ellenőrizze a webszerver konfigurációját, és állítson be zászlót: Set-Cookie HttpOnly; Secure.
E közben a HTTPOnly attribútum a sütiket láthatatlanná teszi a saját JavaScript kódja előtt is.
- Path-Based Vulnerabilities ("útvonal" sérülékenységek).
A szkenner akkor jelenti ezt a sebezhetőséget, ha nyilvánosan elérhető fájlt vagy könyvtárat talál az oldalon, amely potenciálisan bizalmas információkat tartalmaz. Például felfedez külön rendszerkonfigurációs fájlokat, vagy hozzáfér a fájlrendszerhez teljes egészében. Ilyen helyzet akkor fordulhat elő, ha az oldalon helytelenül állítják be a hozzáférési jogosultságokat.
: A támadók a védtelen protokollt használják a felhasználói információk lehallgatására, a szkriptek manipulálására, és a weboldalon keresztül történő kérések elküldésére annak nevében. Még ha a weboldal látogatója nem is adott meg adatokat, ez nem védi meg őt: Ha a fájlrendszer "kibújik a külső világra", a támadó behatolhat az operációs rendszer felületére, és megpróbálhat jelszavakat tartalmazó mappákat keresni, ha azok nyíltan vannak tárolva (ne csináld ezt!). Vagy ellophatók a jelszavak hash-ei, és azokat visszafejtheti a jelszó kitalálásához, valamint megpróbálhatja megemelni a jogosultságokat a rendszerben és továbblépni az infrastruktúrában.
Amire a webfejlesztőnek érdemes emlékeznie: Ne felejtsd el a hozzáférési jogosultságokat, és konfiguráld a platformot, a webszervert, a webalkalmazást úgy, hogy ne lehessen "kibújni" a webkönyvtárból.
- Olyan űrlapok, amelyek bizalmas adatokat kérnek, és aktív az automatikus kitöltés funkció.
Ha a felhasználó gyakran kitölti az űrlapokat az oldalakon, a böngészője elmenti ezeket az információkat az automatikus kitöltés funkcióval.
A weboldalakon található űrlapok tartalmazhatnak olyan mezőket, amelyek bizalmas információkat, például jelszavakat vagy hitelkártyaszámokat kérnek. Ilyen mezők esetén érdemes az oldalon letiltani az automatikus kitöltés funkciót.
: A támadók a védtelen protokollt használják a felhasználói információk lehallgatására, a szkriptek manipulálására, és a weboldalon keresztül történő kérések elküldésére annak nevében. Még ha a weboldal látogatója nem is adott meg adatokat, ez nem védi meg őt: Ha a felhasználó böngészője elmenti a bizalmas információkat, a támadó később, például phishing által képes lehet azokat megszerezni. Lényegében a webfejlesztő, aki elfelejtette ezt a részletet, kiteszi a felhasználóit.
Amire a webfejlesztőnek érdemes emlékeznie: Ilyen esetekben klasszikus konfliktus áll fenn: kényelem vs. biztonság. Ha a webfejlesztő figyelembe veszi a felhasználó kényelmét, tudatosan választhatja az automatikus kitöltést. Például, ha fontos, hogy kövesse – az információk hozzáférhetőségének ajánlásai a fogyatékkal élő felhasználók számára.
A legtöbb böngészőben az automatikus kitöltés letiltása az autocompete="off" attribútummal lehetséges, például:
<body> <form action="/hu/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit"> <div> <input type="text" placeholder="Keresztnév"> </div> <div> <input type="text" id="lname" placeholder="Vezetéknév" autocomplete="on"> </div> <div> <input type="number" placeholder="Hitelkártya szám"> </div> <input type="submit"> <input type="hidden" name="trp-form-language" value="hu"/></form> </body>De a Chrome esetében ez nem fog működni. Ezt JavaScript használatával lehet megkerülni, a recept egy változatát itt találhatod .
- A weboldal kódjában nincs megadva az X-Frame-Options fejléc.
Ez a cím befolyásolja a frame, iframe, embed vagy object tageket. Ezzel teljesen meg lehet akadályozni, hogy a webhelyét beágyazzák egy keretbe. Ehhez az X-Frame-Options: deny értéket kell megadni. Vagy megadhatja az X-Frame-Options: sameorigin értéket, amely lehetővé teszi az iframe-be történő beágyazást csak az Ön domainjén.
: A támadók a védtelen protokollt használják a felhasználói információk lehallgatására, a szkriptek manipulálására, és a weboldalon keresztül történő kérések elküldésére annak nevében. Még ha a weboldal látogatója nem is adott meg adatokat, ez nem védi meg őt: Az ilyen fejléc hiányát rosszindulatú webhelyeken lehet felhasználni a clickjacking. Az ilyen támadás során a hacker egy átlátszó keretet hoz létre a gombok fölé, megtévesztve ezzel a felhasználót. Például: a csalók egy közösségi média oldalát helyezik el a keretben a webhelyükön. A felhasználó azt hiszi, hogy az adott webhely gombjára kattint, de a kattintás valóban át van irányítva, és egy kérést küld a közösségi oldalra, ahol aktív session van. Így a csalók spamet küldenek a felhasználó nevében, vagy felnövelik a feliratkozókat és lájkokat.
Ha nem tiltanak le egy ilyen lehetőséget, a hacker a jövőbeli webhelyén a gombját helyezheti el. Érdekelt lehet az Ön referáló programjában vagy a felhasználóiban.
Amire a webfejlesztőnek érdemes emlékeznie: A sebezhetőség akkor fordulhat elő, ha a X-Frame-Options ellentmondásos értéke van megadva a webkiszolgálón vagy a terheléselosztón. Ebben az esetben a kiszolgáló és a terheléselosztó egyszerűen felülírja a fejléceket, mivel magasabb prioritással rendelkeznek, mint a backend kód.
A deny és sameorigin értékek megakadályozzák a Yandex webvizora működését. Annak érdekében, hogy lehetővé tegye az iframe használatát a webvizor számára, külön szabályt kell írnia a beállításokban. Például, nginx esetén így állítható be:
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) sebezhetőségek.
Ez egy sebezhetőség, amely a webhely stílusaiban rejlik. Akkor fordul elő, ha a stílusfájlok eléréséhez relatív hivatkozásokat használnak, mint pl. href="/somefolder/styles.css/". A hacker ezt kiaknázza, ha megtalálja a módját annak, hogy a felhasználót rosszindulatú oldalra irányítsa. Az oldal beilleszt egy relatív hivatkozást az URL-jébe, és imitálja a stílusok elérését. Ez olyan kérést eredményez, mint a badsite.ru/…/somefolder/styles.css/, amely a stílus mögé rejtve kártékony műveleteket végezhet.
: A támadók a védtelen protokollt használják a felhasználói információk lehallgatására, a szkriptek manipulálására, és a weboldalon keresztül történő kérések elküldésére annak nevében. Még ha a weboldal látogatója nem is adott meg adatokat, ez nem védi meg őt: A csaló kihasználhatja ezt a sebezhetőséget, ha talál még egy biztonsági rést. Ennek eredményeként pedig ellophatja a felhasználói adatokat a sütikből vagy a tokenekből.
Amire a webfejlesztőnek érdemes emlékeznie: Állítson be X-Content-Type-Options: nosniff fejlécet. Ebben az esetben a böngésző ellenőrzi a tartalom típusát a stílusoknál. Ha a típusa eltér a text/css-től, a böngésző blokkolja a kérést.
Kritikus sebezhetőségek
- A jelszómezőt tartalmazó oldal nem biztonságos csatornán keresztül érkezik a szerverről (HTML form containing password field(s) is served over HTTP).
A szerver válasza nem titkosított csatornán sebezhető a „Man in the middle” támadásokkal szemben. A támadó elfoghatja a forgalmat, és beléphet a kliens és a szerver közé, amikor az oldal a szervertől a kliens felé halad.
: A támadók a védtelen protokollt használják a felhasználói információk lehallgatására, a szkriptek manipulálására, és a weboldalon keresztül történő kérések elküldésére annak nevében. Még ha a weboldal látogatója nem is adott meg adatokat, ez nem védi meg őt: A csaló át tudja alakítani az oldalt, és elküldheti a felhasználónak egy űrlapot bizalmas adatokról, amelyek a támadó szerverére kerülnek.
Amire a webfejlesztőnek érdemes emlékeznie: Néhány oldal a jelszó helyett egyszer használatos kódot küld a felhasználóknak e-mailben/telefonon. Ebben az esetben a sebezhetőség nem olyan kritikus, de a mechanizmus megnehezíti a felhasználók életét.
- A bejelentkezési űrlap nem biztonságos csatornán keresztül kerül elküldésre (Login Form Is Not Submitted Via HTTPS).
Ebben az esetben a felhasználó űrlapja nem titkosított csatornán keresztül kerül a szerverre, amely tartalmazza a bejelentkezési adatokat.
: A támadók a védtelen protokollt használják a felhasználói információk lehallgatására, a szkriptek manipulálására, és a weboldalon keresztül történő kérések elküldésére annak nevében. Még ha a weboldal látogatója nem is adott meg adatokat, ez nem védi meg őt: A korábbi esettől eltérően ez már kritikus sebezhetőség. A bizalmas adatok elfogása egyszerűbb, hiszen ehhez még kódot sem szükséges írni.
- Ismert sebezhetőségekkel rendelkező JavaScript könyvtárak használata.
A vizsgálat során a legelterjedtebb könyvtárrá a jQuery vált, amely sz széles verzióskálát ölel fel. Minden egyes verzióban legalább egy, de akár több ismert sebezhetőség is található. A hatás változó lehet – a sebezhetőség természetétől függ.
: A támadók a védtelen protokollt használják a felhasználói információk lehallgatására, a szkriptek manipulálására, és a weboldalon keresztül történő kérések elküldésére annak nevében. Még ha a weboldal látogatója nem is adott meg adatokat, ez nem védi meg őt: Az ismert sebezhetőségekre léteznek kihasználási módszerek, például:
Amire a webfejlesztőnek érdemes emlékeznie: Rendszeresen térjen vissza a körforgásra: ismert sebezhetőségek keresése – megszüntetés – ellenőrzés. Ha tudatosan használ elavult könyvtárakat, például régi böngészők támogatása vagy költségmegtakarítás céljából, keressen lehetőséget az ismert sebezhetőség megszüntetésére. - Keresztoldali szkriptek (XSS).
A Cross-Site Scripting (XSS), vagyis a köztes webhelyszkriptek, olyan támadások egy webalkalmazás ellen, amely során a rosszindulatú kód megjelenik az adatbázisban. Ha a Qualys ilyen sebezhetőséget talál, akkor a potenciális támadó be tudja illeszteni, vagy már be is illesztette a saját js-skriptjét a webhely kódjába a rosszindulatú tevékenységek végrehajtásához.Tárolt XSS (Stored XSS) sokkal veszélyesebb, mivel a kód a szerveren kerül beillesztésre, és minden alkalommal végrehajtódik, amikor a támadott oldalt a böngésző megnyitja.
Reflektált XSS (Reflected XSS) könnyebb végrehajtani, mert a rosszindulatú skriptet be lehet illeszteni az HTTP-kérésbe. Az alkalmazás megkapja az HTTP-kérést, nem ellenőrzi az adatokat, csomagolja őket, és azonnal elküldi. Ha a támadó elfogja a forgalmat, és beilleszti a következő formátumú skriptet:
<script>/*+что+то+плохое+*/</script>akkor a kliens nevében egy rosszindulatú kérdés távozik.
Kiváló példa az XSS-re: js-snifferek, amelyek a CVC, a kártya lejárati ideje és hasonló dolgok megadására készült oldalakat imitálnak.
Amire a webfejlesztőnek érdemes emlékeznie: A Content-Security-Policy fejlécben használja a script-src attribútumot, hogy a kliens böngészője csak megbízható forrásból tölthesse le és hajthassa végre a kódot. Például a script-src ‘self’ fehérlistára helyez minden skriptet csak a saját webhelyünkről.
A legjobb gyakorlat Inline kód használata: csak inline javascript engedélyezése unsafe-inline értékkel. Ez az érték lehetővé teszi az inline js/css használatát, de nem tiltja a js-fájlok csatlakoztatását. A script-src ‘self’ kombinációjával megakadályozzuk a külső szkriptek végrehajtását.Kötelező minden műveletet naplózni a report-uri segítségével, és figyelni a weboldalra tett bevitel kísérleteit.
- SQL-injekciók.
A sebezhetőség lehetőséget ad SQL kódok webhelyre történő beillesztésére, amelyek közvetlenül a weboldal adatbázisához fordulnak. SQL-injekció akkor lehetséges, ha a felhasználói adatok nincsenek escape-elve: nem ellenőrzik a helyességüket, és azonnal felhasználják a kérdésben. Például ez történik, ha a weboldalon lévő űrlap nem ellenőrzi az adatbevitelt az adat típusának megfelelően.: A támadók a védtelen protokollt használják a felhasználói információk lehallgatására, a szkriptek manipulálására, és a weboldalon keresztül történő kérések elküldésére annak nevében. Még ha a weboldal látogatója nem is adott meg adatokat, ez nem védi meg őt: Ha a támadó egy SQL-ilyet küld be az űrlapba, akkor megsemmisítheti az adatbázist vagy titkos információkat kaphat.
Amire a webfejlesztőnek érdemes emlékeznie: Ne bízzon meg abban, ami a böngészőtől érkezik. Védekeznie kell az ügyfél és a szerver oldalán egyaránt.
Az ügyfél oldalán készítse el a mezők ellenőrzését JavaScript segítségével.
A népszerű keretrendszerek beépített funkciói szintén segítenek a gyanús karakterek kiszűrésében a szerveren. A szerveren érdemes paraméterezett adatbázis-lekérdezéseket is használni.
Határozza meg, hogy pontosan hol történik az interakció az adatbázissal a webalkalmazásban.
Az interakció akkor következik be, amikor információt kapunk: lekérdezés id-vel (id csere), új felhasználó létrehozása, új kommentár – új rekordok az adatbázisban. Itt sql-injekciók léphetnek fel. Még akkor is, ha eltávolítunk egy rekordot az adatbázisból, sql-injekció előfordulhat.
Általános ajánlások
Ne feltalálja a kereket – használja a bevált keretrendszereket. Általában a népszerű keretrendszerek biztonságosabbak. .NET esetén ezek az ASP.NET MVC és ASP.NET Core, Python esetén a Django vagy Flask, Ruby-ra a Ruby on Rails, PHP-ra a Symfony, Laravel, Yii, JavaScript-re a Node.JS-Express.js, Java-ra pedig a Spring MVC.
Figyelje a gyártó frissítéseit, és rendszeresen frissítse őket. A sebezhetőséget felfedezik, majd exploitot írnak, nyilvánosságra hozzák, és minden újra kezdődik. Iratkozzon fel a gyártó szoftverének stabil verzióinak frissítéseire.
Ellenőrizze a hozzáférési jogokat. A szerver oldaláról mindig úgy tekintsen a kódjára, mintha az egész, az elsőtől az utolsó betűig, a leggyűlöltebb ellensége írta volna, aki azt akarja, hogy a weboldala tönkre menjen, és a adatai integritása megsérüljön. Különösen, hogy néha valóban így van.
Használjon klónokat, tesztelő környezetet, aztán már csak a produktívra. Ez segít elkerülni a hibákat és mulasztásokat a produktív környezetben: a produktív környezet pénzt hoz, a produktív környezet leállása kritikus. Hozzáadáskor, hiba javításakor vagy probléma lezárásakor érdemes munkálatokat végezni a tesztkörnyezetben, majd ellenőrizni a funkcionalitást és az észlelt sebezhetőségeket, és csak aztán tervezni a munkákat a produktív környezetben.
Védje meg a webalkalmazást a következőkkel és integrálja vele a sebezhetőség-ellenőrző mintákat. Például a DataLine-ban a szolgáltatások összekapcsolására a Qualys és FortiWeb használatos.
Forrás: habr.com
