30. září 2020 (Aktualizováno 10. října 2020)

Česká republika je e-shopovou velmocí. Na počet obyvatel máme nejvyšší počet e-shopů v Evropě. Dle dostupných dat k 30. 9. 2020 existuje v České republice 42 143 internetových obchodů (https://www.ceska-ecommerce.cz).

Pro provozování menšího nebo středně velkého obchodu je velice oblíbený způsob tzv. pronájmu e-shopu. Takové řešení je k dispozici prostřednictvím několika kliknutí, a to včetně doplňků na EET, GDPR nebo již implementovaných českých dopravců a platebních metod.

Jelikož nejsem odborníkem v této oblasti, začal jsem hledat, jaké společnosti na českém trhu poskytují pronájmy e-shopů. Vyhledával jsem především řešení pro menší nebo středně velké obchody. Podle celkového počtu obchodů, ceny za pronájem a recenzí jsem vybral k bezpečnostnímu testu tyto společnosti:

• Shoptet (https://www.shoptet.cz, přes 22 000 e-shopů)
• Eshop-rychle (https://www.eshop-rychle.cz, více než 6500 e-shopů)
• Webareal (https://www.webareal.cz, více než 6500 e-shopů)
• UPgates (https://www.upgates.cz, 1. místo Nejlepší pronájem e-shopů 2020)

Co bylo cílem?

Cílem nebylo provést penetrační nebo nějaký větší bezpečnostní test. Jednalo se vždy o krátký a jednoduchý test webové aplikace za účelem zjištění, zdali má útočník možnost převzít kontrolu nad celým e-shopem, a to v roli běžného zákazníka. Nejběžnější webovou zranitelností je chybná validace a sanitizace uživatelského vstupu. Cílem tedy bylo najít zranitelnost typu cross-site scripting (XSS), která by umožnila manipulovat s administrací eshopu.

XSS je v tomto případě je velice nebezpečná zranitelnost. Podaří-li se vložit útočníkovi XSS do administrace, může vykonávat za uživatele libovolnou činnost. V případě otevření administrace uživatelem s nejvyššími právy může útok zajít až k absolutní kontrole nad celým e-shopem, tj. vytvoření dalšího administrátorského účtu nebo ke krádeži účtu.

XSS je client-side zranitelnost, a tak veškeré požadavky budou v logu vedeny pod uživatelem oběti (IP adresa, čas). Jakékoliv akce vytvořené pomocí XSS by byly velice problematické, protože by byly k nerozeznání od legitimních požadavků.

Cílem bylo zjistit, jak mají společnosti vyřešenou bezpečnost u svého řešení, a také jak přistupují k opravám v případě nahlášení bezpečnostní chyby.

Způsob testování

Ve všech případech se jednalo pouze o manuální test webové aplikace, který byl proveden na vlastním (testovacím) e-shopu u vybraných společností. Kvůli potvrzení, jestli se nejrizikovější zranitelnosti vyskytují opakovaně, došlo k vytvoření dalšího testovacího e-shopu. Pouze u UPgates došlo k ověření zranitelnosti Reflected XSS na jiném internetovém obchodě, a to kvůli ověření chyby na starší šabloně.

Test jsem prováděl ve svém volném čase, postupně po jednotlivých společnostech a dle časových možností.

Shoptet

Shoptet je leader české e-commerce v poskytování e-shopových řešení. V jejich internetových obchodech utratí 3,5 milionů unikátních nakupujících 30 miliard korun ročně. V době testu spravoval Shoptet okolo 21 500 e-shopů.

Na stránkách informují o bezpečnosti tímto způsobem (https://www.shoptet.cz/bezpecny-hosting):

Nalezené zranitelnosti:

E-shop:

• Session Fixation
• Stored XSS
• ???? (není opraveno)

Administrace:

• Stored XSS – Komentář k objednávce (nalezeno během přetestování oprav)
• Stored XSS – Vyhledání uživatele s XSS ve jméně (nalezeno během přetestování oprav)
• Stored XSS - Jméno zákazníka

Popis:

Stored XSS (E-shop)

U šablon Classic a Waltz byl zranitelný uživatelský vstup Jméno a příjmení nacházející se v klientském centru. V případě uložení XSS do tohoto vstupu, docházelo ke spuštění vloženého skriptu na všech stránkách e-shopu. Kód se spouštěl pouze u přihlášeného uživatele e-shopu s uloženým skriptem.

Stored XSS - Jméno zákazníka

Zákazníkům shoptetového e-shopu není validováno jméno a mohou si do něj uložit i nebezpečné znaky jako <>"/' a jiné, mohou si tedy uložit do jména XSS. Pokud nebudu brát v potaz předchozí nalezenou zranitelnost Stored XSS (e-shop používá třeba jinou šablonu), tak je uživatelský vstup v response e-shopu správně ošetřen a nebezpečné znaky jsou převedeny na HTML entity.

Problém se objevil na jiném místě, a to v administraci, konkrétně v části Statistika zákazníků (/admin/statistika-zakazniku). V legendě grafu nebyl uživatelský vstup správně ošetřen a docházelo zde k vykonání skriptu.

Pokud útočník vytvořil na e-shopu libovolnou objednávku, po jejím odeslání si změnil své jméno na <script>alert(1)</script>, tak ve statistikách zákazníků došlo k zobrazení alertu. Na dané administrační stránce se dynamicky mění jméno zákazníka, a proto útočníkovi stačilo změnu provést až po odeslání objednávky. Tímto vektorem útoku mohl jakýkoliv uživatel e-shopu vložit javascriptový skript do administrace.

Příklady zneužití:

Útočník již odeslal objednávku a nastavil si své jméno na XSS skript. V následujících příkladech budou ukázány reálné dopady zranitelnosti, pokud došlo k otevření statistik administrátorem e-shopu (pravděpodobně nejčastější případ).

Změna ceny produktu

Při otevření statistik došlo automaticky ke změně ceny produktu vybraného útočníkem.
Video

Krádež klientské databáze

Při spuštění skriptu byl automaticky vygenerován “Permanentní odkaz” na export zákazníků bez limitu IP adresy (minimum Basic Tarif). Tento vygenerovaný odkaz byl ihned přeposlán na server útočníka.
Video

Změna platebních bran/bankovního účtu

Pokud byl motivem útočníka finanční prospěch, mohl libovolně měnit hodnoty pro příjem peněz. Šlo například o možnost změny bankovního účtu, PayPal účtu nebo jiných účtů.
Video

Změna majitele administrace

Útočník si mohl přidat další administrátorský účet nebo mohl rovnou ukrást účet stávající. K tomuto případu mohlo dojít, jelikož v části Administrace->Správci obchodu nebylo vyžadováno aktuální heslo pro provedení změny přístupového emailu nebo hesla.

Pokud by došlo k tomuto útoku, domnívám se, že by vysvětlování situace zákaznické podpoře nebylo jednoduché. Shoptet má totiž svůj web https://www.eshopiste.cz, kde umožňuje prodat stávající obchod jiným majitelům a u prodání takového e-shopu je nutné provést změnu vlastníka. V případě útoku by se tedy nejednalo o neobvyklou situaci (změna majitele e-shopu).

V následujícím videu je ukázán celý komplexní útok, včetně automatického odhlášení poté, co byl skript na změnu hesla a emailu vykonán. Oběti byl ihned zamezen přístup a obnovení hesla nebylo možné.

Průběh oprav a komunikace

22. 6. 2020 Nahlášeny nalezené zranitelnosti na email uvedený v security.txt
(https://www.shoptet.cz/.well-known/security.txt)
22. 6. 2020 Potvrzeno přijetí ze strany Shoptetu
24. 6. 2020 Opraveno Stored XSS v administraci
25. 6. 2020 Opraveno Stored XSS u dvou šablon v e-shopu
26. 6. 2020 Nahlášeny další dva výskyty Stored XSS v administraci. V prvním případě jako privilegovaný uživatel administrace, v druhém bylo XSS uloženo jako zákazník e-shopu
26. 6. 2020 Opraveno XSS, které bylo vloženo zákazníkem e-shopu
20. 8. 2020 Shoptet informován, že v druhé polovině září dojde ke zveřejnění článku. Již opraveno XSS, které bylo vloženo jako privilegovaný uživatel administrace
24. 8. 2020 Vydaná oprava na Session Fixation
25. 8. 2020 Oprava na Session Fixation zkontrolována
17. 9. 2020 Změna emailu nebo hesla v administraci již vyžaduje ověření aktuálního hesla
Stav k 30. 9. 2020: stále nebyl opraven menší nedostatek v zákaznické části - po přidání několika opatření se již nejedná o bezpečnostní chybu

Eshop-rychle

Další společností je Eshop-rychle, která informuje na svých stránkách o tom, že celkový roční obrat jejich e-shopů je 5 miliard Kč, průměrný denní počet objednávek je 7842 a mají více než 6500 e-shopů.

Na stránkách informují o bezpečnosti tímto způsobem (https://www.eshop-rychle.cz/administrace):

Nalezené zranitelnosti:

Eshop:

• Session Fixation
• ????

Administrace: (Aktualizováno 10. 10. 2020)

• ???? (není opraveno)
• ???? (nalezeno během přetestování oprav – není opraveno) Reflected XSS - id_clankysk
• ???? (nalezeno během přetestování oprav – není opraveno) Reflected XSS - params
• ???? (nalezeno během přetestování oprav – není opraveno) Stored XSS - Náhled objednávky
• Stored XSS – Komentář k produktu
• Stored XSS - Jméno zákazníka

Popis:

Stored XSS - Jméno zákazníka

Eshop-rychle měl identickou zranitelnost jako Shoptet. Svým zákazníkům umožňuje do svých klientských údajů vkládat cokoli, tedy i XSS. V e-shopové části jsou data správně ošetřena a nebezpečné znaky jsou převedeny na HTML entity. V administraci tomu tak ale nebylo a k vykonání záškodnického skriptu docházelo na dvou místech, v sekci „Registrovaní uživatelé“ a „Objednávky“. Útočník mohl přepsat své jméno na <script>alert(1)</script>, což vedlo k zobrazení alertu v administrační části „Registrovaní uživatelé“.

Stejně si mohl počínat při odeslání objednávky. Stačilo nastavit jméno odesílatele na XSS a skript byl poté uložen do administrační sekce „Objednávky“. Velkým rizikem v administraci byla právě sekce „Objednávky”, protože se načte vždy, pokud uživatel otevře v menu položku „E-shop”.

Než došlo k opravě této zranitelnosti, tak byl reportován další výskyt Stored XSS. Neošetřený byl předmět komentáře na hlavní stránce administrace. Útočník mohl uložit skript do předmětu, který se u oběti provedl ihned po přihlášení.

Příklady zneužití:

Útočník u všech ukázek odeslal objednávku se jménem obsahující skript.

Změna ceny produktu/nastavení slevy pro konkrétního uživatele

Při otevření stránky „E-shop“ v administraci automaticky došlo ke změně ceny konkrétního produktu.
Video

Krádež klientské databáze

Při spuštění skriptu byl automaticky vygenerován odkaz na export zákazníků, který byl přeposlán na server útočníka.
Video

Změna platebních bran/bankovního účtu

Útočník mohl libovolně měnit platební údaje. Šlo například o možnost změny bankovního účtu, PayPal účtu aj.
Video

Přidání dalšího účtu

Po otevření kategorie „E-shop“ byl automaticky vytvořen nový účet s přístupem do všech sekcí. Tento účet byl na emailovou adresu útočníka, kterému přišel potvrzovací email.

Přidání dalšího účtu se zamezením vstupu do správce účtů (Přidáno 10. 10. 2020)

V části „Přihlašovací/kontaktní údaje“->„Další účty“ byl zranitelný další uživatelský vstup, a to „Typ účtu“. Do vstupu bylo opět možné vložit XSS.

Při otevření kategorie „E-shop“ byl vytvořen nový účet s typem účtu jako XSS, který přesměroval oběť na jinou stránku. Při zobrazení správce účtu byla oběť vždy přeměrována jinam, nebylo tedy možné jednoduše odstranit nově vytvořený účet.

Průběh oprav a komunikace:

20. 7. 2020 10:07 Odeslán email na zákaznickou podporu s žádostí o kompetentní email pro zaslání nalezených zranitelností (Marek Tóth)
20. 7. 2020 18:10 Informace o zranitelnostech prý mohu zaslat na email podpory
20. 7. 2020 19:36 Vysvětleno, že na email podpory nebudu zasílat tyto informace (M.T.)
20. 7. 2020 19:51 Osobní email, kam mám zaslat nalezená zjištění
20. 7. 2020 20:17 Odeslán dokument s popisem zranitelností (M.T.)
20. 7. 2020 20:24 Potvrzeno přijetí dokumentu
21. 7. 2020 09:35

14. 8. 2020 Eshop-rychle informován, že v druhé polovině září dojde ke zveřejnění článku. „Jestliže už nyní víte, že řešení zabere delší čas a není možné nedostatky napravit do 15.09.2020, kontaktujte mě prosím.“ Stále nebyla opravena riziková zranitelnost Stored XSS v administraci. (M.T.)
18. 8. 2020

21. 8. 2020 Nahlášená zranitelnost Stored XSS v administraci – zranitelný předmět komentáře od zákazníka e-shopu (M.T.)
21. 8. 2020 Eshop-rychle nahrál update opravující Session Fixation a nějaké nahlášené zranitelnosti
24. 8. 2020 Nahrán další update ze strany Eshop-rychle
26. 8. 2020 Updaty přetestovány. Informováno o stavu. Session Fixation, Stored XSS a ???? bylo opraveno. Stále nebylo opraveno vše z prvotního dokumentu. Nalezeny další nové zranitelnosti. (M.T.)
26. 8. 2020

8. 9. 2020 Odeslán email s vysvětlením vážností situace (M.T.)

8. 9. 2020

Stav k 30. 9. 2020: stav se nezměnil, k novému updatu nedošlo

2. 10. 2020 Hovor od jednatele společnosti. Chybně vyhodnoceny rizika nahlášených zranitelností ze strany zaměstnance.
10. 10. 2020 Opraveny nejvíce rizikové zranitelnosti v administraci: 2x Reflected XSS,
Stored XSS - Typ účtu (privilegovaný uživatel), Stored XSS - Náhled objednávky (nutná interakce onmouseover)

Webareal

Další řešení Webareal je od společnosti Bohemiasoft s.r.o., která zmiňuje, že přes jejich řešení je uskutečněno více než 3200 objednávek denně a spravují více než 6500 e-shopů.

Nalezené zranitelnosti:

Eshop:

• Session Fixation
• Reflected XSS (DOM Based)

Administrace:

• ???? (není opraveno)
• ???? (nalezeno během přetestování oprav – není opraveno)
• Stored XSS (DOM Based) - Dashboard (nalezeno během přetestování oprav)
• Stored XSS - Jméno zákazníka

Popis:

Reflected XSS (E-shop)

Zranitelné byly veškeré parametry nacházející se za hashem při třídění produktů. Zranitelných bylo 20 šablon z 23 (kromě Cuprum, Iridium, Cadmium).

Stored XSS - Jméno zákazníka

Tak i do třetice. Totožnou zranitelnost měl i Webareal. Do jména uživatele bylo opět možné vložit skript. E-shop ošetřoval správně znaky na výstupu, ale v administraci tomu tak nebylo. Chyba se nacházela v části „Registrovaní uživatelé“ v podsekci Přehled zákazníků. Útočníkovi stačilo nastavit si své jméno na XSS, a skript se poté vykonal v administračním přehledu.

Během přetestování oprav došlo k nalezení další zranitelnosti - Stored XSS (DOM Based). Neošetřené jméno uživatele bylo možné uložit do administrace, a to do části „Dashboard“. Nebylo zde ošetřeno jméno uživatele, který nejvíce nakupuje most_spending.

Příklady zneužití:

Útočník měl u všech ukázek nastaven XSS jako své jméno.

Změna ceny produktu/nastavení slevy pro konkrétního uživatele

Při otevření „Přehled zákazníků“ došlo automaticky ke změně ceny konkrétního produktu.
Video

Krádež klientské databáze

Při spuštění skriptu byl vygenerován odkaz na export zákazníků. Tento odkaz byl přeposlán na server útočníka.
Video

Změna platebních bran/bankovního účtu

Pokud byl motivem útočníka finanční prospěch, mohl libovolně měnit hodnoty pro příjem peněz. Šlo například o možnost změny bankovního účtu
Video

Přidání dalšího účtu

Po otevření „Přehled zákazníků“ byl automaticky vytvořen nový účet s přístupem do všech sekcí. Tento účet byl na emailovou adresu útočníka, kterému přišel potvrzovací email.

Změna emailu u přihlášeného uživatele – Změna majitele administrace

V sekci “Přihlašovací údaje” bylo možné změnit přihlašovací email bez zadání aktuálního hesla. Útočník tak mohl provést změnu u aktuálně přihlášeného uživatele. Při změně byla oběť automaticky odhlášena a zpětné přihlášení nebylo možné, jelikož starý email nemohl zadat.

Průběh oprav a komunikace:

20. 7. 2020 10:07 Odeslán email na zákaznickou podporu s žádostí o kompetentní email pro zaslání nalezených zranitelností (Marek Tóth)
20. 7. 2020 12:14 Email od programátora Webareal
20. 7. 2020 15:54 Odeslán dokument s popisem zranitelností – bez reakce (M.T.)
22. 7. 2020 10:34 Zjišťován stav přijetí emailu – bez reakce (M.T.)
24. 7. 2020 10:08 Odeslán email znovu na zákaznickou podporu s žádostí o jiný email (M.T.)
24. 7. 2020 10:12 Od zákaznické podpory získán kontakt na jednatele.
24. 7. 2020 10:30 Odeslán email jednateli společnosti včetně popisu zranitelností (M.T.)
24. 7. 2020 11:10 Zpráva od programátora, čerpal dovolenou. Dokument předal programátorům k nápravě.
24. 7. 2020 11:45 Jednatel společnosti potvrzuje předání dokumentu programátorům.
14. 8. 2020 Webareal informován, že v druhé polovině září dojde ke zveřejnění článku. Stále nebyla opravena riziková zranitelnost Stored XSS. (M.T.)
17. 8. 2020 Opraveno Session Fixation
18. 8. 2020 Zpráva o opravě Reflected XSS v eshopu a Stored XSS v administraci
19. 8. 2020 Oprava přetestována. Reflected XSS a Stored XSS – oprava pouze částečná. Reportované nové zranitelnosti. (M.T.)
17. 9. 2020 Zranitelnosti Reflected XSS, a obě formy Stored XSS byly opraveny. Přidáno ověření aktuálního hesla při změně emailu. Nebyly opraveny některé zranitelnosti z 19. 8. a jedna zranitelnost z prvotního reportu.
Stav k 30. 9. 2020: stav se nezměnil, k novému updatu nedošlo

UPgates

UPgates nabízí e-shopové řešení, které je velmi kladně hodnoceno v recenzích. Vítěz srovnání "Nejlepší pronájem e-shopů 2020" uskutečněný portálem 5 Nej. Dále je na 3. místě (2.místo v pronájmu eshopu) dle uživatelského hodnocení na stránkách vybrat-eshop.cz.

Nalezené zranitelnosti:

Eshop:

• Session Fixation
• Reflected XSS
• ????

Administrace:

• Session Fixation
• ????
• ???? (nalezeno během přetestování oprav – není opraveno)
• Server-Side Request Forgery – XSS, LFI
• Email Spoofing

Popis:

UPgates bylo jediné testované e-shopové řešení, které nemělo obvyklou Stored XSS zranitelnost. Tedy zranitelnost, kdy běžný zákazník nastavil své jméno na XSS, a tento skript se propsal do administrace. Upgates uživatelský vstup dobře sanitizuje a do administrace je vstup uložen bez nebezpečných znaků. Webovou aplikaci jsem začal zkoumat tedy trochu více s cílem najít jinou zranitelnost vedoucí ke stejnému výsledku.

Reflected XSS (E-shop)

U některých starších šablon byl na stránce s výsledky vyhledávání zranitelný parametr phrase.

Server-Side Request Forgery (Administrace)

Grafický editor v UPgates načítá skrze proxy zadanou URL.

https://testovaci-eshop.admin.upgates.com/graphics/configurator/?url=https://testovaci-eshop.upgates.com&do=iframeContentProxy

Problémem bylo, že UPgates neomezoval uživatele v zadané adrese a útočník mohl načíst libovolnou URL. Kromě zobrazení stránky došlo k vypsání obsahu do response na doméně UPgates.

SSRF -> Reflected XSS

Pomocí SSRF chyby bylo možné načíst vlastní URL obsahující XSS. Obsah dané stránky se propsal do response, tím došlo k vykonání skriptu na UPgates doméně.

SSRF -> Local File Inclusion

Co změnit celou URL a zkusit načíst lokální soubor? Půjde to?

Ups!.. Tak prý ano 🙃 Toto ale nebylo cílem testování a další soubory proto nebyly zkoušeny. Pravděpodobně by bylo možné se dostat k velmi zajímavým souborům a logům. Pokud by útočník nebyl nějak omezen přístupovými právy, mohl by útok vyeskalovat až do Remote Code Execution (RCE).

Zpět ale k Reflected XSS…

K vykonání skriptu bylo nutné znát adresu k administraci a dále bylo nutné, aby byl uživatel přihlášený. Adresu k administraci je možné zjistit jednoduše. Tvar adresy vypadá takto:

nazevEshopu.admin.upgates.com [Demo]
nazevEshopu.admin.s[cisloServeru].upgates.com [Produkční obchod]

Veškerá potřebná data lze získat zobrazením zdrojového kódu e-shopu, protože veškeré obrázky se načítají právě s použitím těchto informací ze static serveru.

Co se týče limitace, aby byl uživatel přihlášený k administraci, tak by stačilo nějakým způsobem dostat odkaz k uživateli.

Ehm...Nějakým způsobem?🤔 Reálný útočník nebude teoretizovat, je tedy nutné poukázat na reálný dopad a dostat odkaz k oběti. Když už to musí být, tak ať to nějak vypadá.🙂

Email Spoofing (Spear phishing)

Před popisem chyby, mám připravený menší test. Oběti dorazily tyto emaily. Můžete prosím vyhodnotit jaký email je pravý a jaký je podvržený?

Pokud stále váháte, tak třeba pomůže poslední screen.

Zobrazit výsledek

Dotazy od zákazníků e-shopu je možné odbavit skrze administrační rozhraní. Ve zprávě je umožněno editovat veškeré emailové vstupy - odesílatele, příjemce, předmět, obsah emailu a také přílohu. Chybně byl ošetřen vstup pro odesílatele, protože bylo možné použít doménový email @upgates.com. Tímto způsobem mohl útočník odesílat podvržené UPgates emaily, a to včetně ověřených SPF, DKIM, DMARC záznamů. Tím, že záznamy souhlasily, nebyl email nikdy vyhodnocen jako SPAM, například Google občas označoval tyto emaily jako „Důležité“.

ID zprávy v hlavičce emailu bylo tvořeno z názvu e-shopu. Stačilo si zaregistrovat testovací e-shop se slovem jako „Support“ nebo „Podpora“ a mohlo to pomoci ke zvýšení důvěryhodnosti emailu.

Příklady zneužití:

Kombinací zjištění Email spoofing (Spear phishing) a SSRF -> Reflected XSS bylo možné zaslat klientům email s odkazem vedoucí na jejich administraci. Odkaz obsahoval Reflected XSS, který provedl nadefinovanou činnost od útočníka. V případě, že nebyl uživatel přihlášený k administraci, tak byl prvně přesměrován na přihlašovací stránku. Po přihlášení byl zpět přesměrován na stránku s XSS. Při otevření odkazu s Reflected XSS došlo k vykonání požadavku, následně byla oběť přesměrována do administrace.

Změna ceny produktu

Po otevření odkazu automaticky došlo ke změně ceny u konkrétního produktu.
Video

Krádež klientské databáze/krádež přístupových údajů k API

Po otevření odkazu došlo ke krádeži přihlašovacích údajů k API. API je možné používat k exportu zákazníků, změně cen produktů nebo objednávek (https://www.upgates.cz/api-v2)
Video

Změna platebních bran/bankovního účtu

Po otevření odkazu došlo ke změně platebních údajů pro platbu v e-shopu.
Video

Přidání dalšího účtu

Po otevření odkazu byl automaticky vytvořen nový administrátorský účet.

Průběh oprav a komunikace:

27. 7. 2020 13:40 Odeslán email jednateli společnosti, dotaz jakým způsobem bude zašifrován soubor (kvůli LFI zranitelnosti) (Marek Tóth)
27. 7. 2020 13:51 Jednatelem vybrán způsob šifrování
27. 7. 2020 14:52 Odeslán dokument s popisem zranitelností (M.T.)
27. 7. 2020 14:55 Potvrzeno přijetí dokumentu
14. 8. 2020 UPgates informován, že v druhé polovině září dojde ke zveřejnění článku. Stále nebyly opraveny rizikové zranitelnosti (M.T.)
17. 8. 2020

20. 8. 2020 Opravy nasazeny na produkční servery.
21. 8. 2020 Všechny nahlášené zranitelnosti opraveny. Během přetestování nalezena menší zranitelnost. Chybí ještě pár doporučujících nastavení. (M.T.)
Stav k 30. 9. 2020: menší zranitelnost stále nebyla opravena, doporučující nastavení také nebylo přidáno

Hodnocení:

U všech řešení bylo možné převzít kontrolu nad celým e-shopem pomocí XSS. U většiny k tomu stačilo pouze to, aby se oběť přihlásila ke své administraci a standardně ji používala (přehled objednávek, přehled zákazníků).

Častokrát chybělo zadání aktuálního hesla při přidání dalšího administrátora, změně emailu nebo při změně hesla. Nastavenou bezpečnostní hlavičku Content-Security-Policy nemělo žádné řešení, a zrovna CSP by výrazně znepříjemnilo použití XSS v administraci. Rád bych ještě dodal, že u všech popsaných příkladů Stored XSS bylo možné použít ten nejzákladnější tvar, tedy zápis za použití script tagů.

Velice kladně hodnotím přístup u Shoptetu, především rychlost oprav administračních zranitelností. Ostatní společnosti začaly opravovat nahlášené zranitelnosti (především ty kritické) až poté, co byly informovány o plánovaném zveřejnění. U Shoptetu došlo k opravení nejrizikovější zranitelnosti do 48 hodin od nahlášení. Jednu věc stále ještě nemají opravenou, ale přidáním několika opatření se již nejedná o bezpečnostní chybu. Shoptet je jediná společnost, která používá security.txt, a to nejenom na hlavním webu, ale také u všech vytvořených e-shopů.

Soubor security.txt výrazně pomáhá při kontaktování kompetentní osoby v dané společnosti, příkladem může být tento test. U Eshop-rychle bylo nutné z mé strany odeslat 3 emaily, než jsem mohl zaslat zjištěné informace. Od prvního emailu až po odeslání zranitelností uběhlo 10 hodin. Dále u Webarealu bylo nutné odeslat 5 emailů a čekat 4 dny než došlo k odpovědi o přijetí dokumentu, celkově bylo psáno na 3 emailové adresy. U UPgates jsem napřímo kontaktoval jednatele společnosti, ne vždy ale jednatelé odpovídají v rozumném čase.

Každý nemusí mít podobnou trpělivost a buď ohlašovatel informace zašle rovnou na zákaznickou podporu, náhodnému zaměstnanci nebo to nemusí zaslat vůbec. Jsou-li zranitelnosti zaslány nekompetentní osobě, může vzniknout bezpečnostní riziko s únikem informací. Pokud tedy nemáte na svém webu ještě security.txt, tak si ho přidejte. Pěkný článek k tomuto tématu sepsal Michal Špaček https://www.michalspacek.cz/k-cemu-je-soubor-security.txt.

UpGates překvapil tím, že neměl klasickou zranitelnost Stored XSS, tak jako ostatní. Zato měl poměrně závažnou server-side chybu (LFI), která sice nebyla více zkoumána, ale domnívám se, že v případě reálného útoku by se útočník mohl dostat k zajímavým informacím. Zranitelnosti byly nasazeny na produkci až po mém informujícím emailu o článku, za to byly opraveny zcela všechny.

U Webarealu stále nebyla opravena administrační zranitelnost z prvního dokumentu, ani nedošlo k opravě poměrně důležité chyby nalezené během přetestování oprav. Nejvíce rizikové zranitelnosti byly však již opraveny.

Eshop-rychle byl opakovaně upozorněn na některé neopravené zranitelnosti. Odpověď ve stylu, že o tom ví a opraví to do 4 měsíců neberu jako odpověď hodnou “početného a kvalifikovaného týmu Eshop-rychle plného programátorů, administrátorů, síťových specialistů...“. Možná jen nastala chyba v předání informací vývojářům. Nebo je taky možné, že těch prioritních chyb nebo věcí k opravě mají mnoho, o to více bych váhal nad použitím tohoto e-shopového řešení. Potvrzeno jednatelem společnosti, problém byl opravdu v předání informací, k 10. 10. 2020 již byly nejvíce rizikové zranitelnosti opraveny.

Závěr

Značná část společností se na svých stránkách pyšní kvalitním bezpečnostním řešením, zmiňují investice do zabezpečení a prezentují zákazníkům texty, za které by se nemusel stydět ani Marek Prchal. Realita byla však jiná.

Každá z testovaných společností měla závažnější zranitelnost, kvůli které mohl kdokoli získat kontrolu nad celým e-shopem. Celkový počet zranitelných internetových obchodů byl přes 34 500. Nejedná se jen o české e-shopy, některé testované společnosti figurují i na jiném trhu. S klidným svědomím mohu asi zmínit, že více než 50% všech českých e-shopů mělo kritickou zranitelnost.

Závažnost útoku vždy závisela na právech uživatele. Pokud administraci používal uživatel s nejvyššími právy (pravděpodobně nejčastější případ), mohlo nenápadně dojít k založení dalšího administrátorského účtu, nebo dokonce k odcizení účtu. V případě nižších práv mohlo dojít ke změně obsahu webu, změně cen produktů nebo k jiným různým aktivitám dle přístupu uživatele.

Společnosti, které nabízejí e-shopy k pronájmu, by se měly zabývat bezpečností svých produktů stejně prioritně, jako řeší vzhled šablon, vývoj nových funkcí, optimalizaci webu a jiných věcí. V případě výskytu bezpečnostní problému totiž výrazně neohrožují jen sebe, ale také ohrožují podnikání svých klientů.

Doporučení

Vývojáři by měli být obezřetní a zaměřit se na to, jaký vstup nechávají uživatele uložit. Vždy se doporučuje vstup od uživatele validovat a sanitizovat, tj. odstranit nebezpečné znaky. V každém případě musí být vždy výstup ošetřen proti XSS. I jenom jeden neošetřený výstup může mít veliké škody, příkladem může být tento bezpečnostní test. XSS není jen alert s jedničkou 🙂.

Určitě bych doporučil všem klientům testovaných společností, aby si zkontrolovali administraci svého e-shopu. Především bych doporučil zkontrolovat všechny účty, které mají přístup do administrace. V případě zjištění neznámého nebo podezřelého účtu, jej raději smažte. V případě omylu nebude problém založit přístupový účet znovu. Ponechání takového účtu by mělo větší následky. Pokud se domníváte, že ve vaší administraci proběhla podezřelá aktivita, bude nejlepší, pokud kontaktujete zákaznickou podporu vašeho pronajatého řešení.

Závěrem bych chtěl poděkovat advokátní kanceláři ROWAN LEGAL za právní konzultaci (https://rowan.legal)