Od poloviny minulého roku pracujeme na nové infrastruktuře pro službu WEDOS Global Protection (WGP). Cílem bylo vytvořit řešení, které je robustnější, rychlejší, snadněji udržovatelné a umožňuje nasazovat pokročilejší detekční mechanismy.
Nová infrastruktura nám umožňuje analyzovat nejen HTTP hlavičky, ale i obsah requestu a dokonce i metadata na úrovni TLS komunikace. To otevírá prostor pro techniky jako například JA4 a JA4H fingerprinting a další univerzálnější detekční metody.
V lednu 2026 proběhla postupná migrace na nové řešení. V tuto chvíli by na něm již měli být všichni zákazníci využívající WEDOS Global Protection. Pokud máte aktivní službu WGP a přístup do administrace, pravděpodobně jste si všimli nových možností pro tvorbu pravidel. Administrace samotná ještě projde dalšími úpravami.
Proč nemůžeme být příliš přísní
S novou infrastrukturou jsme schopni technicky implementovat ochranu, která by v mnoha případech dokázala nahradit běžný WAF pro webový provoz na portech 80 a 443. To ale neznamená, že je to vždy správný přístup.
V reálném provozu existuje velké množství nestandardních aplikací a API rozhraní. Pokud nastavíme pravidla příliš přísně, začneme rozbíjet legitimní provoz zákazníků. Proto musí být pravidla navrhována s velkou opatrností.
Bezpečnost je vždy kompromis mezi:
- ochranou infrastruktury
- stabilitou služby
- kompatibilitou s aplikacemi zákazníků
Právě proto máme definované procesy, které určují, jak reagujeme na nové typy útoků.
Vlna scanování zranitelností přes EXTRACTVALUE
Minulý týden jsme zaznamenali zvýšenou aktivitu automatizovaného scanování zranitelností zaměřeného na SQL injection techniky využívající funkci EXTRACTVALUE.
Nejde o novou techniku. Je známá více než deset let a patří mezi tzv. error-based SQL injection. Přesto se pravidelně vrací ve vlnách vždy po zveřejnění nových zranitelností v běžně používaných aplikacích.
Princip je jednoduchý.
Funkce EXTRACTVALUE() slouží v MySQL/MariaDB pro práci s XML daty. Pokud dostane nevalidní vstup, vrátí chybovou hlášku. A právě do této chybové hlášky je možné vložit data z databáze.
Ukázkový payload může vypadat například takto:
EXTRACTVALUE(1, CONCAT(':', (SELECT user())))Výsledkem je chyba databáze, která by za ideálních okolností pro útočníka vypadala následovně:
XPATH syntax error: ':root@localhost'Tedy:
- aplikace vrátí chybu
- chyba obsahuje data z databáze
- útočník získá informace bez nutnosti zobrazit výstup aplikace
To je důvod, proč se tato technika používá v automatizovaných skenerech, je prostě jednoduchá, rychlá a spolehlivá.
Proč se tato technika objevila právě teď
V posledních měsících bylo publikováno větší množství SQL injection zranitelností v různých webových aplikacích a pluginech. Jakmile se podobná zranitelnost objeví v databázi CVE nebo exploit databázích, automatizované nástroje začnou během krátké doby prohledávat internet a testovat dostupné služby.
Například:
- v únoru 2026 byla zveřejněna chyba CVE-2026-24419 v aplikaci OpenSTAManager, která umožňovala získávat data z databáze právě pomocí funkcí
extractvalue()neboupdatexml()prostřednictvím chybových zpráv databáze - další zranitelnosti typu SQL injection byly publikovány v různých webových aplikacích a systémech, například CVE-2025-34038, kde bylo možné spustit libovolné SQL dotazy přes nevalidovaný parametr v HTTP požadavku
- podobné chyby se objevují opakovaně v pluginech a webových aplikacích, kde aplikace přímo používá vstup uživatele při sestavování SQL dotazů bez správného ošetření vstupů
Jakmile je taková zranitelnost zveřejněna, nastává typicky následující scénář:
- publikace zranitelnosti
- zveřejnění exploitu nebo proof-of-concept
- automatizované scanování internetu
- pokusy o identifikaci zranitelných systémů
Nejde tedy o cílený útok na konkrétní web. Jde o systematické testování velkého množství systémů, které se velice snadno promění v takový menší DDoS útok.
Jak vypadalo konkrétní scanování
Níže je ukázka reálného scanování jednoho e-shopu, který má velmi dobře optimalizovaný kód, takže útok zvládl ustát, ale byl výrazně zpomalen. Mimochodem jedná se o náš VEDOS NoLimit Extra, který po velkých optimalizacích ze začátku roku celkem slušně zrychlil.
Souhrn dat:
- 1 cílová doména
- 56 Points of Presence (PoPs), přes které provoz procházel
- 19 858 unikátních IP adres
- 218 577 legitimně vypadajících HTTP požadavků
- délka útoku přibližně 1,5 hodiny
Útočník velmi pečlivě reguloval počet requestů.
Za celou dobu:
- pouze 1 IP překročila 500 requestů
- pouze 9 IP překročilo 100 requestů
- většina IP generovala jen desítky požadavků
To je typické chování moderních scannerů, které hledají zranitelnosti. Před rokem by to bylo něco výjimečného a dobře cíleného, dnes jsou podobné věci na denním pořádku pro masové scanování.
Nejde o přetížení serveru velkým objemem provozu. Jde o dlouhodobé, distribuované testování zranitelností. Nicméně když ke svému provozu přidáte pár tisíc požadavků na formuláře za minutu, už to je znát. A ne každý má tak dobře optimalizovaný web a NoLimit Extra 😉
Na druhou stranu, web vlivem útoku začal postupně zpomalovat a to tak, že to už bylo znatelné. Na grafu vidíte délku spojení na origin server a dobu odpovědi.
Co je na tom zajímavé z pohledu obrany
Útočník použil několik technik, které umožnily obejít základní automatické blokace:
- nízký počet requestů z jedné IP adresy
- distribuovaný provoz z velkého množství zdrojů
- obfuskované SQL payloady
- absence typických signatur útoku
- postupné zatěžování serveru
- a pár dalších, které veřejně nemůžeme prezentovat
To je důležité. Klasické rate limiting mechanismy v takovém případě nefungují, protože:
- každá IP generuje jen malé množství požadavků
- provoz je rozložený v čase
- požadavky vypadají relativně normálně
Pokud by to optimalizoval, tak nějakých 1 – 2K requestů za minutu si nikdo na rychlosti nevšimne. A to je dost.
Co z toho plyne pro ochranu infrastruktury
Takové útoky dnes představují typický „provoz“ na internetu. Nejde už o výjimečnou událost. Takového provozu blokujeme vyšší desítky procent.
SQL injection patří dlouhodobě mezi nejčastější webové zranitelnosti a stále se objevuje v nových aplikacích, často kvůli nesprávnému zpracování vstupů při sestavování SQL dotazů. Většinou leží ochrana na straně tvůrce skriptu, aby tyto vstupy ošetřil. Nicméně pár tisíc requestů do formulářů je prostě slušná zátěž, kterou neodbavíte přes cache.
Z pohledu infrastruktury to znamená:
- útok nemusí server shodit
- ale může ho výrazně zpomalit
- a generovat zbytečnou zátěž
Proto je důležité reagovat rychle, ale zároveň opatrně.
SQL injection řešíme dlouhodobě ale opatrně
SQL injection útoky nejsou nic nového. Patří mezi nejdéle známé a nejčastější webové zranitelnosti a v různých podobách se objevují prakticky neustále.
Proto jsme v rámci WEDOS Global Protection už dříve implementovali sadu pravidel zaměřených na nejčastější techniky, například:
- time-based SQL injection (
sleep(),pg_sleep()) - pokusy o načtení souborů z filesystemu (
load_file()) - klasické injection patterny (
union select,or 1=1) - pokusy o manipulaci s SQL komentáři
- další typické signatury používané automatizovanými nástroji
Tato pravidla používáme dlouhodobě a fungují velmi dobře. Zároveň je ale používáme opatrně. Důvod je jednoduchý. Velké množství zákazníků používá API rozhraní, která mohou obsahovat:
- SQL-like dotazy
- filtrační výrazy
- vlastní query syntaxe
- nestandardní parametry
Pokud bychom nastavili pravidla příliš přísně, začali bychom blokovat legitimní provoz. Proto se snažíme držet princip: detekovat konkrétní techniku útoku, ne obecná klíčová slova
Proč jsme nové pravidlo neměli nasazené dříve
Pravidlo proti SQL injection přes EXTRACTVALUE() jsme měli připravené již dříve.
Nebyl to nový nápad. Při historických testech na reálných datech ale naráželo na jeden problém a to false positive.
Konkrétně některé nestandardní API požadavky zákazníků obsahovaly podobné konstrukce jako:
- funkce
- závorky
- textové výrazy
- kombinace parametrů
A jednoduchá detekce by vedla k blokování legitimního provozu. To je situace, které se snažíme vyhnout za každou cenu. Zvláště proto, že WGP chrání služby VEDOS, kde zákazníci s touto ochranou nepočítají.
Z pohledu infrastruktury je totiž horší rozbít skript zákazníka než nechat projít jednotlivý scanovací požadavek. Přeci jen neošetřené vstupy u skriptu jsou odpovědností majitele webu.
Co se změnilo
Aktuální vlna scanování změnila situaci. Je masivní, profesionální a nejde po jednotlivých zákaznících. Cílem může být doslova každý. Navíc se celkem efektivně vyhýbá řadě detekčních technik.
Možností jak toto vyřešit máme vícero, ale řekněme že tato konkrétní SQLi si prostě zaslouží také vlastní pravidlo. Otevřela se tak starší issue, porovnali jsme původní návrhy, doporučení OWASP a nová data.
Od původního návrhu jsme se navíc už posunuli pořádně kupředu a část falešně pozitivních zvládneme případně vyřešit jinak. A tak vznikl koncept nového pravidla.
Jak probíhalo testování a nasazení pravidla
Nasazení nového pravidla neprobíhá jedním krokem. Je to řízený proces.Typický postup:
1) návrh pravidla
Cíl:
- detekovat konkrétní techniku útoku
- minimalizovat false positive
- zachovat nízkou výpočetní náročnost
2) test v izolovaném prostředí
Ověřujeme:
- funkčnost
- výkon
- stabilitu
Například:
- jestli pravidlo správně detekuje payload
- jestli neblokuje běžné requesty
- jestli nezvyšuje latenci
3) backtest na reálných datech
To je klíčová fáze. Používáme historické logy z produkčního provozu a simulujeme:
- běžný provoz
- API requesty
- známé útoky
Cílem je zjistit:
- kolik útoků pravidlo zachytí
- kolik legitimních requestů by zablokovalo
Výsledek v tomto konkrétním případě:
- 100 % detekce aktuální vlny scanování
- 0 false positive v testovaných datech
- více než 99,9 % detekce starších SQLi útoků
To je v prostředí sdíleného hostingu velmi dobrý kompromis.
Proč není cílem 100 % detekce všech SQL injection
Tohle je důležité vysvětlit. WEDOS Global Protection není náhradou za bezpečně napsané skripty. Jednak stále vznikají nové a nové varianty a než k nim bychom vytvořili pravidlo tak může být pozdě, a také není možné udělat univerzální pravidla pro každého. To co se hodí pro blog anebo eshop nebude správně fungovat pro API.
Zodpovědnost za bezpečnost aplikace vždy zůstává na straně vývojáře.
Naším hlavním cílem je:
- snížit zátěž infrastruktury
- omezit automatizované scanování
- zlepšit stabilitu služby
Finální review a nasazení
Po dokončení testování následuje finální kontrola. Součástí je manuální review bezpečnostním týmem a vývojáři. Zaměřujeme se hlavně na:
- kontrolu výkonu – pravidlo nesmí být zbytečně náročné
- simulace provozu – tohle je spíše o tom na kterou vrstvu pravidlo umístit
- analýza možných slabin – je třeba myslet na řadu dalších pravidel a hlavně uživatelská pravidla
V této fázi využíváme i automatizované nástroje pro analýzu pravidel, včetně modelů strojového učení, které pomáhají identifikovat potenciální problémy nebo nečekané scénáře.
Teprve poté dochází k nasazení.
V tomto konkrétním případě byl čas od detekce útoku po nasazení pravidla přibližně 4 dny.
Ovšem v případě kritické situace jsme schopni distribuovat nová pravidla velmi rychle. Od zapsání pravidla do systému to aktuálně zvládáme u přibližně 90 % lokalit do 5 minut a šechny lokality přibližně do 15 minut.
Distribuce probíhá paralelně do všech lokalit infrastruktury. Naším cílem je globální nasazení do 5 minut. To je technický cíl, na kterém aktuálně pracujeme.
Závěr
Podobné vlny scanování zranitelností dnes patří k běžnému provozu na internetu. Nejde o výjimečné události, ale o kontinuální proces, který se opakuje pokaždé, když je zveřejněna nová zranitelnost nebo exploit.
Naším cílem není blokovat každý jednotlivý pokus o útok za každou cenu.
Naším cílem je udržet infrastrukturu stabilní, minimalizovat zbytečnou zátěž serverů a reagovat rychle na nové techniky, které se v provozu objeví.
Nová infrastruktura WEDOS Global Protection nám v tom dává výrazně lepší možnosti.
Tento konkrétní případ ukazuje, jak dnes v praxi probíhá reakce na nové typy „neakutních“ útoků od identifikace problému přes analýzu dat až po nasazení pravidla do produkce.
Bezpečnost není jednorázové nastavení. Je to kontinuální proces. A právě na tom je postavena i filozofie WEDOS Global Protection.