Tento web navštívilo 1 247 lidí.“ Blikající číslice ve stylu tachometru, logo TOPlistu pod patičkou, návštěvní kniha o dvě řádky níž. Devadesátá léta a začátek nultých nechávaly návštěvnost viset přímo na stránce – veřejně, pro každého. Dnes je stejné číslo schované v administraci, pod přihlášením a za souhlasem s cookies. Co se vlastně stalo mezi tím?

Zranitelnost ve WordPressu není žádná novinka. Kdo provozuje weby postavené na této platformě, ví, že bezpečnostní záplaty chodí prakticky pořád. O to větší pozornost by měla vzbudit chyba, u které nic z toho neplatí. A přesně takový je případ zranitelnosti, která dostala přezdívku wp2shell. potřeb. Zranitelný kontaktní formulář, děravý e-shopový plugin, opomenutá kontrola oprávnění v nějaké obskurní rozšiřující knihovně – to je denní chleba každého, kdo sleduje bezpečnostní feedy. Zpráva „nová chyba ve WordPress pluginu“ má tak nízkou informační hodnotu, že ji většina lidí přejde bez mrknutí oka.

Webový vývojář v roce 2000 a dnes: Co všechno se změnilo? Představte si, že byste vzali webového vývojáře z roku 2000, posadili ho do stroje času a vysadili v dnešní open space kanceláři.…

WordPress pohání přes 43 % celého webu. Právě proto je terčem neustálých útoků. Jenže kdykoli se objeví titulkové zprávy o „napadených WordPress webech“, klíčový detail bývá pohřben v posledním odstavci — nebo chybí úplně: samotné jádro WordPressu je za útok zodpovědné jen výjimečně.

„Cron mi nějak neběhá.“ Klasická věta, která ve WordPress světě může znamenat cokoli od špatně nastavené WP_SITEURL, přes loopback zablokovaný Cloudflarem, až po fatal error v callbacku, který nechal viset transient doing_cron. WP-Cron totiž není skutečný scheduler — je to pseudo-cron závislý na návštěvnosti webu a HTTP loopbacku, se všemi pastmi, které si dokážete představit. Tenhle článek je hloubkový průchod jeho vnitřnostmi: co se reálně děje při spawn_cron(), kde vznikají race conditions, proč selhává a čím ho v produkci nahradit.

WordPress pohání přes 40 % všech webů na světě. To z něj dělá nejrozšířenější CMS a zároveň nejčastější terč automatizovaných útoků. Boti nepotřebují cílit přímo na vás: systematicky procházejí miliony domén a hledají otevřené dveře. Stačí zapomenutý plugin bez aktualizace, výchozí prefix databáze nebo heslo z uniklé databáze. Tento článek není seznam pluginů. Je to průvodce od základů přes hardening konfigurace až po serverové zabezpečení s konkrétními kroky, které můžete udělat ještě dnes.

AI asistenti často naráží na stejný problém — neznají kontext — tohle platí, zejména pokud člověk potřebuje použít nějakou konkrétní technologii nebo framework. Skvělým příkladem je Nette Framework, hojně využívaný českou PHP komunitou.…

Společnost PeoplePath pořádá v Plzni jednou za dva měsíce workshopy na různá IT témata. Tentokrát bylo hlavním tématem PHPUnit a byl pořízen videozáznam. Ve videu je porovnání různých testovacích framewroků, ale hlavně se…

Při útoku XML External Entity Injection (XXE) může útočník na místo jím vytvořené entity v XML souboru vložit obsah nějakého jiného souboru, třeba takového, ke kterému nemá jinak přístup. Co se stane pak záleží především na vás a vaší aplikaci. O XXE ale píšu hlavně proto, abych na konkrétním příkladu ukázal proč aktualizovat na novější PHP verze spíš rychleji, než pomaleji, protože tenhle problém se už v roce 2020 defaultně vyřešil tak nějak sám vydáním PHP 8.0.

Krádež session id z výpisu phpinfo() je již nějakou dobu známá technika, která se používá k obcházení atributu HttpOnly, který JavaScriptu zakazuje přístup k takto označené cookie (např. PHPSESSID). Mě akorát až teď napadlo řešení, které dovolí phpinfo() zachovat: ty citlivé údaje prostě zcenzurujeme, čímž phpinfo() pro útočníka ztratí část své hodnoty.