Přibližně před rokem jsme v DataLine spustili službu pro hledání a analýzu zranitelností v IT aplikacích. Celé řešení je postaveno na cloudové platformě Qualys, o které jsme . Za rok využívání této služby jsme provedli 291 skenování různých webů a nasbírali statistiky o běžných zranitelnostech ve webových aplikacích.
V následujícím článku ukážu, jaké bezpečnostní nedostatky se skrývají za různými úrovněmi závažnosti. Podíváme se, které zranitelnosti skener nacházel nejčastěji, proč k nim může docházet a jak se bránit.
Všechny zranitelnosti webových aplikací Qualys dělí na tři úrovně závažnosti: nízkou, střední a vysokou. Pokud se podíváme na rozdělení podle "závažnosti", zdá se, že to není tak špatné. Zranitelností s vysokou úrovní závažnosti je málo, většinou jsou všechny nekritické:
Ale nekritické – neznamená bezobsažné. Takové zranitelnosti mohou také způsobit vážné škody.
Top "nekritických" zranitelností
- Zranitelnosti spojené se smíšeným obsahem.
Bezpečnostním standardem webových stránek je přenos dat mezi klientem a serverem prostřednictvím protokolu HTTPS, který podporuje šifrování a chrání informace před odposlechem.
Některé weby používají smíšený obsah: přenášejí část dat prostřednictvím nezabezpečeného protokolu HTTP. Častěji se takto přenáší pasivní obsah : informace, které ovlivňují pouze zobrazení webu: obrázky, CSS styly. Ale někdy se takto přenáší také aktivní obsah: skripty, které řídí chování webu. V tomto případě je možné pomocí speciálního softwaru analyzovat informace přicházející ze serveru s aktivním obsahem, modifikovat své odpovědi za běhu a donutit zařízení fungovat tak, jak jeho tvůrci nezamýšleli.
Nové verze prohlížečů varují uživatele, že weby se smíšeným obsahem jsou nebezpečné, a blokují obsah. Vývojáři webů také dostávají varování od prohlížeče v konzoli. Například takto to vypadá v :
Jaké nebezpečí: Útočníci využívají nezabezpečený protokol k odposlouchávání informací o uživateli, výměně skriptů a odesílání požadavků na web jménem uživatele. I když návštěvník webu nezadal žádná data, to ho nechrání před phishingem – získávání důvěrných informací podvodnými metodami. Například pomocí skriptu lze přesměrovat uživatele na nebezpečnou stránku, která se maskuje jako známá. V některých případech může zlovolná stránka vypadat dokonce lépe než originál, a uživatel může sám vyplnit formulář a předat důvěrné údaje.Co si pamatuje webový vývojář: I když správce webové stránky nainstaloval a nastavoval SSL/TLS certifikát, zranitelnost může vzniknout v důsledku lidského faktoru. Například pokud je na některé ze stránek použito místo relativního odkazu absolutní s http, a navíc nejsou nakonfigurovány přesměrování z http na https.
Smíšený obsah na webu lze odhalit pomocí prohlížeče: prozkoumat zdrojový kód stránky a přečíst si upozornění v konzoli vývojáře. Nicméně vývojář bude muset dlouho a nučně procházet kód. Proces lze urychlit pomocí automatizovaných analytických nástrojů, například: , volné softwarové nástroje Lighthouse nebo placený software Screaming Frog SEO Spider.
Zranitelnost může rovněž vzniknout z problémů se zděděným kódem – kódem, který byl převzat. Například pokud je část stránek generována podle starého šablony, která nezohledňuje přechod webů na https.
- Cookies bez vlajek „HTTPOnly“ a „secure“.
Atribut „HTTPOnly“ chrání soubory cookies před zpracováním skripty, které útočníci používají k krádeži uživatelských dat. Vlajka „secure“ nedovoluje přenos cookies v otevřené podobě. Výmena dat bude povolena pouze v případě, že k odeslání cookies se používá chráněný protokol HTTPS.
Oba atributy se zapisují do vlastností cookies:
Set-Cookie: Secure; HttpOnlyJaké nebezpečí: Pokud vývojář webu tyto atributy nenastavil, útočník může zachytit informace uživatele z cookies a využít je. Pokud se cookies používají pro autentizaci a autorizaci, může ukrást relaci uživatele a provádět akce na webu jeho jménem.
Co si pamatuje webový vývojář: Obecně se v populárních rámcích tyto atributy nastavují automaticky. Ale i tak zkontrolujte konfiguraci webového serveru a nastavte vlajku: Set-Cookie HttpOnly; Secure.
Přitom atribut „HTTPOnly“ učiní cookies neviditelnými i pro váš vlastní JavaScript.
- Path-Based Vulnerabilities („cestovní“ zranitelnosti).
Skenner hlásí takovou zranitelnost, pokud najde veřejně přístupný soubor nebo adresář webu s potenciálně důvěrnými informacemi. Například odhaluje jednotlivé soubory s konfigurací systému nebo přístup k celému souborovému systému. Tato situace může nastat, pokud jsou na webu nesprávně nastavena oprávnění.
Jaké nebezpečí: Pokud se souborový systém "vystavuje", útočník může proniknout do rozhraní operačního systému a pokusit se najít složky s hesly, pokud jsou uložena v otevřené podobě (to nedělejte!). Nebo si může odcizit hash hesel a pokusit se je uhádnout, stejně jako se pokusit zvýšit privilegium v systému a proniknout hlouběji do infrastruktury.
Co si pamatuje webový vývojář: Nezapomínejte na oprávnění a konfigurovejte platformu, webový server a webovou aplikaci tak, aby se nemohlo "utečt" z webového adresáře.
- Formuláře pro zadání důvěrných dat se zapnutou funkcí automatického vyplňování.
Pokud uživatel často vyplňuje formuláře na webových stránkách, jeho prohlížeč tuto informaci ukládá pomocí funkce automatického vyplňování.
Formuláře na webových stránkách mohou obsahovat pole s důvěrnými informacemi, například hesla nebo čísla kreditních karet. Pro taková pole je vhodné na samotné stránce vypnout funkci automatického vyplňování.
Jaké nebezpečí: Pokud prohlížeč uživatele uloží důvěrné informace, útočník je může později zachytit, například pomocí phishingu. V podstatě webový vývojář, který na tento detail zapomene, ohrožuje své uživatele.
Co si pamatuje webový vývojář: V tomto případě máme klasický konflikt: pohodlí vs bezpečnost. Pokud webový vývojář myslí na pohodlí uživatele, může se rozhodnout pro automatické vyplňování. Například pokud je důležité dodržovat – doporučení pro přístupnost obsahu pro uživatele se zdravotním postižením.
Pro většinu prohlížečů je možné vypnout automatické vyplňování pomocí atributu autocompete="off", například:
<body> <form action="/cs/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit"> <div> <input type="text" placeholder="Jméno"> </div> <div> <input type="text" id="lname" placeholder="Příjmení" autocomplete="on"> </div> <div> <input type="number" placeholder="Číslo kreditní karty"> </div> <input type="submit"> <input type="hidden" name="trp-form-language" value="cs"/></form> </body>Ale pro Chrome to nefunguje. To se obchází pomocí JavaScriptu, alternativu receptu lze najít .
- Na stránkách není nastavená hlavička X-Frame-Options.
Tento nadpis ovlivňuje značky frame, iframe, embed nebo object. Pomocí něj můžete zcela zakázat vkládání svého webu do rámce. K tomu je třeba nastavit hodnotu X-Frame-Options: deny. Nebo můžete uvést X-Frame-Options: sameorigin, pak bude vkládání do iframe dostupné pouze na vaší doméně.
Jaké nebezpečí: Nepřítomnost takového záhlaví lze využít na škodlivých stránkách pro clickjacking. Pro takový útok útočník vytvoří průhledný rámec nad tlačítky a oklame uživatele. Například: podvodníci umisťují do rámce na webové stránce stránky sociálních sítí. Uživatel si myslí, že kliká na tlačítko na této stránce. Místo toho je kliknutí zachyceno a odesílá požadavek uživatele na sociální síť, kde má aktivní relaci. Takto útočníci rozesílají spam jménem uživatele nebo zvyšují sledující a lajky.
Pokud tuto možnost nezakážete, útočník může umístit tlačítko vaší aplikace na škodlivou stránku. Může mít zájem o váš referral program nebo o vaše uživatele.
Co si pamatuje webový vývojář: Zranitelnost může vzniknout, pokud je na webovém serveru nebo vyrovnávacím zařízení načten konfliktující X-Frame-Options. V takovém případě server a vyrovnávací zařízení jednoduše přepíšou záhlaví, protože mají vyšší prioritu než kód backendové části.
Hodnoty deny a sameorigin pro záhlaví X-Frame-Options budou narušovat funkci webvizoru Yandexu. Aby bylo umožněno používat iframe pro webvizor, je třeba v nastavení napsat zvláštní pravidlo. Například pro nginx lze nastavit takto:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - Zranitelnosti PRSSI (Path-relative stylesheet import).
Toto je zranitelnost ve stylech webu. Nastává, pokud jsou pro přístup k souborům stylů používány relatívní odkazy typu href="/somefolder/styles.css/". Útočník toho využije, pokud najde způsob, jak přesměrovat uživatele na škodlivou stránku. Stránka vloží relativní odkaz do svého URL a napodobí přístup ke stylům. Vytvoří se požadavek jako badsite.ru/.../somefolder/styles.css/, který pod záminkou stylu může vykonávat škodlivé akce.
Jaké nebezpečí: Podvodník může využít tuto zranitelnost, pokud najde další bezpečnostní díru. V důsledku toho lze ukrást uživatelská data z cookies nebo tokenů.
Co si pamatuje webový vývojář: Nastavte záhlaví X-Content-Type-Options: nosniff. V tomto případě prohlížeč zkontroluje typ obsahu pro styly. Pokud se typ liší od text/css, prohlížeč požadavek zablokuje.
Kritické zranitelnosti
- Stránka s polem pro heslo je přenášena ze serveru přes nezabezpečený kanál (HTML form containing password field(s) is served over HTTP).
Odpověď od serveru přes nešifrovaný kanál je zranitelná vůči útokům typu „Man in the middle“. Útočník může zachytit provoz a vložit se mezi klienta a server, když stránka jde od serveru ke klientovi.
Jaké nebezpečí: Podvodník může pozměnit stránku a poslat uživateli formulář pro důvěrné údaje, které odejdou na server útočníka.
Co si pamatuje webový vývojář: Některé stránky místo hesla zasílají uživatelům jednorázový kód na e-mail/telefon. V tomto případě není zranitelnost tak kritická, ale mechanismus zkomplikuje život uživatelům.
- Odeslání formuláře s přihlašovacím jménem a heslem přes nezabezpečený kanál (Login Form Is Not Submitted Via HTTPS).
V tomto případě se od uživatele na server odesílá formulář s přihlašovacím jménem a heslem přes nešifrovaný kanál.
Jaké nebezpečí: Na rozdíl od předchozího případu se již jedná o kritickou zranitelnost. Zachytit důvěrné údaje je snazší, protože není potřeba psát pro to kód.
- Používání knihoven JavaScript se známými zranitelnostmi.
Během skenování se nejpoužívanější knihovnou stal jQuery s širokým rozsahem verzí. V každé verzi je alespoň jedna, a to i více známých zranitelností. Dopad může být různý – závisí na povaze zranitelnosti.
Jaké nebezpečí: Pro známé zranitelnosti existují exploity, například takové:
Co si pamatuje webový vývojář: Pravidelně se vracejte k cyklu: vyhledání známých zranitelností – odstranění – ověření. Pokud vědomě používáte zastaralé knihovny, například pro podporu starých prohlížečů nebo pro úsporu rozpočtu, hledejte možnosti odstranění známé zranitelnosti. - Mezisiteové skripty (XSS).
Cross-Site Scripting (XSS), nebo mezisiteové skripty, jsou útoky na webovou aplikaci, kdy se v databázi objeví škodlivý kód. Pokud Qualys zjistí tuto zranitelnost, pak potenciální útočník může vložit nebo již vložil svůj js skript do kódu webu pro provádění škodlivých činností.Uložené XSS (Stored XSS) jsou nebezpečnější, protože skript se vkládá na serveru a spouští se pokaždé, když je napadená stránka otevřena v prohlížeči.
Održené XSS (Reflected XSS) se snadněji provádějí, protože zlovolný skript lze vložit do HTTP požadavku. Aplikace obdrží HTTP požadavek, neověří data, zabalí je a okamžitě odešle. Pokud útočník zachytí provoz a vloží skript typu
<script>/*+что+то+плохое+*/</script>, odejde ze strany klienta škodlivý požadavek.
Jasný příklad XSS: js sniffery, které napodobují stránky pro zadání CVC, platnosti karty a tak dále.
Co si pamatuje webový vývojář: V hlavičce Content-Security-Policy použijte atribut script-src, aby prohlížeč klienta načítal a vykonával pouze kód z důvěryhodného zdroje. Například script-src 'self' zařazuje do whitelistu všechny skripty pouze z naší stránky.
Nejlepší praxí je Inline kód: povolte pouze inline javascript pomocí hodnoty unsafe-inline. Taková hodnota povoluje použití inline js/css, ale nezakazuje připojování js souborů. V kombinaci se script-src 'self' zakazujeme spouštět externí scénáře.Jasně logujte všechny pomocí report-uri a sledujte pokusy o vkládání do webu.
- SQL injekce.
Zranitelnost říká, že existuje možnost vložení SQL kódu na web, který se přímo obrací na databázi webu. SQL injekce je možná, pokud data od uživatele nejsou escapována: neověřují se na správnost a okamžitě se používají v dotazu. Například se to stane, pokud formulář na webu nezkoumá shodu vstupu s typem dat.Jaké nebezpečí: Pokud útočník tento dotaz zadá do takového formuláře, může zničit databázi nebo vyzradit důvěrné informace.
Co si pamatuje webový vývojář: Nedůvěřujte tomu, co přichází z prohlížeče. Ochrana je nutná na straně klienta i serveru.
Na straně klienta napište kontrolu polí pomocí JavaScript.
Vestavěné funkce v populárních rámcích také pomáhají escapovat podezřelé znaky na serveru. Na serveru se také doporučuje používat parametrizované dotazy k databázím.
Určete, kde přesně dochází k interakci s databází na webové aplikaci.
Interakce nastává, když získáváme nějaké informace: dotaz s id (změna id), vytvoření nového uživatele, nový komentář – nové záznamy v databázi. Zde mohou vznikat sql-injekce. I když odstraníme záznam z databáze, může nastat sql-injekce.
Obecná doporučení
Nevynalézejte kolo – používejte ověřené rámce. Obecně jsou populární rámce bezpečnější. Pro .NET to jsou ASP.NET MVC a ASP.NET Core, pro Python – Django nebo Flask, pro Ruby – Ruby on Rails, pro PHP – Symfony, Laravel, Yii, pro JavaScript – Node.JS- Express.js, pro Java – Spring MVC.
Sledujte aktualizace dodavatele a pravidelně aktualizujte. Zranitelnost najdou, poté napíšou exploit, zveřejní ho a vše se opakuje znovu. Přihlaste se k odběru aktualizací stabilních verzí od dodavatele softwaru.
Kontrolujte přístupová práva. Z pohledu serveru vždy nahlížejte na svůj kód tak, jako by byl celý, od prvního do posledního písmene, napsán vaším nejnenáviděnějším nepřítelem, který se snaží zničit váš web a narušit integritu vašich dat. Tím spíše, že někdy tomu tak skutečně je.
Používejte klony, testovací prostředí a teprve potom přenášejte na produkci. To pomůže, jednak se vyhnout chybám a nedostatkům v produktivním prostředí: produktivní prostředí přináší peníze, prostoje produkčního prostředí jsou kritické. Při přidávání, opravování nebo uzavírání nějakého problému je vhodné provádět práce v testovacím prostředí, poté zkontrolovat funkčnost a nalezené zranitelnosti, a teprve potom plánovat práce s produktivním prostředím.
Chraňte webovou aplikaci pomocí a integrujte s ním zprávy od skeneru zranitelností. Například v DataLine se jako spojení služeb používají Qualys a FortiWeb.
Zdroj: habr.com
