Všechny softwarové produkty pro ochranu PHP skriptů jsou rozděleny do dvou kategorií: ty, které vyžadují instalaci dalších modulů na server a které pracují s obvyklou konfigurací webových serverů. První jmenované jsou z hlediska bezpečnosti spolehlivější, protože překládají PHP skripty z textové podoby do speciálního binárního kódu, ale vyžadují přístup k serveru s administrátorskými právy. Ty druhé umí fungovat téměř na všech hostingech s podporou PHP, včetně těch zdarma, ale není příliš těžké je hacknout. Zdrojový kód, který nepoužívá šifrování nebo kompresi, lze rozlišit do samostatné podskupiny.
Ochrana na úrovni serveru:
Zend Encoder / Zend SafeGuard Suite je nejoblíbenější komerční ochrana, moduly pro podporu Zend se obvykle instalují na všechny placené hostingy. Zend poskytuje doménové a ip skriptování, načasování zkušebních skriptů a výkonné mlžení. Podporovány jsou všechny operační systémy. Ve veřejné doméně existuje několik možností pro odstranění utilit Zend, všechny jsou upravené PHP verze 4 a 5. Starší verze Zendu jsou odstraněny bez problémů, ve druhé jsou potíže kvůli zatemnění zdrojového kódu.Nová, aktivně se rozvíjející obchodní ochrana. Poskytuje interakci s chráněnými skripty na úrovni vlastních API, podporovány jsou operační systémy Windows a Linux. Vzhledem k nízkému rozšíření se neinstaluje na běžný virtuální hosting, ale uživatelé si jej mohou nainstalovat na dedikované servery. Neexistují žádné veřejné dekodéry.
Komerční ochrana se prakticky nenachází, není nainstalována na virtuální hosting. Umožňuje nastavit zkušební období pro skripty pro kontrolu data na externích časových serverech, navázání chráněných skriptů na servery, IP-adresu, MAC-adresu síťové karty a tato data se použijí k dešifrování. Podporovány jsou všechny operační systémy. Neexistují žádné veřejné dekodéry.
phpSHIELD. SourceGuardian pro prototyp PHP. Po sloučení obou vývojářů se přestal vyvíjet jako samostatný produkt. Hlavní funkcionalita je stejná, nejsou zde žádné veřejné dekodéry.
ionCube PHP Encoder. Druhý nejoblíbenější komerční produkt pro ochranu skriptů. Poté, co se objevily veřejné dekodéry pro Zend, začal se stále více používat a instalovat na sdílený hosting. Umožňuje šifrovat nejen skripty, ale také šablony, xml-dokumenty, obrázky, binární soubory. Váže chráněné soubory na servery, je zde výkonný obfuscátor, jsou podporovány všechny operační systémy. Neexistují žádné veřejné dekodéry, ale v některých případech je může deZender odstranit.
PHTML kodér. Vzácný komerční bezpečnostní systém, který poskytuje běžnou funkčnost pro produkty tohoto typu, funguje pod všemi operačními systémy. Za zvláštní poplatek si můžete zakoupit originální bezpečnostní kódy a upravit je tak, aby vyhovovaly vašim potřebám. Neexistují žádné veřejné dekodéry.
DWebEncoder. Exotická ochrana pro Windows určená k vytváření skriptovaných prezentací a katalogů na CD. V nainstalované podobě je to něco jako nezávislý webový server, na kterém se spouštějí zakódované php skripty. Neexistují žádné veřejné dekodéry.
Kompaktní PHP. Obhajoba je spíše teoretická než praktická. Byl vyvíjen na jednom z tuzemských fór, ale vypadá to, že nepostoupil nad rámec autorských vydání. Neexistují žádné dekodéry, stejně jako chráněné skripty.
Open source doplněk k vintage php akcelerátorům Turck MMCache a eAccelerator. Převádí skripty na bajtkód za účelem zvýšení rychlosti jejich provádění. Existují verze modulů pro Windows a Linux. Veřejné dekodéry neexistují, ale snad otevřený zdrojový kód projektu nějak pomůže při studiu.
Ochrana na úrovni zdroje:
PHP LockIt! ... Populární komerční ochrana, to je velmi běžné, hlavně ve skriptech od zahraničních vývojářů. Umožňuje nastavit zkušební dobu pro provoz skriptů, vázání na domény a ip-adresy, komprimuje skripty pomocí standardních php nástrojů (gzinflate). Jediná záludná část je dobrý obfuskátor. Různé verze ochrany se liší pouze úpravou rozbalovacího modulu. Snadno odnímatelné v manuálním i automatickém režimu. Bez obfuskátoru se odstraňuje přesně do zdrojového kódu, s obfuskačem vyžaduje dodatečné zpracování.CNCrypto. Ve veřejné doméně není ani demoverze, analýza byla provedena pomocí chráněných skriptů. Výklopný modul není náročný na rozbalení, ochrana je založena pouze na dobrém zamlžení zdrojového kódu.
PHPCipher. Ochrana je online služba. Archiv s vašimi skripty je nahrán na web a již chráněný je stažen zpět. Placená licence vám umožňuje podepisovat chráněné skripty vašimi daty a používat je pro komerční účely. Bezplatná licence umožňuje pouze osobní použití. Samotná ochrana je php-modul chráněný Zendem, který se napojuje na chráněné skripty.Po deZendu je ochranný modul a získávání všech potřebných konstant z něj kompletně odstraněn do zdrojového kódu. Neexistuje žádná funkce obfuskátoru.
ByteRun Protector pro PHP. Komerční produkt vám v závislosti na typu licence umožňuje chránit skripty jak na úrovni serveru, tak na úrovni zdrojového kódu. Ochrana serveru se standardními funkcemi, nic zvláštního. Ochranu na úrovni skriptu lze velmi snadno odstranit automaticky i ručně. Pro serverovou verzi neexistuje žádný veřejný dekodér.
Ochrana velmi oblíbená mezi tuzemskými vývojáři. Jedná se o ochranný modul silně posetý prázdným kódem, který je připojen přes include k chráněným skriptům. Algoritmus dekódování je velmi jednoduchý, nezpůsobuje žádné potíže při ručním a automatickém odstraňování. Ve všech případech je zcela odstraněn ze zdrojového kódu, není zde žádná funkce obfuscator. Existují malé funkce pro speciální případy dekódování, ale nebudou zde popisovány.
CodeLock. Další populární obrana, skvělý příklad negramotného programování. Jde o php aplikaci, která umožňuje kódovat jak skripty samotné, tak výsledek jejich práce v prohlížeči pomocí javascriptu. Skripty lze chránit heslem, ale kvůli průměrné implementaci lze heslo snadno zjistit i bez odstranění sklopné ochrany. Ochranný modul je php skript plný prázdného kódu, který se připojuje k chráněným skriptům. Algoritmus ochrany je velmi jednoduchý, je zcela odstraněn do zdrojového kódu. Neexistuje žádná funkce zatemnění.
TrueBug PHP Encoder, nověji TrueBug PHP Obfuscator & Encoder. Velmi zajímavý běhoun k prozkoumání. Před verzí 1.0.2 se používaly standardní php nástroje pro kompresi gzip, od verze 1.0.3 autoři vyvinuli vlastní kompresní algoritmus. Nový produkt TrueBug PHP Obfuscator & Encoder přidává funkci obfuskace a optimalizace zdrojového kódu. Jediným slabým místem ochrany je neměnný algoritmus dekódování skriptu, ale samotný algoritmus se pro každou verzi ochrany mění. Po parsování je ochrana snadno odstraněna přesně na zdrojový kód, samozřejmě za předpokladu, že nebyl použit obfuskátor.
Zorex PHP CryptZ. Protection, stejně jako CodeLock, je php aplikace, ke svému fungování vyžaduje databázi MySQL. Ochranný modul je plug-in php skript zašifrovaný v několika vrstvách. Po analýze je algoritmus velmi snadno odstraněn přesně do zdrojového kódu. Neexistuje žádná funkce obfuskátoru.
Zdarma PHP Encoder. Bezplatná online služba pro kódování php skriptů. Ochranný modul je plug-in php-script krytý Zendem, který je nutné stáhnout ze stránky.Po odstranění Zendu a analýze algoritmu lze ochranu snadno úplně odstranit do zdrojového kódu. Algoritmus ochrany je nezměněn, není zde žádná funkce obfuskátoru.
Skript PHP, primitivní kódování, standardní base64. Nezaslouží si větší pozornost a nemá praktický význam.
Místo standardního wp-signup.php vytváříme vlastní registrační stránku pro multisite.
V typické instalaci WordPressu se na stránce registrace (přihlášení, resetování hesla) zobrazí soubor wp-login.php.
- /wp-login.php - autorizace
- /wp-login.php?action=register - registrace
- /wp-login.php?action=lostpassword - reset hesla
V wp-login.php jsou samostatné podmínky pro multisite. Takže když kliknete na odkaz /wp-login.php?action=register na multisite, WordPress se přesměruje na stránku /wp-signup.php. V mnoha tématech stránka nevypadá moc atraktivně, takže si uděláme vlastní.
Hlavní stránka sítě
Ve výchozím nastavení WordPress otevře registrační stránku (wp-signup.php) na hlavní doméně (stránce) sítě. Můžete však vytvořit samostatnou registrační stránku pro každý web v síti, i když mají různá témata. Budeme uvažovat případ, kdy všechny stránky v síti mají svou vlastní registrační stránku, ale používá se stejné téma a stránky se liší pouze jazykem. Pokud používáte různá témata, budete muset napsat více kódu.
funkce.php?
Ne. Zdá se, že název tohoto souboru je uveden v každém článku WordPress. V našem případě, vzhledem k tomu, že funkce registrace je navržena pro několik stránek, má smysl ji přesunout do zásuvných modulů MU, které se načítají při otevření libovolné stránky.
Lyrická odbočka
Stojí za zmínku, že pluginy MU se načítají dříve než běžné pluginy a dříve, než se plně načte jádro WordPressu, takže volání některých funkcí může vést k fatálním chybám v PHP. Toto "brzké" načítání má také své výhody. Například uvnitř žádného motivu nemůžete lpět na některých akcích, které jsou spuštěny ještě před načtením souboru functions.php z motivu. Příkladem toho jsou akce z pluginu Jetpack ve tvaru jetpack_module_loaded_related-posts (related-posts - název modulu), pomocí kterých je možné sledovat aktivitu modulů v Jetpacku. Na tuto akci ze souboru motivu nelze „ulpět“, protože akce již byla spuštěna před načtením motivu – pluginy se načítají před motivy. Na obecný obrázek pořadí načítání WordPressu se můžete podívat na stránce Action Reference v kodexu.
Pořadí souborů
Pluginy MU mohou obsahovat libovolný počet souborů a libovolnou strukturu, která vám připadá logická. Držím se něčeho jako je tato hierarchie:
| -mu-plugins | - | -load.php | - | - | -selena-network | - | - | - | -registrace | - | - | - | - | -plugin.php | - | - | - | - | -... | - | - | - | -jetpack | - | - | - | - | -plugin.php
Všechny potřebné "pluginy" pro naši síť jsou připojeny v souboru load.php:
// Načtení Traslates pro všechny doplňky load_muplugin_textdomain ("selena_network", "/ selena-network / languages /"); // Registrace sítě vyžaduje WPMU_PLUGIN_DIR. "/selena-network/signup/plugin.php"; // Jiné pluginy // vyžadují WPMU_PLUGIN_DIR ...
Složky pluginů jsou uloženy ve složce selena-network, každá má svůj plugin.php, který zahrneme do load.php. To vám dává flexibilitu a možnost rychle věci vypnout a zapnout.
Adresa registrační stránky
K zadání adresy registrační stránky se používá filtr wp_signup_location. Lze jej nalézt v souboru wp-login.php a je zodpovědný za přesměrování na wp-signup.php.
Případ "register": if (is_multisite ()) (wp_redirect (apply_filters ("wp_signup_location", network_site_url ("wp-signup.php"))); exit;
Přidejme naši funkci do mu-plugins / selena-network / signup / plugin.php, která vrátí adresu registrační stránky na aktuálním webu:
Funkce selena_network_signup_page ($ url) (return home_url (). "/ Signup /";) add_filter ("wp_signup_location", "selena_network_signup_page", 99);
selena_network je předpona, kterou používám v názvech všech funkcí v zásuvných modulech MU na mém webu, abych se vyhnula kolizím, měla by být nahrazena mým vlastním jedinečným předponou. Filtr má prioritu 99, protože některé pluginy jako bbPress a BuddyPress mohou tuto URL přepsat vlastní (MU pluginy se načítají dříve než běžné pluginy, viz výše). Všimněte si, že home_url () se používá místo network_site_url () k udržení návštěvníka ve stejné doméně. Jako adresu lze použít jakoukoli adresu URL.
Vytvořit stránku
Nyní vytvoříme stránku s adresou site.com/signup/ prostřednictvím běžného rozhraní a ve složce podřízeného motivu je šablona pro naši novou stránku page-signup.php. Místo slova „registrace“ lze použít jedinečné ID.
Uvnitř nové šablony je potřeba zavolat funkci selena_network_signup_main (), která zobrazí registrační formulář.
Je třeba poznamenat, že celý proces se šablonami není vyžadován a místo toho si můžete vytvořit svůj vlastní krátký kód, který bude také volat funkci selena_network_signup_main ().
wp-signup.php a wp-activate.php
Nyní začněme vytvářet funkci, která zobrazí registrační formulář. Chcete-li to provést, zkopírujte soubory wp-signup.php a wp-activate.php z kořenového adresáře WordPress do mu-plugings / selena-network / signup / (a nezapomeňte je připojit uvnitř mu-plugins / selena-network / registrace / plugin.php) ... Další manipulace se soubory jsou extrémně obtížné a časově náročné na popis, takže je budete muset udělat sami. Jen popíšu, co přesně je potřeba udělat, a zveřejním zdrojové soubory mého projektu:
- Na začátku souboru odstraňte všechny požadované funkce, volání funkcí a další kód mimo funkce.
- Přejmenujte všechny funkce přidáním jedinečných předpon k názvům.
- Zabalte spodní část kódu wp-signup.php do funkce selena_network_signup_main a hned na začátek napište globální $ active_signup; ...
- Vyměňte rozvržení za vlastní na správných místech.
Uvnitř wp-activate.php musíte udělat přibližně totéž:
- Odstraňte veškerý kód mimo funkce, zabalte rozložení do samostatné funkce.
- V případě potřeby změňte rozvržení.
Soubor wp-activate.php je zodpovědný za stránku aktivace účtu. Stejně jako u registrační stránky je pro ni potřeba vytvořit samostatnou šablonu, uvnitř které zavoláte funkci ze souboru wp-activate.php.
Zasíláme aktivační dopisy
Registrační stránka zašle návštěvníkovi e-mail s odkazem na aktivaci účtu. Standardně to dělá funkce wpmu_signup_user_notification () ze souboru ms-functions.php. Jeho funkčnost si můžete zapůjčit pro svou funkci. Důvodem, proč přestat používat tuto funkci, je to, že odesílá odkaz na aktivaci účtu z wp-activate.php. Tuto funkci můžete „zakázat“ pomocí filtru wpmu_signup_user_notification a uvést na ni false (pokud to neuděláte, aktivační dopis bude zaslán dvakrát, dobře, ve skutečnosti dvě různá písmena).
Funkce armyofselenagomez_wpmu_signup_user_notification ($ user, $ user_email, $ key, $ meta = array ()) (// ... // Kód z funkce wpmu_signup_user_notification () wp_mail ($ user_email, wp_specialchars_decode ($ message_headers), $ message), $ ; return false;) add_filter ("wpmu_signup_user_notification", "armyofselenagomez_wpmu_signup_user_notification", 10, 4);
Výsledkem je, že registrační stránka v tématu Selena vypadá mnohem čistěji a přesněji.
Závěr
Existuje mnoho dalších nepříliš správných způsobů, jak totéž udělat na internetu - přesměrování Apache, formuláře AJAX, které nebudou fungovat bez Java Scriptu atd. vlastní web.
Všimněte si, že byste měli soubory upravovat opatrně a snažit se příliš neodchýlit od originálu, takže v budoucnu, pokud WordPress změní soubory wp-signup.php a wp-activate.php, bude snazší je porovnat a najít Změny.
Nezapomeňte se podívat do zdrojového kódu všech výše popsaných funkcí, abyste plně pochopili, co a jak se uvnitř kódu děje.
bonus. Ochrana proti spammerům
Dokonce i ty nejmenší weby WordPress podléhají častým registracím spamu. Pro filtrování botů se dají psát nekonečné podmínky, často spíš pokusy o vytvoření umělé inteligence 🙂 V případě multisite mi hodně pomohlo obvyklé přesměrování v Apache, se kterým při otevření /wp-signup.php a /wp- acitvate.php, požádal jsem o 404 (nejsem odborník na konfiguraci Apache, takže moje pravidla nemusí být příliš správná).
RewriteEngine On RewriteBase / RewriteRule ^ wp-signup \ .php - RewriteRule ^ wp-activate \ .php - # ZAČÁTEK WordPress # Ve výchozím nastavení se nedotýkejte pravidel WordPressu :) # ... # KONEC WordPress
P. S. Některé věci třetích stran se snažím popsat co nejpodrobněji, protože když jsem začínal, občas nebyl nikdo, kdo by spoustu věcí popohnal a vysvětlil. Věřím také, že takové drobné tipy na další materiály někoho popostrčí k tomu, aby se naučil něco nového a rozšíří si pole znalostí. Regulární výrazy se používají v položkách RewriteRule, nejsou nijak složité, například znak ^ znamená začátek řádku.
„Rozbíjejí stránky bank pro peníze, Pentagon kvůli špionáži a můj projekt nikdo nepotřebuje,“ bohužel si to myslí většina majitelů osobních blogů, internetových vizitek, virtuálních kanceláří malých firem. Jen málokdo přemýšlí, jak lokalitu ochránit, ale marně. V moderní realitě je v očích hackerů zajímavá absolutně jakákoli platforma, bez ohledu na typ nebo popularitu. Kdo může potřebovat váš zdroj a proč? Pojďme na to přijít:
1. Žerty scriptkiddis. Žargon odkazuje na začínající hackery, kteří dělají své první kroky na „temné straně“. Poté, co získali několik nástrojů nebo napsali několik vlastních programů, chtějí testovat svůj výkon na první oběti, na kterou narazí, a zpravidla si vybírají nejjednodušší (slabě chráněné a neaktualizované CMS) cíle.
2. Černá SEO. Stále se využívají služby nepoctivých optimalizátorů – stále se praktikuje umisťování skrytých odkazů do kódu projektů s více než 10 TCI. A za prvé, zdroje na open source engine (Joomla, Drupal, OpenCart a tak dále) jsou napadeny.
3. Budování botnetu. Ochrana WordPress pomocí htaccess a pluginů je také relevantní, protože k vytvoření zombie sítě používané při DDoS útocích, spamování atd. lze použít naprosto jakýkoli zdroj.
4. Vedlejší škody. Konečně možná nebudete napadeni – hlavním cílem bude hosting a stránka bude sloužit pouze jako jedna velká zranitelnost IT infrastruktury poskytovatele. Hackery jeho osud samozřejmě nezajímá.
Důsledky hackování mohou být nejnepříjemnější: ztráta obsahu nebo zdroje jako celku, pesimizace ve výsledcích vyhledávače, ztráta publika kvůli nápisu „Stránka může ohrozit bezpečnost počítače nebo mobilního zařízení“ a dokonce i riziko zapletení se do trestního případu, pokud byly na základě vašeho webového zdroje spáchány nezákonné činy.
Můžeme tedy s jistotou říci, že bezpečnostní problémy se týkají naprosto každého webmastera. A pokud je zanedbáte, veškeré snahy o propagaci vyhledávače (a to jsou peníze a drahocenný čas) mohou přijít přes noc vniveč. Problém je velmi naléhavý, a tak jsem se rozhodl zahájit sérii článků věnovaných síťovým hrozbám a způsobům jejich řešení. Populárnímu CMS systému - Wordpressu se budeme věnovat ve třech číslech.
Metody pro zabezpečení webu WordPress
Jednou z nejprimitivnějších metod hackování je hrubá síla. Doslova je tento výraz přeložen jako „hrubá síla“ a znamená získání dvojice login / heslo hrubým výčtem možných možností. Brute-forcers se jim často snaží usnadnit život tím, že využívají chyb v nastavení enginu a serveru – pomáhá jim to například zjistit název účtu, což výrazně snižuje počet kombinací. Řeč bude o odstranění těchto zranitelností a také o metodách boje proti pokusům o neoprávněný přístup.
1. Použijte jedinečné přihlašovací jméno správce
Ve výchozím nastavení systém nabízí vytvoření uživatele s názvem admin. Chcete-li však chránit svůj web WordPress, je nejlepší použít přihlašovací jméno sestávající ze sady náhodných písmen a čísel. Na živém zdroji lze jméno administrátora bez problémů změnit jedním ze dvou způsobů:
Prostřednictvím administračního panelu. Přejděte do sekce „Uživatelé“, klikněte na tlačítko „Přidat nového“ a vytvořte si účet. V poli „Role“ vyberte „Správce“ a potvrďte operaci. Poté se znovu přihlaste jménem nově vytvořeného účtu, vraťte se do sekce „Uživatelé“, vyberte „admin“ a klikněte na „Odstranit“. V okně, které se otevře, umístěte přepínač do pozice „Propojit veškerý obsah“ a z rozevíracího seznamu vyberte nového správce a poté klikněte na „Potvrdit odstranění“.
... Pomocí phpMyAdmin. Je mnohem jednodušší provést stejný postup prostřednictvím ovládacího panelu databáze. Vyberte požadovanou databázi, najděte tabulku wp_users, najděte řádek „admin“ (ID = 1), klikněte na „Změnit“ a zadejte požadovaný název.
2. Vytvořte vyhrazený publikační účet
Pokud je správce „vynechán“, poskytne to dodatečnou ochranu. Vytvořte si samostatný účet pro zveřejňování článků a propojte s ním všechny dříve publikované materiály způsobem popsaným v odstavci 1. Dále přidávejte informace a komunikujte se čtenáři pouze z nového účtu.
3. Zadejte silné heslo
Dodržujte obecně uznávaná doporučení: heslo musí mít alespoň 10 znaků, musí být jedinečné a sestávat z náhodné sekvence velkých a malých písmen, číslic a speciálních znaků.
V žádném případě byste neměli:
... sestavit heslo ze smysluplných frází
... použít jakékoli faktické údaje (datum narození, rodné příjmení, číslo bankovního účtu, aktuální rok...)
Odpadne tak riziko hledání přístupové fráze pomocí slovníku a také se výrazně prodlouží čas nutný pro hrubou sílu. Rozluštění sekvence 10 znaků, skládající se pouze z malých písmen a číslic (hki458p1fa), tedy zabere 10 dní počítačového času na jednom počítači, ale pokud přidáte velká písmena a další znaky (Nv6 $ 3PZ ~ w1), toto období se prodlouží až na 526 let, což zaručuje téměř absolutní ochranu WordPress. Vymyslet a zapamatovat si tato hesla je poměrně obtížné, zvláště pokud máte na starosti více projektů. Pro jejich generování a ukládání je proto lepší použít speciální správce, například KeePassX, distribuovaný zdarma, nebo běžný testovací dokument (je lepší, když je zabalen do archivu s heslem).
4. Změňte heslo pro databázi
Výše uvedená pravidla platí také pro zabezpečení přístupového kódu MySQL. Koneckonců, je to tam, kde je veškerý obsah, stejně jako hash administrátorské tajné fráze. Pokud již používáte slabé heslo, vyplatí se dát si tu práci a změnit ho. To se provádí následovně:
1. Přejděte do ovládacího panelu phpMyAdmin
2. Otevřete záložku "Uživatelé" a vyberte vlastníka databáze
3. Klikněte na „Upravit oprávnění“
4. Najděte sloupec „Změnit heslo“ a do příslušných polí zadejte novou tajnou sekvenci
5. Uložte změny kliknutím na "OK"
Nyní zbývá pouze upravit wp-config.php, jinak se WordPress nebude moci připojit k databázi. Najděte definovaný řádek („DB_PASSWORD“, „heslo“); a místo slova heslo zadejte nové heslo. Všimněte si, že znak (‘) se používá k oddělování příkazů SQL, neměl by se používat jako součást přístupové fráze.
5. Pravidelně aktualizujte hesla
Měly by se měnit alespoň každých šest měsíců. Mimořádná změna kódových frází by měla být VŽDY provedena po:
Předávání dat pro autentizaci třetím stranám (programátorům, systémovým administrátorům, optimalizátorům a dalším specialistům, i když pracují na zaměstnancích hostitelské společnosti)
... přihlášení k webovému zdroji z počítače někoho jiného (na večírku, v internetové kavárně)
... autorizace od zařízení, které mohlo být kompromitováno (stroj infikovaný virem)
6. Nezapomeňte změnit tajné klíče pro soubory cookie
Jsou umístěny v souboru wp-config.php. Je jich 8:
| definovat ("AUTH_KEY", "jedinečný klíč"); definovat ("SECURE_AUTH_KEY", "jedinečný klíč"); definovat ("LOGGED_IN_KEY", "jedinečný klíč"); definovat ("NONCE_KEY", "jedinečný klíč"); definovat ("AUTH_SALT", "jedinečný klíč"); definovat ("SECURE_AUTH_SALT", "jedinečný klíč"); definovat ("LOGGED_IN_SALT", "jedinečný klíč"); definovat ("NONCE_SALT", "jedinečný klíč"); |
definovat ("AUTH_KEY", "jedinečný klíč"); definovat ("SECURE_AUTH_KEY", "jedinečný klíč"); definovat ("LOGGED_IN_KEY", "jedinečný klíč"); definovat ("NONCE_KEY", "jedinečný klíč"); definovat ("AUTH_SALT", "jedinečný klíč"); definovat ("SECURE_AUTH_SALT", "jedinečný klíč"); definovat ("LOGGED_IN_SALT", "jedinečný klíč"); definovat ("NONCE_SALT", "jedinečný klíč");
Jak asi tušíte z názvů proměnných, klíče jsou zodpovědné za šifrování cookies (známý slang: cookie - cookies, salt - salt, krmíme hackery slanými cookies), které se používají k vytvoření "zapamatovat" váš počítač po autorizaci. Pointa je, že i když útočník dostane k dispozici hash hesla správce, nebude schopen generovat soubory cookie nezbytné pro přístup na stránku bez uvedených tajných frází.
Pro zlepšení zabezpečení by měly být výchozí sekvence znaků nahrazeny jedinečnými ihned po nasazení CMS. Pro pohodlí vývojáři vytvořili webový generátor umístěný na adrese www.api.wordpress.org/secret-key/1.1/salt/ - když vstoupíte, uvidíte klíče, a pokud stránku obnovíte, kombinace se aktualizují .
7. Dvojité oprávnění pro oblast administrátora
Htaccess vám umožňuje dále zabezpečit váš web WordPress přidáním ověřování na úrovni serveru. Kód bude vypadat takto:
| < Files wp- login. php> # Nastavili jsme základní typ autentizace - to znamená, že když se pokusíte# při přístupu k zadanému adresáři nebo souboru budete vyzváni k zadání hesla: AuthType základní # Zadejte text, který se zobrazí v záhlaví formuláře: AuthName "Identifikujte se" # Zadejte cestu k souboru obsahujícímu přístupovou frázi: AuthUserFile "/home/site/.htpasswd" # Upozorňujeme, že při přístupu k souboru wp-login.php musíte zadat heslo: Vyžadovat platný uživatel # Odepřít přístup k souboru .htpasswd třetím stranám:< Files . htpasswd>rozkaz povolit, odepřít ode všech odepřít |
# Vyberte soubor autorizačního skriptu:
Zároveň by bylo fajn postarat se o zabezpečení samotného htaccess. Přesně řečeno, taková směrnice by měla být uvedena v hlavním nastavení hostingu, ale vzhledem k nedbalosti některých poskytovatelů byste měli hrát na jistotu:
Místo „login“ nahraďte požadované jméno. Zbývá vygenerovat heslo samotné a také jej zašifrovat, protože ukládat taková data v čistém textu je nepřípustný luxus. Na to existuje mnoho služeb, ale je lepší napsat potřebný skript sami. To se provádí následovně:
1) Vytvořte soubor .php v poznámkovém bloku, například crypt.php
2) Zadejte kód a místo slova „Heslo“ nahraďte své heslo:
3) Uložte soubor a nahrajte do kořenového adresáře
4) Klikněte na odkaz site_name.ru / crypt.php - na obrazovce se objeví hash hesla
5) Uložte tuto hodnotu do souboru .htpasswd a nahrajte ji do kořenového adresáře a smažte crypt.php
Posledním krokem je zákaz prohlížení obsahu adresáře webových zdrojů. Do htaccess stačí přidat jeden řádek:
| Možnosti Vše - Indexy |
Možnosti Všechny - Indexy
To se děje proto, aby hackeři nemohli zjistit, které soubory jsou v adresářích projektu. Na mnoha hostitelských webech je tato směrnice již zahrnuta v nastavení serveru, ale pokud tento bod přehlédnete, měli byste si ji zaregistrovat sami.
8. Nainstalujte captcha
Použití captcha vám umožní odříznout, když ne všechny, tak alespoň většinu robotů hrubou silou a zároveň. Adresář pluginů pro ochranu webu WordPress nabízí mnoho možností. Kromě připojení proprietárního řešení od Google je velkým zájmem Captcha od BestWebSoft smíšeného (grafického a textového) typu, který je založen na matematických operacích. Nezávislost na službách, přehlednost a přijatelná úroveň složitosti dělají z modulu jeden z nejlepších.
Přizpůsobení není velký problém. Karta „Základní“ vám umožňuje vybrat, kde se má captcha zobrazit, a také zadat název a symbol pro označení požadovaných polí.
Sekce "Pokročilé" poskytuje možnost vytvářet vlastní chybové zprávy a také aktivovat další balíčky obrázků, aby byl život pro roboty ještě obtížnější.
Další užitečnou funkcí je vestavěný whitelist IP adres, u kterých se captcha nezobrazí.
Výsledkem instalace a aktivace pluginu bude zobrazení formuláře na autorizační stránce:
9. Změňte adresu správce
Když už mluvíme o tom, jak chránit web WordPress, stojí za zmínku radikálnější, ale také složitější způsob - změna adresy URL přihlašovací stránky na úrovni skriptu. Postup se provádí v několika fázích:
1. Přejmenujte soubor wp-login.php. Použijte náhodnou sekvenci malých latinských písmen, číslic a pomlček. Například: abc-123.php
2. Najděte ve výsledném souboru všechny odkazy na wp-login.php a nahraďte je novým názvem.
3. Aby web fungoval správně, musí být nahrazení také provedeno v: wp-activate.php, general-template.php, post-template.php, functions.php, class-wp-customize-manager.php, general -template.php, link-template.php, admin-bar.php, post.php, pluggable.php, ms-functions.php, canonical.php, functions.wp-scripts.php, wp-signup.php, my -sites.php, schema.php, ru_RU.po
Po těchto manipulacích bude panel správce umístěn na webu / abc-123.php. Přístup k novému souboru by měl být omezen a chráněn heslem, jak je popsáno výše. Potenciální hackery je také možné uvést v omyl vytvořením falešného souboru wp-login.php a nastavením hesla i pro něj.
Ještě jednodušší možností je použití doplňku „Přejmenovat wp-login.php“. Po instalaci pluginu pro ochranu webu se v nabídce „Nastavení“ -> „Trvalé odkazy“ objeví nové pole:
10. Zadejte IP adresu správce
Další zabezpečení lze poskytnout, pokud máte statickou IP adresu. Odmítnutí přístupu k wp-login.php z jakéhokoli jiného počítače než vašeho vlastního hackerům značně ztíží život:
| < Files wp- login. php>objednávka odepřít, povolit odmítnout od všech povolit od 127.0.0.1, 127.0.02 # Své IP adresy oddělte čárkami |
11. Zakažte chyby autorizace
Při hrubém vynucení hesel bude útočníkovi velmi užitečné vědět, že zadaná data byla nesprávná. Takové zprávy se zobrazují při každém neúspěšném pokusu o přihlášení a WordPress hlásí i to, co bylo zadáno špatně, uživatelské jméno nebo heslo. Chcete-li se jich zbavit, stačí přidat pouze jeden řádek do functions.php:
| add_filter ("login_errors", create_function ("$ a", "return null;")); |
add_filter ("login_errors", create_function ("$ a", "return null;"));
Chcete-li to provést, vyberte v panelu správce "Vzhled" -> "Editor" -> "Funkce motivu". Za úvodní značku je nutné napsat kód
12. Použijte zabezpečené připojení.
Pro šifrování provozu mezi počítačem uživatele a webovým serverem existuje protokol https, jehož použití vylučuje možnost zachycení důležitých údajů, v našem případě identifikačních údajů. Chcete-li jej aktivovat, musíte si nejprve zakoupit certifikát SSL, který plní dvě funkce najednou: ověřování webového zdroje a šifrování přenášených informací. Seženete ho ve specializovaných centrech nebo u řady registrátorů doménových jmen. Pro nekomerční účely zcela postačí získat bezplatný vstupní certifikát (ten nabízí společnost www.startssl.com). Pokud jde o proces instalace, je zpravidla podrobně popsán v nápovědě hostitele.
Po obdržení certifikátu SSL je třeba nakonfigurovat přesměrování administrativní části webového zdroje na zabezpečené připojení. V případě WordPressu se to děje pomocí následující konstrukce:
| < IfModule mod_rewrite. c>Options + FollowSymlinks RewriteEngine On RewriteCond% (HTTPS) = off RewriteCond% (REQUEST_URI) = / wp- přihlášení. php RewriteRule (. *) https: |
Můžete také vynutit použití certifikátů SSL na úrovni enginu. Chcete-li to provést, otevřete soubor wp-config.php a přidejte jej
| definovat ("FORCE_SSL_ADMIN", true); |
definovat ("FORCE_SSL_ADMIN", true);
Navíc si můžete nastavit globální přesměrování z http na https. Pro nové weby je tento přístup optimální, protože Google podporuje bezpečné projekty a dává jim určitou prioritu ve výsledcích vyhledávání:
| < IfModule mod_rewrite. c>Options + FollowSymlinks RewriteEngine on RewriteCond% (HTTPS) = off RewriteRule ^ (. *) $ Https: //% (HTTP_HOST)% (REQUEST_URI) |
13. Blokujte vetřelce
Pokud je zjištěna podezřelá aktivita z určitých IP adres, vyplatí se zablokovat jejich přístup na stránku. To se provádí analogicky s předchozí metodou. Rozdíl je v tom, že směrnice jsou psány pro projekt jako celek a my uvádíme adresy těch, které chceme zakázat:
Objednat Povolit, Odmítnout Povolit ze všech Odmítnout od 127.0.0.1, 127.0.02 # Zadejte nechtěnou IP
Metoda je spolehlivá, ale neúčinná. Jednak je potřeba nějak zaznamenat požadavky násilných služeb a oddělit je od slušných návštěvníků. Za druhé, s masivním útokem jednoduše nebudete moci ručně sledovat a vjíždět IP hackerů a botů. Tato metoda je dobrá pouze v případě, že má správce spolehlivý blacklist adres.
Jinak můžete použít plugin pro zabezpečení webu WordPress s názvem WP Cerber. Toto řešení je zcela zdarma a zároveň nabízí velmi působivou sadu nástrojů navržených tak, aby zabránily hackování CMS. Můžete jej nainstalovat přímo z administračního panelu.
Standardně jsou nabízeny poměrně rozumné parametry. Počet pokusů by se však měl zvýšit na 5, aby se předešlo nedorozuměním.
Zaškrtávací políčko vedle „Blokovat IP pro jakýkoli požadavek wp-login.php“ by mělo být zaškrtnuté, pokud změníte adresu správce výše popsaným způsobem.
Pro tyto účely můžete také použít vlastní nástroj WP Cerber:
Režim zásuvného modulu pro ochranu webu Citadel také nevyžaduje další konfiguraci. Je navržen tak, aby „zamlžil“ projekt během masivního útoku hrubou silou. Je lepší zrušit zaškrtnutí políčka vedle „Zaznamenat pokusy o přihlášení do souboru“ - pomůže to odstranit další zatížení serveru.
Záložka „Přístupové seznamy“ se používá k vytvoření „černého“ a „bílého“ seznamu IP (pokud máte statickou adresu, nezapomeňte ji přidat do seznamu důvěryhodných) a sekce „Nástroje“ vám umožňuje importovat a exportovat dříve provedená nastavení. Tyto možnosti však nevyžadují samostatnou úvahu.
14. Přesuňte konfigurační soubor
Jak jsme zjistili výše, wp-config.php ukládá taková důležitá data, jako je přihlašovací jméno a heslo pro přístup k MySQL, stejně jako klíče API. Další krok se zdá být zřejmý – ochrana WordPressu prostřednictvím htaccess omezením přístupu k souboru:
| < Files wp- config. php>Objednávka povolit, odepřít Odepřít všem |
Existuje však i spolehlivější metoda. WordPress má velmi zajímavou funkci, o které málokdo ví. Engine umožňuje umístit konfigurační soubor o jednu úroveň nad kořenový adresář. php lze přesunout do adresáře webu. V takovém případě se soubor stane přes internet zcela nepřístupným, přičemž informace v něm obsažené bude CMS stále číst.
15. Přidejte kontrolu REFERER
Při konfrontaci s brute-force útoky pomůže i osvědčená metoda ochrany WordPressu před spamem. Hrubé vynucení hesel není v žádném případě manuální práce: k těmto účelům se používají specializované programy. To znamená, že povolením kontroly hlaviček v příchozích požadavcích můžete odříznout roboty, kteří přišli odnikud s prázdným HTTP REFERER:
| < IfModule mod_rewrite. c>RewriteEngine On RewriteCond% (REQUEST_METHOD) POST RewriteCond% (REQUEST_URI). (wp- komentáře- příspěvek | wp- přihlášení) \. php * RewriteCond% (HTTP_REFERER)!. * tekseo. su. * [NEBO] RewriteCond% (HTTP_USER_AGENT) ^ $ RewriteRule (. *) http: //% (REMOTE_ADDR) / $ 1 |
16. Chraňte XML-RPC
Od verze 3.5 zmizela z WordPressu možnost deaktivovat protokol vzdáleného volání procedur XML-RPC. V podstatě je potřeba interakce s mobilními aplikacemi, ale ne každý takovou funkcionalitu potřebuje. Zároveň je xmlrpc.php aktivně využíván k provádění DDoS útoků, což je Achillova pata celého projektu.
Navíc hackery napadlo použít XML-RPC pro hrubou sílu. Použití metody wp.getUsersBlogs vám umožňuje procházet přihlašovacími údaji mnohem rychleji než pomocí formuláře pro správce. Protože mnoho volání XML-RPC vyžaduje autorizaci, požadavek jako je tento:
| < methodCall> < methodName>wp. getUsersBlogs < params>< param>< value>< string>admin < param>< value>< string> 12345 |
způsobí, že vám motor sdělí, zda je předaná kombinace správná. Chcete-li se této pohromy zbavit, musíte protokol zcela zakázat. To lze provést několika způsoby:
1) Zablokováním přístupu k souboru xmlrpc.php přes htaccess
require_once (ABSPATH. "wp-settings.php");
potřeba se zaregistrovat
funkce remove_x_pingback ($ headers) (nenastaveno ($ headers ["X-Pingback"]); return $ headers;) add_filter ("wp_headers", "remove_x_pingback");
4) Pomocí pluginu Control XML-RPC publishing s vrácením příslušné možnosti v Nastavení -> Zápis:
Upozornění: doplněk deaktivuje protokol ihned po aktivaci a v nastavení jej můžete povolit zaškrtnutím příslušného políčka.
17. Monitorujte útoky hrubou silou
Na závěr stojí za zmínku zajímavý plugin pro logování pokusů o hackování – Authentication and xmlrpc log Writer. Ačkoli stejný WP Cerber má vestavěné monitorovací nástroje, tento modul bude stále užitečný, zejména pro ty, kteří potřebují možnosti protokolu popsaného výše. AX LogWriter je schopen sledovat hrubou sílu prostřednictvím xmlrpc.php, takže můžete posoudit míru ohrožení a vhodnost úplného odmítnutí použití jeho schopností. A konečně těm, kteří se zabezpečením svého projektu vůbec nepodíleli, plugin pro ochranu stránek otevře oči, jak důležité jsou vyjmenované aktivity.
Použití AX LogWriter je přímočaré. Po instalaci se v nabídce administrátora objeví odpovídající sekce, kde můžete provést všechny potřebné změny:
V poli „Typ chyby“ vyberte způsob uložení. Podporuje zápis do systémového protokolu, protokolu serveru Apache a také možnost vytvořit vlastní soubor. V druhém případě může být také konfigurován s vlastním názvem protokolu chyb a vlastní cestou protokolu chyb. To otevírá široké možnosti pro správce systému – řešení lze například použít společně s fail2ban. Nezapomeňte také ve sloupci Časové pásmo vybrat příslušné časové pásmo.
Vlastní protokol lze zobrazit přímo z panelu správce na stránce Prohlížeč vlastních protokolů:
Pojďme si to shrnout:
Uvedené metody pomohou výrazně zvýšit zabezpečení vašeho zdroje a ochránit jej před roboty-brute-forced, síťovými chuligány a praktikujícími scriptkiddis. Vše výše popsané je však jen špičkou ledovce. Útočníci mají ve svém arzenálu mnohem sofistikovanější metody. A v příštím článku budeme hovořit o tom, jak se chránit před skutečnými hackery pomocí různých zranitelností enginu a serverového softwaru. Stejně jako v tomto materiálu budou kromě obecných „hygienických pravidel“ považována za klíčová nastavení CMS, způsoby úpravy kódu a také nejdůležitější pluginy.
Pokud jde o zabezpečení aplikací, je důležité se starat nejen o hardware a operační systém, ale také o psaní bezpečných skriptů. V tomto článku se dozvíte, jak udržet vaši aplikaci zabezpečenou a méně zranitelnou. Níže je uveden seznam opatření, která vám pomohou chránit vaši aplikaci před všemi druhy útoků:
- Ověření příchozích dat
- Ochrana proti XSS útokům
- Ochrana proti CSRF útokům
- Prevence SQL Injection
- Ochrana souborového systému
- Ochrana dat relace
- Chyba při zpracování
- Ochrana zahrnutých souborů
Ověření příchozích dat
Při navrhování aplikace se musíte snažit chránit ji před „špatnými“ příchozími daty. Pravidlo, které je třeba dodržovat, je něco jako: "Nikdy nevěř tomu, co uživatel zadal." Ačkoli většina uživatelů nepředstavuje hrozbu, vždy existuje možnost, že někdo chce hacknout váš web pomocí „špatných“ dat zadaných prostřednictvím formulářů nebo adresního řádku. Pokud vždy ověřujete a filtrujete příchozí data, pak máte velkou šanci napsat zabezpečenou aplikaci.
Vždy kontrolujte svá data v PHP skriptech. Pokud k ověření dat používáte JavaScript, útočník jej může ve svém prohlížeči kdykoli zakázat. V tomto případě je vaše aplikace ohrožena. Nikdo není proti validaci JavaScriptu, ale pro dobrou ochranu je potřeba dvakrát zkontrolovat data v PHP skriptech.
Ochrana proti XSS útokům
Cross-site scripting neboli XSS útok je útok založený na vkládání kódu do potenciálně zranitelných stránek. Nebezpečí spočívá v tom, že prostřednictvím formulářů lze zadat škodlivý kód a následně jej zobrazit v prohlížeči.
Předpokládejme, že váš web má formulář pro zadávání komentářů, které se po přidání ihned zobrazí. Útočník by mohl zadat komentář obsahující kód JavaScript. Po odeslání formuláře jsou data odeslána na server a vložena do databáze. Poté se data načtou z databáze a nový komentář se zobrazí na stránce HTML, včetně vloženého kódu JavaScript. Může uživatele přesměrovat na nějakou škodlivou stránku nebo phishingový web.
Chcete-li chránit své aplikace, spusťte příchozí data pomocí funkce strip_tags (), která odstraní všechny přítomné značky. Při zobrazování dat v prohlížeči použijte funkci htmlentities ().
Ochrana proti CSRF útokům
Dalším typem útoku, na který se podíváme, je útok CSRF nebo podvržení požadavku mezi stránkami. Útočník používá různé triky, jak získat důvěrné informace nebo uzavřít obchod bez vědomí oběti. To se děje hlavně na špatně chráněných webech, kde je obchodní logika založena na práci požadavků GET.
Obecně řečeno, požadavky GET jsou idempotentní. Idempotence v tomto kontextu znamená, že na jednu a tutéž stránku lze přistupovat mnohokrát bez jakéhokoli vnějšího zásahu. Proto by požadavky GET měly být používány pouze k získání přístupu k informacím, ale v žádném případě k provádění různých druhů transakcí.
Následující jednoduchý příklad ukazuje, jak může být nezabezpečený web vystaven útoku CSRF:
Předpokládejme, že Bob chce provést CSRF útok na Alici. Vytvořil speciální url adresu a poslal ji Alici e-mailem:
Navštivte můj web!
Pokud je Alice autorizována na webu example.com a následuje tento odkaz, bude z jejího účtu převedeno 1 000 $ na Bobův účet. Případně může Bob také poslat obrázek a vyplnit „špatnou“ adresu URL v atributu src.
Prohlížeč nebude moci zobrazit tento obrázek, protože neexistuje, ale požadavek bude podán bez vědomí a účasti Alice.
Chcete-li tomuto druhu útoků zabránit, používejte pouze požadavky POST na procesy určené ke změně informací v databázi. Nepoužívejte $ _REQUEST. Použijte $ _GET ke zpracování parametrů GET a $ _POST k načtení parametrů POST.
Jako další opatření můžete vygenerovat jedinečný token a připojit jej ke každému požadavku POST. Když se uživatel přihlásí do systému, můžete vygenerovat náhodný token a zapsat ho do relace. Protože se uživateli zobrazují všechny formuláře, musí být tento token zapsán do skrytého pole. Obchodní logika aplikace musí poskytovat funkce, které zkontrolují token z formulářů a token uložený v relaci.
Prevence SQL Injection
Ke spouštění dotazů na databázi byste měli používat PDO. Pomocí parametrizovaných dotazů a připravených příkazů můžete zmírnit hrozbu injekce SQL.
Podívejme se na následující příklad:
Ve výše uvedeném kódu posíláme požadavek na metodu připravit () včetně jmenovaných parametrů:: jméno a: věk. Dotaz je tedy předkompilován pro další substituci dat. Když je zavolána metoda execute (), je požadavek plně vytvořen a vykonán. Pokud použijete tuto techniku, všechny pokusy útočníka o provedení SQL injection budou zrušeny.
Ochrana souborového systému
Jako odpovědný vývojář byste měli vždy psát kód, který neohrozí váš souborový systém. Podívejme se na kód, který odesílá soubor ke stažení v závislosti na datech zadaných uživatelem.
Tento skript je velmi nebezpečný, protože umožňuje přístup k libovolnému adresáři, který je přístupný ze souboru se skriptem: adresář s relacemi, systémové složky a mnoho dalšího.
Ochrana dat relace
Ve výchozím nastavení se všechny informace o relaci zapisují do dočasného adresáře. Pokud používáte sdílený hosting, někdo kromě vás může napsat skript a číst data relace. Dejte si proto pozor na ukládání hesel nebo čísel kreditních karet v relacích.
Pokud stále potřebujete ukládat taková data v relaci, pak je šifrování nejlepším měřítkem. To problém zcela nevyřeší, protože zašifrovaná data nejsou 100% bezpečná, ale uložené informace budou nečitelné. Také byste měli zvážit, že data relace mohou být uložena jinde, například v databázi. PHP má speciální metodu session_set_save_handler (), která vám umožňuje ukládat data relace vlastním způsobem.
Od PHP 5.4 můžete objekt typu SessionHandlerInterface předat session_set_save_handler ().
Chyba při zpracování
Při vývoji aplikace stojí za to věnovat pozornost všem druhům chyb, které mohou nastat, je však třeba je před koncovými uživateli skrýt. Pokud se uživatelům zobrazují chyby, váš web je zranitelný. Nejlepším řešením by tedy byla odlišná konfigurace pro cílový server a vývojový server.
Na veřejném serveru musíte deaktivovat volby jako display_errors a display_start_up_errors, ale volby jako error_reporting a log_errors by měly být aktivní, aby byly protokolovány všechny chyby, se kterými se uživatelé setkají.
Můžete také použít set_error_handler k definování vlastního ovladače chyb. Mohou však existovat omezení, protože nativní ovladač je nižší než nativní mechanismus PHP. Chyby E_CORE_ERROR, E_STRICT nebo E_COMPILER_ERROR nelze zachytit ve stejném souboru jako konkrétní obslužná rutina. Kromě toho nelze zachytit chyby, které se mohou vyskytnout v samotném handleru.
Pro elegantnější způsob zachycení výjimek by měl být potenciálně nebezpečný kód umístěn do bloku try / catch. Všechny nativní výjimky musí být objekty tříd nebo podtříd Exception. Pokud byly vyvolány výjimky, lze je zpracovat v bloku try / catch.
Ochrana zahrnutých souborů
Často se v PHP skriptech načítají další soubory, jako je připojení k databázi a mnoho dalších. Někteří vývojáři dávají těmto souborům příponu .inc. PHP ve výchozím nastavení takové soubory neanalyzuje. Pokud je oslovíte přímo, uživatel uvidí text tohoto souboru. Pokud se hackerovi podaří získat přístup k souboru uchovávajícímu datové připojení k databázi, může později získat přístup ke všem datům vaší aplikace. Pro nahrané soubory tedy vždy používejte příponu .php a ukládejte je tam, kde není přímý přístup uživatele.
Výsledek
Pokud se budete řídit uvedenými 8 pravidly, výrazně to zlepší odolnost vaší aplikace vůči různým druhům útoků. Nedůvěřujte údajům zadávaným uživateli, chraňte své soubory a databázi.
Zamysleme se nad tím, kdo je hacker? Hacker není cracker! Lidé si tyto pojmy často pletou. Hacker je především člověk s myšlením out-of-the-box a v tom je takříkajíc jeho síla.
Abyste úspěšně odolali hackerovi, musíte se také naučit myslet mimo rámec. Jak se říká, klín se vytlouká klínem.
Dnes vám nabídnu velmi neobvyklý způsob, jak se chránit před útoky typu php include. Samozřejmě se nehodí pro každého. A pokud upřímně, chrání ne před samotným útokem, ale před jeho odhalením. Zaujatý?
Jak najít včetně...
Nejprve si ujasněme, jak přesně se útočník snaží najít zranitelnost.
Vypadá to takto. Útočník postupně upravuje všechny příchozí parametry za předpokladu, že se data těchto parametrů dostanou do funkce include. No, nebo pokud se jednoduchým způsobem pokusí "připojit" soubory. A aby mohl určit, zda existuje zranitelnost nebo ne, potřebuje zahrnout nějaký soubor do cílového systému (pokud ví - existuje zranitelnost, ne - neexistuje žádná zranitelnost).
Přirozeně, pokud útočník jedná zvenčí, nezná strukturu umístění adresářů a souborů a nemůže připojit žádný soubor, protože nezná cestu k němu. Existují však soubory, které v systému vždy existují a ke kterým jsou vždy oprávnění ke čtení. Pro Linux je to / etc / passwd a pro Windows nechť je to C: \ boot.ini. Ale mimochodem, Windows nás málo zajímají, takže dále budeme mluvit o passwd
/ etc / passwd
Pravděpodobně jste ve svých protokolech narazili na více záznamů formuláře:
Akce = .. / etc / passwd% 00
? action = .. / .. / etc / passwd% 00
? akce = .. / .. / .. / etc / passwd% 00
? akce = .. / .. / .. / .. / etc / passwd% 00
? akce = .. / .. / .. / .. / .. / etc / passwd% 00
? do = .. / etc / passwd% 00
? do = .. / .. / etc / passwd% 00
? do = .. / .. / .. / etc / passwd% 00
? do = .. / .. / .. / .. / etc / passwd% 00
? do = .. / .. / .. / .. / .. / etc / passwd% 00
? id = .. / etc / passwd% 00
? id = .. / .. / etc / passwd% 00
? id = .. / .. / .. / etc / passwd% 00
? id = .. / .. / .. / .. / etc / passwd% 00
? id = .. / .. / .. / .. / .. / etc / passwd% 00
Pokud ano, pak byste měli vědět, že jste se pokusili najít php include (no, nebo schopnost číst libovolné soubory, ale to nás teď nezajímá). Pokud tedy jeden z vašich parametrů není správně zpracován a skončí ve funkci zahrnout (), pak by byl přidán soubor / etc / passwd, jeho obsah by byl interpretován jako php skript, a protože neobsahuje tagy php kódu, zobrazil by se v prohlížeči beze změny. To by sloužilo jako „značka“ pro útočníka, aby měl zranitelnost.
Proč to píšu, k tomu, že při hledání include se útočník určitě (garantuji, že v 90% případů) pokusí soubor přidat / etc / passwd.
Chraňte se, pane!
Možná si teď říkáte: "Chce nabízet běžný WAF a filtrovat pakety podle přítomnosti / etc / passwd v nich?" Ne. Toto je standardní způsob. To je příklad toho, jak uvažuje obyčejný člověk.
Pojďme trochu kreativně. Proč do obsahu souboru passwd prostě nepřidáme nějaký php kód? A pokud se náhle útočníkovi podaří ho připojit, spustí se náš php kód. (Považujete to za nesmysl? - podívejte se na závěr)
Vzhledem k tomu, že víme, že jediný, kdo bude hádat, zda tento soubor zahrnout, je cracker, musí to náš php kód zakázat, a aby nedošlo k dalšímu hackování našeho systému, zablokujte zranitelný soubor a je žádoucí upozornit správce o incidentu.
Ale jak přidáte php kód do / etc / passwd, protože jeho syntaxe je přísně regulována? Každý uživatel má pole „komentář“ – popis uživatele, můžete tam zadat cokoli chcete (samozřejmě kromě dvojtečky). Proto vezmeme a přidáme uživatele do systému s komentářem, který potřebujeme. Poté bude / etc / passwd obsahovat následující řádek
root: x: 0: 0: Superuser: /:
démon: *: 1: 5 :: /: / sbin / sh
bin: *: 2: 2 :: / usr / bin: / sbin / sh
sys: *: 3: 3 :: /:
adm: *: 4: 4 :: / var / adm: / sbin / sh
bezpečnostní uživatel: *: 1001: 1001::/:
No, ve skriptu plug-in již provádíme akce, které potřebujete - zakázat uživatele, zablokovat požadavek, upozornit správce.
Výsledkem je, že máme jakousi past, která dokáže ochránit váš web před hackery.
Závěr
Ano, jsem si plně vědom toho, že vše napsané výše vypadá jako nesmysl. A naprosto chápu, že to nikdo v praxi nevyužije. Ale to není to, kvůli čemu jsem psal. Psal jsem proto, abych ukázal příklad nestandardního přístupu v oblasti ochrany.
Děkuji za pozornost =)
