Při aktualizaci Drupalu jsem narazil na problém v jedné z bezpečnostních kontrol nad HAProxy. Měl jsem tam jedno velké pravidlo, které blokovalo jakékoliv volání PHP souborů ve /core, /vendor, /misc, /includes, /libraries a sites/*/files. Myšlenka byla správná. Nic z toho se přes HTTP volat nemá. Jenže Drupal při aktualizaci používá vlastní interní entrypointy (např. /core/authorize.php), a ty se tak přes update formulář venku zkrátka volají z prohlížeče. Takže pravidlo sepnulo a aktualizace selhala.
Vyřešil jsem to rozdělením do tří samostatných vrstev:
D01 - ochrana proti backdoorům
Tvrdý blok pro jakýkoliv .php v sites/*/files. To je čisté RCE a nemá se to nikdy spouštět. Zůstává bez kompromisů.
D02 - blokace chráněných PHP v interních adresářích/core, /vendor, /misc, /includes, /libraries se pořád blokují, ale s výjimkou tří legitimních entrypointů, které potřebuje Drupal 8 až 11 během instalace a aktualizací:/core/authorize.php, /core/install.php, /core/rebuild.php.
D03 - session check
Vyjmenované entrypointy se povolí jen tehdy, pokud má request od uživatele Drupal správnou session cookie. Pravidlo D03 ještě projde revizí a bude potřebovat zřejmě trochu přísnější validaci. Nicméně WAF pravidla WEDOS Global Protection mají bránit hlavně hledání zranitelností a automatizovaným útokům. Nemají řešit zabezpečení místo programátorů.
Závěr
Udržel jsem striktní ochranu (hlavně files/), ale zároveň umožnil Drupalu, aby si během update sáhl na to, co skutečně potřebuje.
Komentáře