Studie: Třetina českých e-shopů má bezpečnostní problémy!

Tohle je tak trošku netradiční studie na našem webu. Tentokrát to není až tolik čtení pro typického marketéra z e-shopu. Mnohem víc potěší vaše vývojáře nebo dodavatele webu. Ti by si ho měli přečíst na 100 %. Je to totiž dost možná nejzávažnější a nejdůležitější článek, který jsme u nás kdy měli.

Autorem této studie je Vláďa Smitka z Lyntu, bezpečnostní výzkumník a spoluorganizátor konference WordCamp Praha:

V e-shopech se zpracovává velké množství osobních dat zákazníků, a tak by jedním ze základních kritérií měla být samozřejmě jejich bezpečnost. Přestože bezpečnostní problémy mohou přinést fatální důsledky, bývá tato oblast často velmi podceňována.

Při provozování libovolných online projektů je třeba přijmout fakt, že internet není bezpečné místo a že náš projekt bude doslova pod palbou nejrůznějších útočníků. V minulosti jsem provedl pokus a na novém serveru s čerstvou IP adresou spustil web, který jsem nikde nepropagoval. První útoky na server začaly již po 8 minutách.

Na toto musíme být dobře připraveni. Bohužel internetová bezpečnost je velmi složitá disciplína, která vyžaduje mnoho technických dovedností, a to nejen v oblasti vývoje, ale i ve správě serverů a sítí. Zároveň jde doba stále dopředu, a tak to, co je bezpečné dnes, nemusí být bezpečné zítra.

Vzal jsem tedy dataset 35 tisíc českých e-shopů a zkoumal, zda na nich nejsou některé zjevné bezpečnostní problémy a zda naleznu alespoň náznaky toho, že se bezpečnostní otázku snažil někdo řešit.

Výsledky nedopadly nejlépe.

31 % e-shopů nepoužívá HTTPS a dává všanc data uživatelů

Nutnost používat šifrovaný protokol HTTPS dnes asi není třeba zdůrazňovat. Nechceme, aby si kdokoliv po cestě od počítače návštěvníka po náš e-shop mohl odchytnout přihlašovací a osobní údaje nebo do provozu vložit svůj kód.

Přestože by protokol HTTPS měl být samozřejmostí, stále jej velké množství webů nemá. Konkrétně 10 913 e-shopů nepoužívá HTTPS – buď jej server vůbec nepodporuje, nebo je certifikát vystaven pro úplně jinou doménu. Dalších 1 952 mělo při testování technické problémy, nebo blokovalo naše testování. Mezi problémy patří i chybná konfigurace, kdy certifikát není platný pro všechny varianty domény – s a bez www. Je dobré si proto všechny varianty vyzkoušet a rovnou ověřit, že správně funguje i přesměrování.

To, že e-shop používá HTTPS, ještě neznamená, že ho používá správně. Mohou být například podporované velmi slabé šifry, které neplní svůj účel, nebo je implementace zranitelná vůči některému známému útoku. „Kvalitu HTTPS“ nám může pomoci otestovat nástroj SSL Server Test, který nastavení serveru oznámkuje. Není důvod, proč v tomto testu nezískat hodnocení A+. Všechny weby, které mají HTTPS aktivní, jsem tedy otestoval v tomto nástroji:

Pozitivní je, že většina webů má hodnocení alespoň A. K získání maximálního hodnocení tak většinou zbývá pouze nasadit bezpečnostní HTTP hlavičku HSTS, která minimalizuje riziko modifikace provozu při přesměrování z HTTP na HTTPS. O hlavičkách si povíme podrobněji v další části článku.

Maximální hodnocení A+ získalo pouze 1 373 e-shopů. To ukazuje i na to, že se správným nastavením HTTPS nikdo u zbylých e-shopů příliš nezabýval a neudělal si ani základní test pomocí volně dostupných online nástrojů.

Známku B (1 946) získaly weby především z důvodu podpory zastaralých protokolů a metod šifrování. C (270) je udělena typicky navíc za nepodporu aktuálního protokolu TLS1.2. Velké prohlížeče oznámily konec podpory protokolů starších než TLS1.2 v první polovině roku 2020 – postižené weby tedy v moderních prohlížečích mohou přestat během několika měsíců fungovat.

Hodnocení F je uděleno, když jsou použity staré zranitelné SSL knihovny, nebo obsahuje jiné závažné konfigurační nedostatky, kdy šifrovaný protokol neplní svou roli. Tyto problémy má 682 e-shopů.

TLS 1.3

Komunikační protokoly se stále vyvíjí, a tak byl v srpnu 2018 standardizován nový protokol TLS 1.3 pro šifrovaný provoz. Jeho hlavní charakteristikou je to, že zahodil podporu starých slabých šifer a omezil možnosti pro vyjednávání o použitých šifrách mezi serverem a klientem. To s sebou přináší jednak vyšší výkon při navazování šifrovaného spojení a druhak také vyšší bezpečnost.

Podporu nového protokolu TLS 1.3 jsem detekoval na 4 155 e-shopech.

HTTP/2 může zrychlit web. Správně ho používá jen 38 % e-shopů

Dalším důležitým zlepšením původního protokolu HTTP je jeho nová verze HTTP/2, kterou je (rozhodnutím tvůrců prohlížečů) možné používat pouze se šifrovaným připojením. Tento nový protokol přináší především zlepšení výkonu paralelním načítáním statických zdrojů, což je především pro e-shopy, kde se typicky stahuje mnoho náhledů produktů, obzvláště výhodné. Správnou konfiguraci protokolu HTTP/2 jsem detekoval na 13 449 e-shopech.

Za zmínku stojí také fakt, že o použití HTTP/2 se snaží mnohem více webů. Bohužel ale používají nesprávnou konfiguraci, a tak tento protokol nefunguje. Problémem jsou zde především starší operační systémy serverů, které nepodporují rozšíření ALPN pro vyjednání komunikačního protokolu mezi prohlížečem a serverem (v řeči správců serverů je třeba mít knihovnu OpenSSL ve verzi vyšší než 1.0.2). HTTP/2 dříve fungovalo i se starším rozšířením NPN – to například v Chrome do května 2016. Mnoho správců tak nasadilo protokol HTTP/2 ve staré konfiguraci a později jeho funkčnost už nezkoumali.

77 % e-shopů zcela ignoruje bezpečnostní HTTP hlavičky!

Samotný web může ovlivňovat chování prohlížeče v různých situacích. Činí tak pomocí nejrůznějších HTTP hlaviček, které přikládá do komunikace. Hlavičkami se často řídí například cachování, ale lze ovlivnit i jeho bezpečnostní funkce. To mají na starosti bezpečnostní HTTP hlavičky, které říkají, jak se má prohlížeč chovat, když detekuje podezřelé uživatelské vstupy, načtení cizích zdrojů, otevření stránky v rámcích a v několika dalších situacích.

Pokud už dojde k bezpečnostnímu problému, tyto hlavičky slouží jako další vrstva ochrany vašeho webu, jež mohou významně pomoci redukovat jeho dopady (alespoň v moderních prohlížečích). Některé z nich dokonce mohou donutit prohlížeč návštěvníka reportovat bezpečnostní problém, a tak se o něm můžete velmi brzo dozvědět a zareagovat (můžete použít službu https://report-uri.com/). Jedná se tak především o preventivní opatření.

Pokud se začnete zabývat bezpečností vašeho webu, zcela jistě velmi brzo narazíte na doporučení implementace alespoň některé z nich. U některých je nasazení velmi jednoduché, u některých může být složitější. Zjednodušeně platí, že čím více jich používáte, tím lépe. Úplná absence bezpečnostních hlaviček však typicky značí, že se bezpečností webu zatím vůbec nikdo nezabýval.

Podíval jsem se tedy na zoubek bezpečnostním hlavičkám českých e-shopů. Počty bezpečnostních hlaviček na e-shopech, kde se podařilo test provést:

Z výsledků je vidět, že naprostá většina e-shopů bezpečnost bohužel zatím příliš řešit nezačala. 

Ve skupině e-shopů, které používají pouze 1-2 hlavičky, se jedná především o nasazení těch nejjednodušších – X-Frame-Options a HTTP Strict Transport Security.

Jaké hlavičky jsme testovali?

• X-Frame-Options – může blokovat načtení stránky v rámci (brání proti tzv. click jackingu).
• Strict-Transport-Security – vynucuje použití šifrovaného protkolu HTTPS (částečná ochrana proti útoku SSLstrip).
• X-XSS-Protection – upravuje chování ochrany proti XSS v prohlížeči a je možné, aby byla stránka při podezřelé aktivitě úplně zablokována místo pokusů o její opravu. Moderní prohlížeče od této funkcionality postupně ustupují.
• X-Content-Type-Options – nastavuje, aby prohlížeč zpracoval tak, jak bylo nastaveno na serveru – aby například nedošlo k vykonání javascriptu v textovém souboru.
• Referrer-Policy – nastavuje, jaké informace se posílají při odkazování na externí zdroj v závislosti na tom, zda dochází ke změně protokolu – např. HTTPS na HTTP.
• Content-Security-Policy – velmi podrobně řídí, jaké zdroje a z jakých URL je možné do webu vkládat. Umí také instruovat prohlížeč, aby všechny zdroje načítal po HTTPS.
• Expect-CT – umožňuje reportovat problémy s certifikátem, například kdyby došlo k jeho podvržení.
• Feature-Policy – poměrně nová hlavička, která umožňuje vypnout některé funkcionality prohlížečů – například přístupy ke geolokaci, kameře atd.

Plnou škálu bezpečnostních HTTP hlaviček používají následující e-shopy:

• eshop.am-autochemie.cz
• levnesporaky.cz
• delid.cz
• kecky.cz
• shop.miele.cz
• motousti.ibyznys.cz

Sami si můžete udělat jednoduchý online test a zjistit, jak jste na tom.

12,3 % e-shopů používá soubor Security.txt

Na práci bezpečnostního výzkumníka je nejhorší ta část, kdy chcete nahlásit chybu, ale nemáte k dispozici žádný vhodný kontakt. Pak je třeba prohledávat web a hledat kontakty na tvůrce, majitele nebo provozovatele. Nejčastěji však skončíte s obecným info@ mailem, ze kterého se bohužel většinou informace nedostane ke kompetentní osobě.

Tento problém lze vyřešit pomocí souboru security.txt, umístěným ve složce /.well-known/, ve kterém můžete uvést vhodné kontakty pro řešení bezpečnostních problémů. Každý provozovatel webu, který to s bezpečností myslí vážně, by tento soubor na webu měl mít.

4 300 e-shopů z našeho výzkumu mělo tento soubor připraven.

Jak si ve všech výše uvedených ohledem vedou velké české e-shopy (používáme stejnou množinu e-shopů jako v naší studii o SEO).

Vážné bezpečnostní problémy

Dosud jsem se zabýval technickými bezpečnostními problémy, které jsou v gesci především správců serverů a je možné je poměrně jednoduše detekovat. Každý web jsem však podrobil i bezpečnostnímu testu, který zkoumal, zda na nich nejsou zjevné nedostatky, za které je zodpovědný vývojář.

Neošetřené uživatelské vstupy – jednoduchý útok XSS prolomí 6,5 % e-shopů

Připravil jsem jednoduchý automatizovaný test, který se snažil na webu vyhledat rozličné formuláře a odeslat do nich útočný vektor, jenž otestoval základní ošetření uživatelských vstupů. Do webu byl tak poslán kus HTML kódu, který byl potenciálně schopen vykonat na stránce cizí javascript. Cílem bylo zjistit, zda se do výsledné stránky kód propsal.

Pokud tento test vrátil pozitivní výsledek, ověřil tím, že je web náchylný k útoku typu Reflected XSS (Cross site scripting) a případný útočník může do webu vložit vlastní kód například pomocí modifikovaného odkazu. Díky tomu tak lze web libovolně modifikovat: od vložení vlastních reklam přes skripty těžící kryptoměny nebo útočící na jiné servery, stahování malware do návštěvníkova prohlížeče, přesměrování webu na úplně jiný, až například po modifikaci cíle formulářů pro přihlašování a odeslání uživatelského účtu útočníkovi.

Jedná se o velmi závažný problém a nalezl jsem ho prokazatelně na 2 289 e-shopech. Na dalších 786 bylo na problém podezření, ale nepodařilo se ho automatizovaně prokázat.

Je třeba upřesnit, že prováděný test byl opravdu velmi jednoduchý a skutečný stav bude pravděpodobně mnohem horší.

Nejčastějšími místy pro provedení tohoto útoku bylo vyhledávání na webu, což prakticky znamená, že když nejsou ošetřeny vstupy na takto viditelném místě, tak s velkou pravděpodobností nebudou ošetřeny nikde. Problémy se poměrně často vyskytovaly i v dalších formulářích na webu – v parametrických filtrech, přihlašování nebo v políčku pro vložení slevového kódu. Výjimkou však nebyl ani stav, kdy vstupy byly ošetřeny správně a chyba se na web dostala později vložením analytického kódu (např. FB pixel), který do kódu propisoval aktuálně navštívenou URL bez jakéhokoliv ošetření.

Je na místě připomenout, že XSS není jediným útokem, který lze kvůli nevhodně ošetřeným uživatelským vstupům provést. Bezpečnostní problémy se často řetězí, a tak může být od XSS často jen malý krůček k SQL Injection a tím k úniku celé databáze.

Zapomenuté soubory a nástroje

Velkým neduhem mnoha webových stránek je zpřístupnění nejrůznějších nástrojů a souborů s informacemi, které by rozhodně přístupné být neměly.

Jedním z těchto nástrojů může být třeba populární správce databáze Adminer. Ten často vývojář na web nahraje, aby mohl jednoduše provádět změny v databázi, ale bohužel na něj pak často zapomene, neaktualizuje jej a nechá tak otevřená vrátka útočníkům.

Přístupný Adminer má 3,2 % e-shopů!

Přístupný Adminer jsem nalezl na 1 144 e-shopech. Na 974 z nich byl ve verzi 4.6.2 a nižší, což znamená, že je možná plná kompromitace webu. Útočník se z těchto verzí totiž může jednoduše připojit ke svému vlastnímu serveru, kde má zvýšená oprávnění, a z původního serveru tak může vyčítat libovolné soubory – například konfiguraci s hesly do vlastní databáze e-shopu. Prakticky bylo možné si tento útok vyzkoušet v loňské soutěži Capture the Flag WordCamp Praha (https://2019.prague.wordcamp.org/capture-the-flag-reseni-flagu-9/).

Nejedná se přímo o bezpečnostní chybu v Admineru, ale o vlastnost MySQL klienta, kterou jsou postiženy i další databázové nástroje, jako je PHPmyAdmin (nalezl jsem ho na 224 webech). Ten však ve výchozím nastavení (které ale lze změnit) neumožňuje připojení k libovolnému databázovému serveru a útok není možné realizovat.

U 178 e-shopů můžete volně stáhnout zdrojové kódy vč. hesel 

178 e-shopů mělo na svém webu volně přístupný Git repozitář, ze kterého bylo možné stáhnout kompletní zdrojové kódy webu, často včetně hesel do databází, k e-mailovým schránkám a API klíčů k nejrůznějším službám.

Tento problém je záludný v tom, že na první pohled není často viditelný, protože při přístupu na adresu repozitáře je typicky vrácena chyba 403 – přístup zamítnut. To však není proto, že by nebyl přístupný, ale proto, že webserver ve složce repozitáře nenalezl žádný soubor typu index.html a má zakázaný výpis adresářů. Samotné soubory repozitáře však přístupné jsou, když člověk ví, kde je nalézt.

Tomuto problému jsem se v minulosti již podrobně věnoval. 

Přístupné konfigurace

Servery pro aplikace psané v jazyku PHP jsou většinou nastaveny tak, že pokud má soubor příponu .php, tak je vykonán. V opačném případě je uživateli přímo vypsán. Zde nastává problém, jestliže jsou ve složce s aplikací nejrůznější konfigurační soubory s jinými příponami. Útočník se pak může zeptat přímo na konfigurační soubor a pokud nejsou přístupy k němu správně omezeny, okamžitě získá konfigurační informace, často včetně hesel k databázi a dalším službám. Tento problém jsem nalezl na celkem 60 webech a odhalil jsem následující konfigurační soubory.

• 28 × config.neon z aplikací psaných v Nette
• 13 × soubor config.inc nebo config.ini z různých systémů
• 9 × konfiguraci s heslem k (S)FTP (z vývojářských nástrojů Sublime a Visual Studio Code)
• 7 × konfiguraci e-shopového systému Magento – local.xml

3 × settings.py ze špatně nastaveného serveru s aplikací v Python frameworku Django.

Byla testována pouze ta nejběžnější místa, kde se tyto soubory nacházejí, při podrobnějším scanu by podobných souborů bylo nalezeno mnohem více.

315 e-shopů omylem sdílí veřejně zálohy webů či databází

Při nasazování webu nebo jeho migraci často vyexportujeme celý web do archivu a vytvoříme export/dump databáze. Problém je, pokud tyto soubory se zálohou necháme na serveru přístupné. Útočník se z nich dozví všechno o struktuře aplikace, může v ní jednoduše najít slabá místa a v případě dumpu databáze získá uživatelská hesla (v lepším případě silně zahashovaná). Tyto soubory může také vygenerovat nějaký nástroj na zálohování, který se na webu používá. Ať byla příčina jejich vzniku jakákoliv, v 315 případech jsem nalezl zálohy souborů webu nebo jeho databáze.

Správci souborů bez autentifikace

V administraci webové aplikace je často možné nahrávat obrázky a další soubory. Zde máme opět prostor pro problémy. Když se použije známý správce souborů a nezaintegruje se do něj autentifikace, pak může kdokoliv, kdo zná jeho adresu, na web nahrávat soubory – v lepším případě pouze omezenou sadu přípon, například jen obrázky (v některých správcích souborů je však možné soubory přejmenovat). Na nejočekávanějších místech jsem nalezl 64 správců souborů bez autentifikace.

Podobný problém může být i s jednoduchými nahrávacími skripty/uploadery, kde však není patrné, kam se vlastně soubor nahraje. Uploader jsem nalezl na 122 e-shopech, jejich funkčnost jsem dále nezkoumal.

O existenci podobných schovaných funkcí se útočník může dozvědět i pomocí výše zmíněných problémů s přístupným repozitářem nebo zálohou.

Logy/chyby/statistiky

Mnoho informací o webu, jeho problémech a provozu, se může případný útočník dozvědět z veřejně přístupných logů aplikace (obecně access.log, error.log, nebo /wp-content/debug.log redakčního systému WordPress).

167 e-shopů mělo některý z logovacích souborů veřejně přístupný.

Úsměvné může být i využití skriptů pro analýzu logů – často jsou využívány nástroje AWstats nebo Webalizer. V 331 případech jsem výstupy z těchto 2 nástrojů nalezl veřejně přístupné, a web tak krásně prozrazoval veškeré detaily o své návštěvnosti – data, která jinak před svou konkurencí často důsledně tají.

4 878 e-shopů má veřejný soubor s výpisem funkce PHP info

Zdánlivě jako drobný problém se může zdát zpřístupnění souboru s výpisem funkce phpinfo(). V tomto souboru však případný útočník nalezne mnoho interních informací o konfiguraci, ke kterým by se jinak nedostal. Namátkou zde může zjistit například to, že používáte dlouho neaktualizovanou verzi PHP, která může obsahovat bezpečnostní chyby. Z výpisu získá informace, kde jsou na serveru umístěné různé soubory, a to může využít v dalších typech útoků. Z adresářové struktury dokáže odvodit použité nástroje pro správu serveru a může se je pokusit napadnout. Zjistí také jméno uživatele, pod kterým web běží a které se často shoduje s účtem na FTP, díky čemuž může být úspěšnější při pokusech o odhadnutí hesla. Někdy se ve výpisech objeví užitečné proměnné prostředí, ve kterých může být například heslo k databázi. Možností je opravdu hodně.

Obzvláště závažné dopady však může mít výpis této funkce v kombinaci s XSS, kdy útočník může pomocí javascriptu získat chráněná session cookies a ukradnout relaci návštěvníka a tím i jeho účet.

Výpis funkce phpinfo jsem nalezl na 4 878 e-shopech. 401 z nich zároveň patří do skupiny e-shopů s možností XSS a nenápadná chyba informačního charakteru tak dosahuje kritických rozměrů.

Pro zajímavost verze PHP používané na českých e-shopech vyčtené z výpisu phpinfo:

Nejrozšířenější verzí je 5.4, které skončila podpora už v září 2015. Nejstarší nalezená verze 4.3 je bez podpory už od března 2005 – téměř 15 let. Aktuálně podporované verze PHP jsou 7.2 a vyšší.

 

Souhrn a další postup

Na více než 35 tisících českých e-shopech jsem provedl velmi základní a bezpečnostní testování. Tento jednoduchý test ukázal, že téměř třetina českých e-shopů má bezpečnostní problémy různé závažnosti. Na více než desetině e-shopů jsou chyby kritické. To je důsledkem toho, že naprostá většina e-shopů bezpečnost vůbec neřeší, což je patrné například z použití bezpečnostních HTTP hlaviček, které používá pouhá necelá čtvrtina testovaných webů.

Testování probíhalo vlastními automatizovanými nástroji, které problémy hledaly pouze na těch nejběžnějších místech. Plnohodnotné bezpečnostní testování by zcela jistě odhalilo množství dalších problémů.

Nalezené chyby je nyní třeba nahlásit a opravit. Zatím jsem zvládnul chyby oznámit několika stovkám e-shopů – především těm, které poskytovaly soubor security.txt s kontaktem na zodpovědnou osobu. Ruční dohledávání kontaktů je extrémně náročné a získané kontakty jsou často málo relevantní. Protože jsou zjištění z tohoto výzkumu velmi závažná, jsou ohroženy osobní údaje stovek tisíců uživatelů a sám nahlásit chyby nezvládnu, požádal jsem o pomoc Národní CSIRT bezpečnostní tým České republiky, který nalezené problémy také prozkoumá a osloví přímo vlastníky domén.

A co můžete udělat vy?

Otestovat nastavení HTTPS a bezpečnostních hlaviček a zlepšit nastavení. Můžete použít následující online nástroje:

• https://www.ssllabs.com/ssltest/analyze.html
• https://observatory.mozilla.org/
• https://securityheaders.com/

Nechat si na web nasadit soubor security.txt s kontaktem na nahlašování chyb.

Ujistit se, že je váš systém aktualizovaný.

Ověřit, že na webu nemáte ponechané žádné soubory nesouvisející s aplikací nebo prozrazující citlivé údaje.

Provádět alespoň základní pravidelné bezpečnostní testování – můžete k tomu využít služeb autora článku.