V závěrečném shrnutí hodnocení soutěže WebTop100 2013 jsem popisoval, jak takové hodnocení vypadá (to je ten článek, kde jsme se naučili, kolik nul má kvintiliarda), kolik si u toho porotce užije legrace a kam všude mu zablokují přístup.
No, víte, ono to zas taková sranda není, takže o co bude dnešní článek méně zábavný, o to bude stejně (málo) technický. Tak nějak lidsky v něm popíšu pár nejčastějších problémů zabezpečení webů, abyste si pod těmi nulami v hodnocení dokázali představit, jak malé nebo velké problémy se na webech dají nalézt. Skočte si zalít to instantní kafe a pojďme na to.
Útok SQL Injection
Pokud se mizerovi podaří na vašem webu úspěšně provést útok SQL Injection, velmi pravděpodobně získá data z databáze vaší aplikace, a to i taková, která běžně na webu nezobrazujete. Tedy např. seznam vašich dodavatelů, objednávky nebo přihlašovací údaje vašich zákazníků.
Někdy je také možné data v databázi změnit, zlý hoch si může radikálně zlevnit některé zboží a poté si ho za tuto super cenu koupit. Záleží na šikovnosti útočníka a na možnostech, které mu chyba ve vaší aplikaci poskytne.
Představte si útok jako vložení dalších příkazů na místo, kde se žádný příkaz neočekává. Například nějaký e-shop může z databáze zobrazovat produkty v určité kategorii, například móda, pomocí dotazu “zobraz všechny produkty z kategorie móda”. Útočník tento dotaz upraví tak, aby se z databáze načetlo trochu více informací, např. takto: “zobraz všechny produkty z kategorie móda a přidej k nim seznam zákazníků a jejich e-mailové adresy, fofrem”.
Tímto typem útoku získali v roce 2012 útočníci 450 tisíc uživatelských e-mailů a hesel z databáze americké firmy Yahoo. Na začátku prosince 2014 tento útok způsobil poprask i mezi uživateli české služby Jabbim. Té útočník zkopíroval přihlašovací údaje 125 tisíc uživatelů, včetně hesel. K oběma službám se ještě vrátíme, nebojte. V soutěži WebTop100 jsme hodnotili celkem 143 webů a z nich 10, tedy asi 7 %, útoku SQL Injection neodolalo.
Útok Cross-Site Scripting (XSS)
Princip útoku spočívá v tom, že útočník spustí nějaký kód v prohlížeči uživatele. Kód v jazyce JavaScript se běžně používá např. pro animace na stránkách nebo pro skrývání různých políček formuláře, jeho možnosti jsou ale mnohem větší.
Pokud útočník na váš web nějaký takový kód vloží a návštěvník danou stránku navštíví, tak jeho prohlížeč ten vložený kód spustí a návštěvníkův prohlížeč bude dělat to, co mu útočník přikázal.
Cross-Site Scripting je tedy útok na uživatele vašeho webu nebo webové aplikace. Lze pomocí něj například změnit přihlašovací formulář na webu tak, aby se vyplněné jméno a heslo odeslalo útočníkovi, nebo lze ukrást tzv. cookies, které identifikují přihlášeného uživatele.
Útočník se tak může vydávat za uživatele, kterému přihlašovací údaje nebo cookies ukradl. Důležité je uvědomit si, že uživatelem vaší aplikace je i administrátor, který vyřizuje objednávky zákazníků nebo přidává zboží.
Útoky Cross-Site Scripting se snaží různým způsobem řešit výrobci prohlížečů i tvůrci webových aplikací, ne vždy se jim to podaří správně. Ochrany v prohlížečích lze někdy obejít, není se čemu divit, hledají totiž onu pověstnou jehlu v kupce sena, když se snaží najít na stránce problém, proti kterému mají uživatele chránit.
Tvůrci webových aplikací mají v podstatě jednu správnou metodu, jak se proti tomuto útoku úspěšně bránit (převodem nebezpečných znaků na jejich bezpečné varianty), přesto se často uchylují k odstraňování nebezpečných znaků, blokování načtení celé stránky, pokud server detekuje nějaký problém, a dalším více nebo spíš méně funkčním ochranám.
Ukazuje se, že stačí jedno drobné chybně ošetřené místečko, díky kterému se “přece určitě nedá žádný problém způsobit!” Jenže na světě je spousta ostřílených a motivovaných mizerů, kteří ví, jak zneužitím drobné chyby zadělat na pořádný problém. To, že to nevíte vy nebo váš programátor, nic neznamená. A to si to prosím neberte osobně.
Chyba, která vede k tomuto útoku je tak častá, že nemá moc smysl vyjmenovávat, kde všude se objevila. Ale pokud nedáte jinak, tak bych jmenoval třeba dvě oblíbené firmy, nejspíš je budete znát: Google a Seznam. A jednu (ne)méně oblíbenou: vaši banku.
Špatně ošetřené nebezpečné znaky, které v naprosté většině vedou k úspěšnému útoku Cross-Site Scripting během pár minut zkoušení, byly k vidění na skoro polovině hodnocených webů ve WebTop100 2014.
Přímý přístup k datům
Pokud vaše webová aplikace špatně ověřuje, kdo má k datům přístup, může se lehce stát, že útočník získá data, která sice na webu běžně zobrazujete, ale která nepatří jemu. Aplikace například zobrazuje vystavené faktury za zboží, které si u vás zákazník nakoupil, a útočník využitím této chyby získá faktury ostatních zákazníků.
Může takto “vydolovat” třeba e-mailové adresy vašich zákazníků a jejich seznam pak prodat vaší konkurenci, které odpadne hodně práce se správným cílením svých reklamních nabídek.
Nejedná se pouze o zobrazování dat, tato chyba se může vyskytnout i třeba při nastavování hesla. Útočník může změnit heslo správci e-shopu, pokud aplikace nebude kontrolovat, jestli se nové heslo nastavuje právě přihlášenému uživateli. V roce 2009 na tuto chybu vsadila Sazka, o rok později tento problém potrápil například americkou společnost AT&T.
Posílání citlivých informací po nešifrovaném spojení
Pokud vaše aplikace posílá data po nešifrovaném spojení, může se stát, že tato data někdo po cestě odposlechne a využije je ke svému prospěchu. Mohou to být přihlašovací údaje vašich zákazníků nebo stahování přijatých plateb z vaší banky.
Šifrované spojení poznáte na první pohled tak, že ve vašem prohlížeči bude adresa začínat na https. To s právě znamená Secure. Ale nejde jen o odesílání hesel a dalších soukromých informací na server, jde také o to, co se ze serveru stahuje do vašeho prohlížeče. Asi byste nechtěli, aby vám někdo měnil stránky, které si prohlížíte, tak, aby vám nabízely ke stažení viry a další nebezpečný nepořádek místo programů, které si opravdu nutně potřebujete nainstalovat.
Některé české společnosti toto již pochopily, a tak například Slevomat podporuje pouze šifrované spojení: cokoliv na web Slevomatu odešlete (třeba adresu, přihlašovací jméno a heslo) a cokoliv si prohlížíte, nemůže být změněno nebo odposlechnuto. Podobně je na tom například prodejce výpočetní techniky Mironet. Další velký prodejce elektroniky CZC.cz přechod údajně chystá.
Od pozemšťanů z Alzy nemám žádné informace, jejich web je zatím pro návštěvníky tak trochu intergalaktická tragédie, alespoň co se možnosti odposlechu a modifikace dat týká – web alza.cz zabezpečené spojení standardně nepoužívá, je ale možné si ho tak nějak ručně zapnout změnou adresy v prohlížeči.
A jak jsou na tom již zmiňovaní Google a Seznam? Celý Google je dostupný jenom na zabezpečeném spojení, a to i včetně YouTube. Některé služby Seznamu již na HTTPS dostupné jsou, snad budou brzy přibývat další. Takovou malou nápovědou a nadějí do blízkého budoucna může být titulní stránka, kterou Seznam nedávno, konkrétně v říjnu 2014, na šifrované spojení převedl.
Co se týká soutěže WebTop100, tak weby se zabezpečeným přihlašováním pomocí HTTPS byste spočítali na prstech jedné ruky, i kdybyste si jich pár usekli sekerou. Samozřejmě omylem.
Špatné ukládání hesel
Velká část uživatelů dnes používá jedno heslo pro přihlašování do více webů nebo webových aplikací. Tím se vystavují poměrně velkému riziku, protože když náhodou útočník nějakým způsobem dostane jejich heslo z jedné aplikace, tak ho potom může použít pro přihlášení i někam jinam a tím může napáchat poměrně značné škody.
Útočník se může dostat i k heslům vašich uživatelů, například pomocí útoku SQL Injection nebo získáním přístupu k zálohám databáze vašeho webu, a vy byste se měli snažit, aby mizera hesla vašich uživatelů nemohl jednoduše jinde použít. Proto se hesla do databáze ukládají v nečitelné podobě. Ne, nešifrují se, protože by je někdo se zlými úmysly mohl rozšifrovat.
Možná se teď oprávněně ptáte, jak by se k databázi a dešifrovacím klíčům dostal. To je správná otázka, pamatujete na útok SQL Injection, který jsem zmiňoval před chvílí? Tak to je jedna z možností. Kolega, který zrovna dostal výpověď pro nadbytečnost, nebo kolega, kterého napadlo si navečer k řešení složitého problému otevřít další láhev jeho oblíbené whisky – tak to jsou další možnosti. Útoky zevnitř není dobré podceňovat.
Hesla se také neposílají e-mailem, protože si je tam může někdo nepovolaný přečíst. A to buď přímo v poštovním programu nebo někde po cestě mezi webem a tím poštovním programem. Heslo by tedy do aplikace měl zadávat jenom uživatel, kterému to heslo patří, aplikace ho v čitelné podobě neukládá ani mu ho nepotřebuje posílat. Nikdy.
Ono takové heslo může o uživateli spoustů věcí prozradit, je to totiž část jeho soukromí. Co si pomyslíte o uživateli, jehož vcelku silné heslo bude znít “radeji_3vdolky#nez@2holky”? Soukromí svých uživatelů by firmy měly maximálně chránit.
Pamatujete, když jsem sliboval, že se ještě vrátíme k Yahoo i Jabbimu? Obě dvě služby měly hesla v databázi uložená v čitelné podobě. Pokud jejich uživatelé používali hesla pro přístup k Yahoo nebo Jabbimu i jinde, například pro přístup k e-mailové schránce, tak… raději nedomýšlet.
Že také používáte jedno heslo na více místech? Jak vidíte, tak to není zrovna nejlepší nápad. Hesla uložená v čitelné podobě měl a možná pořád ještě má web Hospodářských novin ihned.cz. Ten také přístupové údaje zasílá e-mailem a standardně nenabízí ani zabezpečené připojení.
Necelých 12 % webů ze 143 hodnocených ve WebTop100 2014 zasílalo heslo e-mailem (ne všechny weby v hodnocení měly nějakou registraci), do administrace tří webů se šlo dokonce přihlásit pomocí uživatelského jména test a hesla test.
WebTop100 2014
Finální výsledek hodnocení je tedy dost žalostný, 91 webů z těch 143 hodnocených dostalo nula bodů kvůli více nebo méně závažné chybě, pomocí které bylo v naprosté většině možné provést nějaký bezpečnostní útok velmi jednoduše. Skoro by se hodilo napsat levou zadní, kdyby Špaček nějakou přední a zadní měl.
Zneužití části chyb pochopitelně vyžaduje více znalostí nebo motivace nebo času, ale úkolem porotců v soutěži WebTop100 není všem webům hned kompletně vybrat celou databázi a páchat zlo kde se dá.
Máte z článku depresi a strach používat webový prohlížeč? Nemějte. Dnes se dá ochrana webů a webových aplikací stavět tak, aby útoky nešly buď vůbec provést, nebo alespoň měly minimální efekt. A to i přesto, že vývojář daného webu udělá nějakou chybu.
Na závěr vás snad trochu povzbudím odpovědí na otázku, kterou určitě máte na jazyku již od druhého odstavce: ano, i já používám Internet a nakupuji v e-shopech. Věřím jejich vývojářům a majitelům, že na zabezpečení dat svých uživatelů nekašlou. Ale musím se přiznat. Rozhodně nenakupuji ve všech e-shopech.
ČLÁNKY DO MAILU