Dneska jsem pro vás sepsal několik situací z praxe. Zjistěte, jak najít admina, změnit heslo nebo jak vypnout WP-cron.
Obsah
- Jak „ukrást“ uživatele
- Nelze změnit heslo z odkazu v e-mailu
- Jak vypnout WP-cron a proč to dělat
- Jak najít odkaz, který není ve zdrojáku
Jak „ukrást“ uživatele
Když máte přístup na ftp, můžete se následujícím postupem dopracovat k legitimnímu přístupu do WordPressu.
- V souboru wp-config.php najdete přihlašovací údaje do databáze. přihlaste se pomocí Admineru a uvedených údajů.
- Ujistěte se, že používáte správný prefix pro tabulky, je také uložený ve wp-config.php, standardně je to wp_.
- V tabulce wp_usermeta si vyfiltrujte meta_key = wp_capabilities, kdo má v meta_value „administrator“, ten vás zajímá. Často to bývá uživatel s user_id == 1. Právě tuto hodnotu si zapamatujte.
- V tabulce wp_users si najděte uživatele s ID == výše nalezená hodnota (obvykle to bývá 1, první uživatel).
- Změňte pole user_email, starý si poznačte, zadejte svůj a záznam uložte.
- Běžte na přihlašovací stránku webu wp-login.php a klikněte na Zapomněli jste heslo? Uveďte jméno uživatele nebo přímo váš e-mail. Pokud chodí e-maily, dorazí vám transakční e-mail pro změnu hesla.
- Změňte heslo a normálně se přihlaste.
Dříve bylo možné změnit heslo přímo v databázi, protože bývalo hashované algoritmem MD5, který Adminer umí zpracovat. Ale nebylo to bezpečné, takže už to naštěstí nejde, používají se lepší algoritmy.
Nelze změnit heslo z odkazu v e-mailu
Pokud jste v minulém tipu dospěli až do fáze, že má přijít e-mail s odkazem na vytvoření hesla, někdy se stane, že nedorazí. Příčina bude zřejmě následující: Nefunguje odesílání e-mailů, tzn. hosting neposkytuje funkci mail() v PHP a na webu není SMTP plugin pro odesílání z externího SMTP serveru.
Odlišujme to, že příchozí zpráva spadla do spamu nebo nebyla doručena vůbec (ale byla prokazatelně odeslána). Řešení této situace je jiné, viz můj starší newsletter o doručování e-mailů.
Dále se pak stává, že se po kliknutí na odkaz pro vytvoření hesla nestane nic, nebo se zobrazí chyba:
- Odkaz je neplatný a vede např. na subdoménu webu track.vasestranky.cz, ne na hlavní.
- Adresa zobrazí chybu 41x nebo 50x, např. chyba gateway nebo jiná podobná (hlásí ji webový server Apache nebo nginx).
- Web je uzavřený do servisního režimu a url pro reset hesla je zneplatněna.
- Vložíte nové heslo do formuláře, ale následně vás aplikace nepřihlásí a ani nehlásí chybu.
Tyto čtyři situace znám z praxe a obvyklý důvod a řešení je následující:
- Pokud je pro rozesílání také transakčních e-mailů použita externí služba, např. Mandrill nebo Mailgun, která vyžaduje vlastní subdoménu pro rozesílání a ještě případně pro sledování odkazů, může se stát, že transakční zprávy pro reset hesla obsahují neplatný odkaz. Nezjistil jsem, proč se to děje, zřejmě je to nějaké korekce url na straně WordPressu. Také jsme zažili, že subdoména byla zrušena, což samotné rozesílce nevadilo, ale resetovací odkaz prostě nebyl platný, WordPress je generoval do černé díry. Nastavení této služby je potřeba aktualizovat a ujistit se, že jsou zadané správné údaje.
- Nastavení webového serveru omezuje délku adresy a počet parametrů, např. v případě Nginx je to large_client_header_buffers. Může se to stát na VPS, které někdo nastavoval ad hoc, sdílené hostingy tím netrpí. Ale pokud je adresa opravdu velmi dlouhá, tento limit existuje i tam.
- Pokud je aktivní nějaký plugin jako Maintenance, žádné url, kromě vyjmenovaných, nefungují. Takže bude potřeba servisní režim vypnout. Pokud chcete, aby se klient podíval na web, který připravujete a který máte v servisním režimu, takto si heslo nevygeneruje.Je třeba to vykomunikovat.
- Pokud byste měli zakázané cookies, tak by bylo potřeba je povolit. Ale roli hrají také soli, které jsou uloženy.. tedy mají být uloženy v souboru wp-config.php. Hodně webů tam místo náhodných řetězců mívá pouze základní větu místo složitého řetězce. Tímto generátorem si je vytvořte a vložte do wp-config.php.
Setkali jste se s jinou situací, kdy nešlo resetovat heslo? Napište mi, sbírám je místo motýlů.
Jak vypnout WP-cron a proč to dělat
Základním předpokladem je vědět, že cron a WP-cron jsou dvě rozdílné věci a nesmějí se zaměňovat.
Systémový cron
Služba cron funguje v operačním systému na serveru, ten je na ní závislý. Jejím principem je spouštění různých příkazů v zadaný čas (rok, měsíc, den, den v týdnu, hodina, minuta). Čas je řízen vnitřním časovačem, který je iniciován hardwarem a obvykle synchronizován přes internet (protože vnitřní hodiny počítače nejsou přesné).
Cron se zpravidla nastavuje přímo v konfiguračních souborech na serveru, častěji pak ve webové administraci hostingu.
Pokud by teroristický útok nebo jiná katastrofa narušila globální časové servery, situace by vyžadovala koordinovanou mezinárodní odpověď, aby se obnovila synchronizace času a zajistila stabilita různých systémů a sítí, které jsou na přesném čase závislé.
–ChatGPT
WP-cron
WordPress má svou variantu, službu pojmenovanou WP-cron. Její úlohy jsou spouštěny nikoliv na základě vnitřního časovače, jaký má operační systém, ale načtením libovolné stránky webu. Jinými slovy: jakmile někdo zadá adresu webu, spustí se služba WP-cron, která provede naplánované události (crontasky). A to obvykle dřív, než se stránka vůbec zobrazí.
Z toho vyplývají dvě věci:
- na webu, na který nikdo nechodí, se WP-cron nespustí,
- na webu, kam chodí málo lidí, se spouští nepravidelně (tzn. zadané časy se nemusí dodržet a mohou mít zpoždění).
Web spí, dokud na něj někdo nepřijde. V případě naplánovaného článku na půlnoc se nejspíš stane, že se publikuje až ráno, když se tam vy jako správce přijdete podívat, co je nového.
Férové je ale přiznat, že cron vám spustí jakýkoliv požadavek, takže třeba i bot, který váš web skenuje. Ale pokud se na něm nic neděje, i boti přestanou chodit. V případě, že WP-cron nefunguje (jeho adresa /wp-cron.php končí chybou), tak se neprovedou naplánované události (crontasky): nepublikují se naplánované články, nezálohuje se web, nezkontrolují se nové aktualizace a další naplánované události.
Proč bych měl/a WP-cron vypínat?
Důvodem je nevyzpytatelnost a nemožnost plánovat přesné spouštění událostí. V informačním systému, který používáme ve firmě, jsem potřeboval přidat plánovač na každých pět minut. Mám na výběr, jak to zařídit:
- ze serveru volat každých pět minut skript wp-cron.php, což obvykle vede ke zvýšené zátěži serveru, protože normální WP-cron také běží,
- vypnout WP-cron (viz dále), nastavit systémový cron a volat jej každých pět minut,
- vypnout WP-cron, nastavit externí monitorování např. pomocí Uptime Robotu, tedy vytvořit „falešnou“ cron službu,
- vytvořit si v pluginu vlastní skripty místo crontasků a volat je ze serveru v požadovaných intervalech (na cron ve WP se nespoléhat) – tohle dělají importní/exportní pluginy.
Výměna WP-cronu za systémový cron
Nastavení se provádí v souboru wp-config.php (přečtěte si o cronu článek na developer.wordpress.org)
define('ALTERNATE_WP_CRON', true);
define('DISABLE_WP_CRON', true);
Zajistit běh externího cronu (webového nebo systémového), příklad:
*/15 * * * * curl https://www.example.com/wp-cron.php?doing_wp_cron&cron=true > /dev/null 2>&1
Pro přehled aktuální tasků a plánovačů používám třeba plugin WP Crontrol.
Jak najít odkaz, který není ve zdrojáku
Wordfence je nástroj pro zabezpečení a ochranu webu. Věnovat se mu budu jindy, dneska jsem ale narazil na situaci, kdy mi hlásil napadení webu. Na titulní stránce našel odkaz považovaný za malware, viz obrázek.
Ve zdrojáku stránky samozřejmě žádný takový odkaz nebyl, pomocí DevTools prohlížeče jsem žádný požadavek s touto adresou nenašel, takže zbývá jediná cesta – vydat se do databáze. Pomocí Admineru jsem nechal prohledat všechny tabulky, hledal jsem jen část adresy tak, aby byla jedinečná, ale pokud možno co nejkratší: „forwardmy“.
Výsledek byl nalezen v post_content titulní stránky a jejích x revizích. Po pravdě mě opravdu překvapilo, když jsem stránku editoval a skutečně jsem našel natvrdo vložený kód včetně obalujícího <script . Obsah ještě nebyl zpracován Gutenbergem, ale starým editorem, nicméně stránka je šablonou upravená na míru a obsah pole post_content se nepoužívá a nezobrazuje. Proto je nebylo třeba editovat.
Všechny cache jsme před skenováním opakovaně mazali, přesto se kód dokázal udržet poměrně dlouho přímo v obsahu a nebyl vidět na frontendu.
Chci tím ilustrovat, jak zapeklité situace mohou někdy nastat a že se vyplatí postupovat metodicky (otevřít databázi) a nespolehnout se pouze na obecné
- mně to funguje
- já to vidím v pořádku
Tak doufám, že jsem dnes zase trochu pomohl.
BTW jak se vám líbí nová příkazová lišta ve WordPressu? Už ji využíváte?