Zhruba před rokem jsme v DataLine spustili vyhledávat a analyzovat zranitelná místa v aplikacích IT. Služba je založena na cloudovém řešení Qualys, o jehož provozu . Během roku práce s řešením jsme provedli 291 skenů pro různé stránky a nashromáždili statistiky o běžných zranitelnostech webových aplikací.
V níže uvedeném článku vám přesně ukážu, jaké díry v zabezpečení webových stránek se skrývají za různými úrovněmi kritičnosti. Podívejme se, jaké zranitelnosti skener obzvláště často nacházel, proč k nim může dojít a jak se chránit.
Qualys rozděluje všechny zranitelnosti webových aplikací do tří úrovní kritičnosti: nízkou, střední a vysokou. Pokud se podíváte na distribuci podle „závažnosti“, zdá se, že všechno není tak špatné. Existuje jen málo zranitelností s vysokou úrovní kritičnosti, většinou jsou všechny nekritické:
Ale nekritický neznamená neškodný. Mohou také způsobit vážné škody.
Nejčastější „nekritické“ zranitelnosti
- Zranitelnosti smíšeného obsahu.
Standardem pro zabezpečení webu je přenos dat mezi klientem a serverem prostřednictvím protokolu HTTPS, který podporuje šifrování a chrání informace před zachycením.
Některé stránky používají smíšený obsah: Některá data jsou přenášena prostřednictvím nezabezpečeného protokolu HTTP. Tak se to přenáší nejčastěji pasivní obsah – informace, které ovlivňují pouze zobrazení webu: obrázky, styly css. Ale někdy se to takhle přenáší aktivní obsah: skripty, které řídí chování webu. V tomto případě můžete pomocí speciálního softwaru analyzovat informace s aktivním obsahem přicházejícím ze serveru, upravovat své odpovědi za běhu a zajistit, aby stroj fungoval způsobem, který jeho tvůrci nezamýšleli.
Novější verze prohlížečů varují uživatele, že stránky se smíšeným obsahem nejsou bezpečné a obsah blokují. Vývojáři webových stránek také obdrží upozornění prohlížeče v konzole. Například takto to vypadá uvnitř :
Je to nebezpečnější: Útočníci používají nezabezpečený protokol k zachycení informací o uživateli, nahrazování skriptů a odesílání požadavků na web jeho jménem. I když návštěvník webu nezadal údaje, nechrání ho to před phishing – získávání důvěrných informací pomocí podvodných metod. Například pomocí skriptu můžete uživatele přesměrovat na nebezpečný web, který se vydává za web, který je uživateli známý. V některých případech vypadá škodlivý web ještě lépe než originál a uživatel může sám vyplnit formulář a odeslat důvěrná data.Co by si měl webový vývojář pamatovat: I když správce webu nainstaloval a nakonfiguroval certifikát SSL/TLS, může dojít k chybě zabezpečení kvůli lidské chybě. Pokud jste například na jednu ze stránek vložili nikoli relativní odkaz, ale absolutní odkaz z http a navíc jste nenastavili přesměrování z http na https.
Smíšený obsah na webu můžete zjistit pomocí prohlížeče: prohledejte zdrojový kód stránky, přečtěte si oznámení ve vývojářské konzoli. Vývojář se však bude muset s kódem šťourat dlouho a zdlouhavě. Proces můžete urychlit pomocí automatizovaných analytických nástrojů, například: , bezplatný software Lighthouse nebo placený software Screaming Frog SEO Spider.
Zranitelnost může také nastat kvůli problémům se starším kódem - kódem, který byl zděděn. Pokud jsou například některé stránky generovány pomocí staré šablony, která nepočítá s přechodem webů na https.
- Soubory cookie bez příznaků „HTTPOnly“ a „secure“.
Atribut „HTTPOnly“ chrání soubory cookie před zpracováním skripty, které útočníci používají k odcizení uživatelských dat. Příznak „zabezpečený“ neumožňuje odesílání souborů cookie jako prostý text. Komunikace bude povolena pouze v případě, že je k odesílání cookies použit zabezpečený protokol HTTPS.
Oba atributy jsou specifikovány ve vlastnostech cookie:
Set-Cookie: Secure; HttpOnlyJe to nebezpečnější: Pokud vývojář webu tyto atributy neurčil, útočník by mohl zachytit informace uživatele ze souboru cookie a zneužít je. Pokud se pro ověřování a autorizaci používají soubory cookie, bude moci unést relaci uživatele a provádět akce na webu jeho jménem.
Co by si měl webový vývojář pamatovat: V populárních frameworkech se tyto atributy zpravidla nastavují automaticky. Přesto zkontrolujte konfiguraci webového serveru a nastavte příznak: Set-Cookie HttpOnly; Zajistit.
V tomto případě atribut „HTTPOnly“ učiní soubory cookie neviditelnými pro váš vlastní JavaScript.
- Zranitelnosti založené na cestě.
Skener ohlásí takovou chybu zabezpečení, pokud najde veřejně přístupný soubor nebo adresář webu s potenciálně důvěrnými informacemi. Detekuje například jednotlivé konfigurační soubory systému nebo přístup k celému systému souborů. Tato situace je možná, pokud jsou na webu nesprávně nastavena přístupová práva.
Je to nebezpečnější: Pokud souborový systém „vyčnívá“, útočník se může dostat do rozhraní operačního systému a pokusit se najít složky s hesly, pokud jsou uloženy jako prostý text (nedělejte to!). Nebo můžete ukrást hash hesel a hrubou silou heslo a také se pokusit zvýšit oprávnění v systému a posunout se hlouběji do infrastruktury.
Co by si měl webový vývojář pamatovat: Nezapomeňte na přístupová práva a nakonfigurujte platformu, webový server, webovou aplikaci tak, aby nebylo možné „uniknout“ z webového adresáře.
- Formuláře pro zadávání citlivých údajů s povoleným automatickým vyplňováním.
Pokud uživatel často vyplňuje formuláře na webových stránkách, jeho prohlížeč tyto informace uloží pomocí funkce automatického vyplňování.
Formuláře na webových stránkách mohou obsahovat pole s citlivými informacemi, jako jsou hesla nebo čísla kreditních karet. U takových polí se vyplatí vypnout funkci automatického vyplňování formulářů na samotném webu.
Je to nebezpečnější: Pokud prohlížeč uživatele uchovává citlivé informace, může je útočník zachytit později, například prostřednictvím phishingu. V podstatě webový vývojář, který na tuto nuanci zapomněl, nastavuje své uživatele.
Co by si měl webový vývojář pamatovat: V tomto případě máme klasický konflikt: pohodlí vs bezpečnost. Pokud webový vývojář přemýšlí o uživatelské zkušenosti, může vědomě zvolit automatické doplňování. Pokud je například důležité dodržovat – doporučení pro přístupnost obsahu pro uživatele se zdravotním postižením.
U většiny prohlížečů můžete zakázat automatické doplňování pomocí atributu autocompete="off", například:
<body> <form action="/cs/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>Ale to nebude fungovat pro Chrome. To se obchází pomocí JavaScriptu, lze najít variantu receptu .
- Záhlaví X-Frame-Options není v kódu webu nastaveno.
Toto záhlaví ovlivňuje značky rámce, rámce iframe, vložení nebo objekt. S jeho pomocí můžete zcela zakázat vkládání vašeho webu do rámce. Chcete-li to provést, musíte zadat hodnotu X-Frame-Options: deny. Nebo můžete zadat X-Frame-Options: sameorigin, pak bude vložení do prvku iframe dostupné pouze ve vaší doméně.
Je to nebezpečnější: Absenci takové hlavičky lze na škodlivých stránkách využít k clickjacking. Pro tento útok útočník vytvoří průhledný rámeček nad tlačítky a oklame uživatele. Například: podvodníci rámují stránky sociálních sítí na webu. Uživatel si myslí, že kliká na tlačítko na tomto webu. Místo toho je kliknutí zachyceno a požadavek uživatele je odeslán na sociální síť, kde je aktivní relace. Takto útočníci rozesílají spam jménem uživatele nebo získávají odběratele a lajky.
Pokud tuto funkci nezakážete, útočník může umístit tlačítko vaší aplikace na škodlivý web. Může ho zajímat váš program doporučení nebo vaši uživatelé.
Co by si měl webový vývojář pamatovat: K chybě zabezpečení může dojít, pokud je na webovém serveru nebo nástroji pro vyrovnávání zatížení nastaveno X-Frame-Options s konfliktní hodnotou. V tomto případě server a balancer jednoduše přepíší hlavičku, protože mají vyšší prioritu ve srovnání s backendovým kódem.
Hodnoty deny a sameorigin v hlavičce X-Frame-Options budou narušovat činnost webového prohlížeče Yandex. Chcete-li povolit použití prvků iframe pro webový prohlížeč, musíte v nastavení napsat samostatné pravidlo. Například pro nginx to můžete nakonfigurovat takto:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - Chyby zabezpečení PRSSI (import šablony stylů relativní k cestě).
Jedná se o zranitelnost ve stylu webu. Dochází k němu, pokud jsou pro přístup k souborům stylů použity relativní odkazy jako href="/cs/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ží do své adresy URL relativní odkaz a simuluje volání stylů. Obdržíte požadavek jako badsite.ru/…/somefolder/styles.css/, který může pod rouškou stylu provádět škodlivé akce.
Je to nebezpečnější: Podvodník by mohl tuto chybu zabezpečení zneužít, pokud by našel jinou bezpečnostní díru. V důsledku toho je možné ukrást uživatelská data z cookies nebo tokenů.
Co by si měl webový vývojář pamatovat: Nastavte hlavičku X-Content-Type-Options na: nosniff. V tomto případě prohlížeč zkontroluje typ obsahu pro styly. Pokud je typ jiný než text/css, prohlížeč požadavek zablokuje.
Kritická zranitelnost
- Stránka s polem s heslem je přenášena ze serveru přes nezabezpečený kanál (formulář HTML obsahující pole hesla je obsluhován přes HTTP).
Odpověď ze 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 vklínit se mezi klienta a server, když stránka putuje ze serveru ke klientovi.
Je to nebezpečnější: Podvodník bude moci nahradit stránku a odeslat uživateli formulář pro důvěrná data, který půjde na server útočníka.
Co by si měl webový vývojář pamatovat: Některé stránky odesílají uživatelům místo hesla jednorázový kód e-mailem/telefonem. V tomto případě není zranitelnost tak kritická, ale mechanismus bude komplikovat život uživatelů.
- Odeslání formuláře s přihlašovacím jménem a heslem přes nezabezpečený kanál (přihlašovací formulář není odeslán přes HTTPS).
V tomto případě je formulář s přihlašovacím jménem a heslem odeslán od uživatele na server prostřednictvím nešifrovaného kanálu.
Je to nebezpečnější: Na rozdíl od předchozího případu se již jedná o kritickou zranitelnost. Je snazší zachytit citlivá data, protože k tomu nemusíte ani psát kód.
- Používání knihoven JavaScriptu se známými chybami zabezpečení.
Při kontrole byla nejpoužívanější knihovna jQuery s rozsáhlým počtem verzí. Každá verze má alespoň jednu nebo i více známých zranitelností. Dopad může být velmi odlišný v závislosti na povaze zranitelnosti.
Je to nebezpečnější: Existují exploity pro známé zranitelnosti, například:
Co by si měl webový vývojář pamatovat: Pravidelně se vracejte do cyklu: hledejte známé zranitelnosti - opravte - zkontrolujte. Pokud používáte starší knihovny záměrně, například pro podporu starších prohlížečů nebo pro úsporu peněz, hledejte příležitost opravit známou chybu zabezpečení. - Cross-site skriptování (XSS).
Cross-Site Scripting (XSS), neboli cross-site scripting, je útok na webovou aplikaci, jehož výsledkem je zanesení malwaru do databáze. Pokud Qualys najde takovou chybu zabezpečení, znamená to, že potenciální útočník může nebo již zavedl svůj vlastní skript js do kódu webu, aby provedl škodlivé akce.Uložené XSS nebezpečnější, protože skript je vložen na server a spuštěn při každém otevření napadené stránky v prohlížeči.
Odražené XSS snadněji proveditelné, protože do požadavku HTTP lze vložit škodlivý skript. Aplikace obdrží HTTP požadavek, neověří data, zabalí je a okamžitě odešle. Pokud útočník zachytí provoz a vloží skript jako
<script>/*+что+то+плохое+*/</script>pak bude jménem klienta odeslán škodlivý požadavek.
Pozoruhodný příklad XSS: js sniffery, které simulují stránky pro zadávání CVC, datum vypršení platnosti karty a tak dále.
Co by si měl webový vývojář pamatovat: V záhlaví Content-Security-Policy použijte atribut script-src k vynucení klientského prohlížeče, aby stáhl a spustil kód pouze z důvěryhodného zdroje. Například script-src 'self' přidá na seznam povolených všechny skripty pouze z našeho webu.
Osvědčeným postupem je vložený kód: povolte vložený javascript pouze pomocí hodnoty unsafe-inline. Tato hodnota umožňuje použití inline js/css, ale nezakazuje zahrnutí souborů js. V kombinaci s script-src 'self' zakážeme spouštění externích skriptů.Nezapomeňte vše zaznamenat pomocí report-uri a podívat se na pokusy o jeho implementaci na web.
- SQL injekce.
Zranitelnost označuje možnost vložení kódu SQL do webové stránky, která přistupuje přímo k databázi webové stránky. Vložení SQL je možné, pokud data od uživatele nejsou prověřena: není kontrolována jejich správnost a jsou okamžitě použita v dotazu. K tomu například dochází, pokud formulář na webu nekontroluje, zda vstup odpovídá datovému typu.Je to nebezpečnější: Pokud útočník zadá SQL dotaz do tohoto formuláře, může havarovat databázi nebo odhalit důvěrné informace.
Co by si měl webový vývojář pamatovat: Nevěřte tomu, co přichází z prohlížeče. Musíte se chránit jak na straně klienta, tak na straně serveru.
Na straně klienta napište ověření pole pomocí JavaScriptu.
Vestavěné funkce v populárních frameworkech také pomáhají uniknout podezřelým postavám na serveru. Doporučuje se také používat parametrizované databázové dotazy na serveru.
Určete, kde přesně probíhá interakce s databází ve webové aplikaci.
K interakci dochází, když obdržíme jakoukoliv informaci: požadavek s id (změna id), vytvoření nového uživatele, nový komentář nebo nové záznamy v databázi. Zde může dojít k injekcím SQL. I když odstraníme záznam z databáze, SQL injection je možná.
Obecná doporučení
Neobjevujte znovu kolo – používejte osvědčené rámce. Populární frameworky jsou zpravidla bezpečnější. Pro .NET - 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 - Jarní MVC.
Sledujte aktualizace dodavatele a pravidelně aktualizujte. Najdou zranitelnost, pak napíší exploit, zpřístupní ho veřejnosti a vše se bude opakovat. Přihlaste se k odběru aktualizací stabilních verzí od dodavatele softwaru.
Zkontrolujte přístupová práva. Na straně serveru vždy zacházejte se svým kódem tak, jako by jej od prvního do posledního písmene napsal váš nejnenáviděnější nepřítel, který chce rozbít váš web a narušit integritu vašich dat. Navíc je to někdy pravda.
Použijte klony, testovací místa a poté je použijte pro produkci. To pomůže za prvé vyhnout se chybám a chybám v produktivním prostředí: produktivní prostředí přináší peníze, jednoduché produktivní prostředí je kritické. Při přidávání, opravování nebo uzavírání jakéhokoli problému se vyplatí pracovat v testovacím prostředí, poté zkontrolovat funkčnost a nalezená zranitelnost a poté naplánovat práci s produkčním prostředím.
Chraňte svou webovou aplikaci pomocí a integrovat s ním zprávy ze skeneru zranitelnosti. Například DataLine používá Qualys a FortiWeb jako balíček služeb.
Zdroj: www.habr.com