30 Semptember 2020 (Updated 10 October 2020)

The Czech Republic has the highest number of e-shops per capita in Europe. According to available data as of September 30, 2020, there are more than 42,000 online stores in the Czech Republic (https://www.ceska-ecommerce.cz).

A very popular method for running a small or medium-sized eshop is e-shop rental. This solution is available in a few clicks, including extensions on GDPR or already implemented Czech carriers and payment methods.

Because of I'm not familiar in this area, I started looking for companies which offer e-shop rental. Based on the total number of e-shops, rental prices and reviews and eventually I chose these companies for security testing:

What was my goal?

The goal was not to do a full penetration test or to do some official security test. It was always a short and simple test of a web application in order to determine whether an attacker has an opportunity to take control of the entire e-shop, in the role of a regular customer.. The most common web vulnerability is invalid validation and sanitization of user input. The goal was to find an XSS-type vulnerability that would allow it to manipulate the e-shop administration.

XSS is a very dangerous vulnerability in this case. When an attacker can put XSS to an administration as a regular user, he can do with e-shop any action. If an administration is opened by a user with the highest privileges, the attacker can get an e-shop under his control. He can create a new admin account or steal an existing admin account.

XSS is a client-side vulnerability so all events going to be logged under a victim account (IP address, time, browser).

The goal was to find out how the companies are secured and how they approach fixes when vulnerabilities are reported.

Method of testing

In all cases, it was only a manual test of the web application, which I carried out on my (testing) e-shop with selected companies.

Shoptet

Shoptet is the leader of Czech e-commerce in providing e-shop solutions. In their online stores, 3.5 million unique shoppers spend CZK 30 billion a year. At the time of the test, Shoptet was managing about 21,500 e-shops.

The company informs about security in this way (https://www.shoptet.cz/bezpecny-hosting):

Findings:

E-shop:

  • Session Fixation
  • Stored XSS
  • ???? (not fixed)

Administration:

  • Stored XSS – Order comment (found during re-testing)
  • Stored XSS – Find a user with XSS in the name (found during re-testing)
  • Stored XSS - Customer name

Description:

Stored XSS (E-shop)

Templates Classic and Waltz had vulnerable user input Name and surname in the client center. If XSS was saved, the script was executed on all websites of the e-shop. The code was run only for the currently logged user.

Stored XSS - Customer name

Names of shoptet eshop’s customers are not validated and the customers can save their name with characters such as <>"/' and others, so they can save names with XSS payload. E-shop side correctly encode special characters in the response.

The problem appeared elsewhere, in the administration, specifically in the Customer Statistics section (/admin/statistika-zakazniku). In the chart legend, the user input was not handled correctly and the script was executed here.

If an attacker created any order on the e-shop and changed his name after sending the order to <script>alert(1)</script>, an alert was displayed in the customer statistics. The name of the customer changes dynamically on the administration page, so the attacker only had to make the change after the order was sent. Any e-shop user could insert a malicious script into the administration using this type of attack.

Examples of attacks:

An attacker sent payment and changed his name to XSS. In the following examples, I will describe the impact of the XSS vulnerability when an administration section was opened by the admin account (probably the most common case).

Change the price of a product

When the statistics were opened, the price of the product selected by the attacker changed automatically.
Video

Client database stealing

When the script was run, a "Permanent link" for exporting customers was automatically generated. This generated link was immediately sent to the attacker's server.
Video

Change of the payment gateway/bank account

If the attacker was financially motivated, he could change the bank accounts for receiving money.
Video

Change of e-shop owner

An attacker could add another administrator account or steal an existing account. This could have happened because the current password was not required in the Administration->Store Account section to change the access email or password.

The following video shows the entire complex attack, including automatic logout after the password and email change script has been executed. The victim was immediately denied access and password recovery was not possible.

Timeline

22. 6. 2020 Reported vulnerabilities to email in security.txt
(https://www.shoptet.cz/.well-known/security.txt)
22. 6. 2020 Acknowledged by Shoptet
24. 6. 2020 Fixed Stored XSS in administration
25. 6. 2020 Fixed Stored XSS in two templates
26. 6. 2020 Reported another two Stored XSS in administration. The first as privilege user, the second case could be saved from regular e-shop's user
26. 6. 2020 Fixed XSS that could be saved from regular e-shop's user
20. 8. 2020 Shoptet inform that in Semptember I will publish reported vulnerabilities. Fixed XSS in administration that could save the privilege user
24. 8. 2020 Fixed Session Fixation
17. 9. 2020 Change email or password in the administration is now require current password
Status 30 Semptember 2020: one issue in the e-shop section was not still fixed - but in this moment is not security issue

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 was the only tested e-shop solution that did not have the usual Stored XSS vulnerability.That is, a vulnerability where a regular customer set his name on XSS, and this script was saved into the administration. So I started researching the web application a little more in order to find another vulnerability leading to the same result.

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.

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)