A PHP szkriptek védelmére szolgáló összes szoftvertermék két kategóriába sorolható: azok, amelyek további modulokat igényelnek a szerveren, és amelyek a webszerverek szokásos konfigurációjával működnek. Előbbiek a biztonság szempontjából megbízhatóbbak, mivel a PHP szkripteket szöveges formából speciális bináris kódba fordítják, de rendszergazdai jogokkal kell hozzáférni a szerverhez. Utóbbiak szinte minden PHP-támogatással rendelkező hostingon működnek, az ingyeneseken is, de nem túl nehéz feltörni őket. A titkosítást vagy tömörítést nem használó forráskódok külön alcsoportba sorolhatók.
Szerver szintű védelmek:
A Zend Encoder / Zend SafeGuard Suite a legnépszerűbb kereskedelmi védelem, a Zend támogatási modulokat általában minden fizetett tárhelyen telepítik. A Zend tartomány- és IP-szkriptet, próbaszkript-időzítést és hatékony elfedést biztosít. Minden operációs rendszer támogatott. A közterületen számos lehetőség kínálkozik a Zend eltávolító segédprogramokhoz, mindegyik módosított PHP 4-es és 5-ös verziója. A Zend régebbi verzióit probléma nélkül eltávolítják, utóbbinál a forráskód elhomályosítása okoz nehézségeket.Új, aktívan fejlődő kereskedelmi védelem. Saját API-k szintjén interakciót biztosít védett szkriptekkel; Windows és Linux operációs rendszerek támogatottak. Alacsony elterjedtsége miatt nem telepítik hagyományos virtuális tárhelyre, de a felhasználók dedikált szerverekre telepíthetik. Nincsenek nyilvános dekóderek.
A kereskedelmi védelem gyakorlatilag nem található, nincs telepítve a virtuális tárhelyre. Lehetővé teszi a szkriptek próbaidőszakának beállítását dátumellenőrzéssel külső időszervereken, védett szkriptek szerverekhez kötését, ip-címet, a hálózati kártya MAC-címét, és ezeket az adatokat a visszafejtéshez használják fel. Minden operációs rendszer támogatott. Nincsenek nyilvános dekóderek.
phpSHIELD. SourceGuardian PHP prototípushoz. A két fejlesztő egyesülése után leállt a független termék fejlesztése. A fő funkció ugyanaz, nincsenek nyilvános dekóderek.
ionCube PHP kódoló. A második legnépszerűbb kereskedelmi szkriptvédő termék. A Zend nyilvános dekódereinek megjelenése után egyre gyakrabban használják és telepítik a megosztott tárhelyre. Nemcsak szkriptek, hanem sablonok, xml-dokumentumok, képek, bináris fájlok titkosítását is lehetővé teszi. Védett fájlokat köt a szerverekhez, van egy erős obfuszkátor, minden operációs rendszer támogatott. Nincsenek nyilvános dekóderek, de bizonyos esetekben a deZender eltávolíthatja.
PHTML kódoló. Egy ritka kereskedelmi biztonsági rendszer, amely az ilyen típusú termékek szokásos funkcionalitását biztosítja, minden operációs rendszer alatt működik. Külön díj ellenében megvásárolhatja az eredeti biztonsági kódokat, és igényei szerint módosíthatja azokat. Nincsenek nyilvános dekóderek.
DWebEncoder. Egzotikus védelem a Windows számára, amelyet arra terveztek, hogy scriptes prezentációkat és katalógusokat készítsen CD-ken. A telepített formában ez olyan, mint egy független webszerver, amelyen a kódolt php szkriptek futnak le. Nincsenek nyilvános dekóderek.
PHP Compact. A védekezés inkább elméleti, mint gyakorlati. Az egyik hazai fórumon fejlesztették, de úgy néz ki, nem jutott tovább a szerző kiadásain. Nincsenek dekóderek, valamint védett szkriptek.
Nyílt forráskódú kiegészítő a Turck MMCache és eAccelerator régi php-gyorsítókhoz. A szkripteket bájtkódokká alakítja, hogy növelje végrehajtásuk sebességét. A moduloknak vannak Windows és Linux verziói. Nincsenek nyilvános dekóderek, de talán a projekt nyílt forráskódja valamilyen módon segít a tanulmányban.
Forrás szintű védelmek:
PHP LockIt! ... Népszerű kereskedelmi védelem, nagyon elterjedt, főleg külföldi fejlesztők szkriptjeiben. Lehetővé teszi, hogy próbaidőszakot állítson be a szkriptek működéséhez, tartományokhoz és IP-címekhez való kötéshez, szabványos php eszközökkel (gzinflate) tömöríti a szkripteket. Az egyetlen trükkös rész egy jó obfuszkátor. A különböző védelmi változatok csak a kicsomagoló modul módosításában térnek el egymástól. Könnyen eltávolítható kézi és automatikus üzemmódban is. Obfuszkátor nélkül pontosan a forráskódig távolítják el, obfuszkátorral további feldolgozást igényel.CNCcrypto. Még demóverzió sincs nyilvánosan, az elemzést védett szkriptek segítségével végezték el. A csuklós modult nem nehéz kicsomagolni, a védelem csak a forráskód jó obfuszkálásán alapul.
PHPCipher. A védelem egy online szolgáltatás. A szkripteket tartalmazó archívum feltöltődik az oldalra, és a már védett is letöltődik. A fizetős licenc lehetővé teszi, hogy adataival védett szkripteket írjon alá, és azokat kereskedelmi célokra használja. Az ingyenes licenc csak személyes használatot tesz lehetővé. Maga a védelem egy Zend által védett php-modul, amely védett szkriptekhez csatlakozik, a deZend után a védelmi modul és az abból való összes szükséges konstans beszerzése teljesen kikerül a forráskódból. Nincs obfuszkátor funkció.
ByteRun Protector PHP-hez. Egy kereskedelmi termék, a licenc típusától függően, lehetővé teszi a szkriptek védelmét mind a szerver szintjén, mind a forráskód szintjén. Szervervédelem alapfunkciókkal, semmi különös. A szkript szintű védelem nagyon egyszerűen eltávolítható automatikusan és manuálisan. A szerververzióhoz nincs nyilvános dekódoló.
A védelem nagyon népszerű a hazai fejlesztők körében. Ez egy védelmi modul, amely erősen tele van üres kóddal, amely az include-on keresztül kapcsolódik a védett szkriptekhez. A dekódoló algoritmus nagyon egyszerű, nem okoz nehézséget a kézi és az automatikus eltávolítás során. Minden esetben teljesen eltávolítjuk a forráskódból, nincs obfuszkátor funkció. Vannak apró funkciók a dekódolás speciális eseteihez, de ezeket itt nem ismertetjük.
CodeLock. Egy másik népszerű védelem, az írástudatlan programozás nagyszerű példája. Ez egy php alkalmazás, amely lehetővé teszi maguknak a szkripteknek és a munkájuk eredményének a böngészőben történő kódolását javascript segítségével. A szkriptek jelszóval védhetők, de a közepes megvalósítás miatt a jelszót a csuklós védelem eltávolítása nélkül is könnyű kideríteni. A védelmi modul egy üres kóddal teli php szkript, amely védett szkriptekhez csatlakozik. A védelmi algoritmus nagyon egyszerű, teljesen eltávolítva a forráskódból. Nincs homályosító funkció.
TrueBug PHP Encoder, újabban TrueBug PHP Obfuscator & Encoder. Nagyon érdekes felfedeznivaló. Az 1.0.2-es verzió előtt a szabványos php-eszközöket használták a gzip-tömörítéshez, az 1.0.3-as verzió óta a szerzők saját tömörítési algoritmust fejlesztettek ki. Az új TrueBug PHP Obfuscator & Encoder termék a forráskód obfuszkálása és optimalizálása funkcióval bővül. A védelem egyetlen gyenge pontja a változatlan script dekódoló algoritmus, de maga az algoritmus a védelem minden verziójához változik. Az elemzés után a védelem könnyen eltávolítható pontosan a forráskódig, persze feltéve, hogy nem használták az obfuszkátort.
Zorex PHP CryptZ. A védelem a CodeLockhoz hasonlóan egy php alkalmazás, működéséhez MySQL adatbázis szükséges. A védelmi modul egy beépülő php szkript, több rétegben titkosítva. Az elemzés után az algoritmus nagyon könnyen eltávolítható pontosan a forráskódba. Nincs obfuszkátor funkció.
Ingyenes PHP kódoló. Ingyenes online szolgáltatás php szkriptek kódolásához. A védelmi modul egy Zend által lefedett beépülő php-script, amit le kell tölteni az oldalról.A Zend eltávolítása és az algoritmus elemzése után a védelem egyszerűen teljesen eltávolítható a forráskódból. A védelmi algoritmus változatlan, nincs obfuszkátor funkció.
Php szkript, primitív kódolás, szabványos base64. Nem érdemel több figyelmet, és nincs gyakorlati érdeke.
A szabványos wp-signup.php helyett saját regisztrációs oldalt hozunk létre a multisite számára.
Egy tipikus WordPress telepítésnél a regisztrációs (bejelentkezés, jelszó-visszaállítás) oldalon a wp-login.php fájl jelenik meg.
- /wp-login.php - engedélyezés
- /wp-login.php?action=register - regisztráció
- /wp-login.php?action=lostpassword - jelszó visszaállítása
A wp-login.php fájlban külön feltételek vannak a multisite-hez. Tehát amikor a /wp-login.php?action=register hivatkozásra kattint egy több webhelyen, a WordPress átirányít a /wp-signup.php oldalra. Sok témában az oldal nem tűnik túl vonzónak, ezért elkészítjük saját magunkat.
A hálózat fő oldala
Alapértelmezés szerint a WordPress megnyit egy regisztrációs oldalt (wp-signup.php) a hálózat fő domainjén (webhelyén). A hálózat minden egyes webhelyéhez azonban létrehozhat külön regisztrációs oldalt, még akkor is, ha eltérő témájúak. Figyelembe vesszük azt az esetet, amikor a hálózat minden oldalának van saját regisztrációs oldala, de ugyanazt a témát használják, és az oldalak csak nyelvükben különböznek egymástól. Ha különböző témákat használ, több kódot kell írnia.
functions.php?
Nem. Úgy tűnik, ennek a fájlnak a neve minden WordPress-cikkben szerepel. Esetünkben, tekintettel arra, hogy a regisztrációs funkciót több webhelyre tervezték, ésszerű áthelyezni azokat az MU-bővítményekbe, amelyek betöltődnek bármely webhely megnyitásakor.
Lírai kitérő
Érdemes megjegyezni, hogy az MU-bővítmények korábban töltődnek be, mint a hagyományos bővítmények, és mielőtt a WordPress magja teljesen betöltődik, így egyes függvények meghívása végzetes hibákhoz vezethet a PHP-ben. Ennek a "korai" betöltésnek is megvannak a maga előnyei. Például egyetlen témán belül sem ragaszkodhat bizonyos műveletekhez, amelyek még azelőtt indulnak el, hogy a functions.php fájl betöltődik a témából. Példa erre a Jetpack bővítmény jetpack_module_loaded_related-posts (related-posts - a modul neve) formátumú műveletei, amelyekkel nyomon lehet követni a Jetpack moduljainak tevékenységét. A témafájlból nem lehet ehhez a művelethez "kapaszkodni", mert a művelet már a téma betöltése előtt elindult - a bővítmények a témák előtt töltődnek be. Megtekintheti a WordPress betöltési sorrendjének általános képét a kódex Műveletreferencia oldalán.
Fájlsorrend
Az MU bővítmények tetszőleges számú fájlt és bármilyen struktúrát tartalmazhatnak, amely logikusnak tűnik. Valami ehhez hasonló hierarchiához ragaszkodom:
| -mu-plugins | - | -load.php | - | - | -selena-network | - | - | - | -regisztráció | - | - | - | - | -plugin.php | - | - | - | - | -... | - | - | - | -jetpack | - | - | - | - | -plugin.php
A hálózatunkhoz szükséges összes "plugin" be van kapcsolva a load.php fájlba:
// Fordítóprogramok betöltése az összes kiegészítőhöz load_muplugin_textdomain ("selena_network", "/ selena-network / languages /"); // A hálózati regisztrációhoz WPMU_PLUGIN_DIR szükséges. "/selena-network/signup/plugin.php"; // Más bővítményekhez // WPMU_PLUGIN_DIR szükséges ...
A beépülő modulok mappái a selena-network mappában vannak tárolva, mindegyiknek megvan a saját plugin.php-je, amelyet a load.php-ben is tartalmazunk. Ez rugalmasságot és lehetőséget biztosít a dolgok gyors ki- és bekapcsolására.
Regisztrációs oldal címe
A regisztrációs oldal címének megadásához a wp_signup_location szűrőt kell használni. A wp-login.php fájlban található, és felelős a wp-signup.php oldalra történő átirányításért.
Case "register": if (is_multisite ()) (wp_redirect (apply_filters ("wp_signup_location", network_site_url ("wp-signup.php"))); kilépés;
Adjuk hozzá a funkciónkat a mu-plugins / selena-network / signup / plugin.php fájlhoz, amely visszaadja a regisztrációs oldal címét az aktuális oldalon:
Függvény selena_network_signup_page ($ url) (return home_url (). "/ Regisztráció /";) add_filter ("wp_signup_location", "selena_network_signup_page", 99);
A selena_network az az előtag, amelyet a webhelyemen lévő MU-bővítményeken belüli összes függvény nevében használok az ütközések elkerülése érdekében. Ezt a saját egyedi előtagomra kell cserélni. A szűrő prioritása 99, mert egyes bővítmények, például a bbPress és a BuddyPress felülírhatják ezt az URL-t a sajátjukkal (az MU beépülő modulok korábban töltődnek be, mint a normál beépülő modulok, lásd fent). Vegye figyelembe, hogy a hálózati_hely_url () helyett a home_url () értéket használja, hogy a látogató ugyanazon a tartományon maradjon. Bármely URL használható címként.
Hozzon létre egy oldalt
Most hozzunk létre egy oldalt a site.com/signup/ címmel a normál felületen keresztül, a gyermektéma mappában pedig a page-signup.php az új oldalunk sablonja. A „regisztráció” szó helyett egyedi azonosító is használható.
Az új sablonon belül meg kell hívni a selena_network_signup_main () függvényt, amely megjeleníti a regisztrációs űrlapot.
Érdemes megjegyezni, hogy a sablonokkal végzett teljes folyamat nem szükséges, helyette létrehozhat saját rövid kódot, amely a selena_network_signup_main () függvényt is meghívja.
wp-signup.php és wp-activate.php
Most kezdjük el a regisztrációs űrlapot megjelenítő függvény létrehozását. Ehhez másolja a wp-signup.php és wp-activate.php fájlokat a WordPress gyökérkönyvtárából a mu-plugings / selena-network / signup / mappába (és ne felejtse el csatlakoztatni őket a mu-plugins / selena-network / regisztráció / plugin.php) ... A fájlokkal végzett további manipulációk leírása rendkívül nehéz és időigényes, ezért ezeket Önnek kell elvégeznie. Csak leírom, hogy pontosan mit kell tenni, és közzéteszem a projektem forrásfájljait:
- A fájl elejéről távolítson el minden követelményt, függvényhívást és egyéb, a függvényeken kívüli kódot.
- Nevezze át az összes függvényt egyedi előtagok hozzáadásával a nevekhez.
- Csomagolja be a wp-signup.php kód alsó részét a selena_network_signup_main függvénybe, és írja be a globális $ active_signup legelejére; ...
- Cserélje ki az elrendezést a sajátjával a megfelelő helyeken.
A wp-activate.php fájlon belül nagyjából ugyanezt kell tennie:
- Távolítson el minden kódot a függvényeken kívül, csomagolja be az elrendezést egy külön funkcióba.
- Szükség esetén módosítsa az elrendezést.
A wp-activate.php fájl felelős a fiókaktiválási oldalért. A regisztrációs oldalhoz hasonlóan ehhez is külön sablont kell készíteni, amin belül a wp-activate.php fájlból hívod meg a függvényt.
Aktiváló leveleket küldünk
A regisztrációs oldal e-mailt küld a látogatónak a fiók aktiválásához szükséges linkkel. Alapértelmezés szerint ezt az ms-functions.php fájl wpmu_signup_user_notification () függvénye teszi meg. Funkciói kölcsönözhetők az Ön funkciójához. A funkció használatának abbahagyásának oka, hogy elküldi a fiókaktiválási hivatkozást a wp-activate.php webhelyről. Ezt a funkciót a wpmu_signup_user_notification szűrővel tudod "letiltani", false értéket adva rá (ha ezt nem teszed meg, az aktiváló levél kétszer kerül elküldésre, oké, valójában két különböző betű).
Függvény armyofselenagomez_wpmu_signup_user_notification ($ user, $ user_email, $ key, $ meta = array ()) (// ... // A wpmu_signup_user_notification () függvény kódja wp_mail ($ user_email, wp_specialchars_decode ($ message_headers), $ message_headers ; return false;) add_filter ("wpmu_signup_user_notification", "armyofselenagomez_wpmu_signup_user_notification", 10, 4);
Ennek eredményeként a Selena téma regisztrációs oldala sokkal tisztábbnak és pontosabbnak tűnik.
Következtetés
Sok más nem túl helyes módszer létezik ugyanerre az interneten - Apache átirányítások, AJAX űrlapok, amelyek Java Script nélkül nem működnek, stb. saját webhely.
Ügyeljen arra, hogy óvatosan szerkessze a fájlokat, és igyekezzen ne nagyon eltérni az eredetitől, hogy a jövőben, ha a WordPress megváltoztatja a wp-signup.php és a wp-activate.php fájlokat, könnyebb lesz összehasonlítani őket. változtatások.
Ne felejtse el megvizsgálni a fent leírt összes funkció forráskódját, hogy teljesen megértse, mi és hogyan történik a kódban.
Bónusz. Spammer elleni védelem
Még a legkisebb WordPress-webhelyek is gyakori levélszemét-regisztrációnak vannak kitéve. A botok szűrésére végtelen feltételeket lehet írni, sokszor inkább mesterséges intelligencia létrehozásának kísérletét 🙂 Multisite esetén nekem sokat segített az Apache-ban szokásos átirányítás, amivel a /wp-signup.php és /wp- megnyitásakor acitvate.php, 404-et kértem (nem vagyok az Apache konfiguráció szakértője, ezért lehet, hogy a szabályaim nem túl helyesek).
RewriteEngine on RewriteBase / RewriteRule ^ wp-signup \ .php - RewriteRule ^ wp-activate \ .php - # WordPress BEÁLLÍTÁS # Alapértelmezés szerint ne érintse meg a WordPress szabályokat :) # ... # WordPress VÉGE
P. S. Igyekszem a lehető legrészletesebben leírni néhány harmadik féltől származó dolgot, mert amikor elkezdtem, néha nem volt senki, aki sok mindent felszólított és elmagyarázott. Azt is hiszem, hogy az ilyen apró tippek más anyagokkal kapcsolatban arra ösztönöznek valakit, hogy valami újat tanuljon, és bővítse tudását. A RewriteRule bejegyzésekben reguláris kifejezések használatosak, egyáltalán nem bonyolultak, például a ^ karakter egy sor elejét jelenti.
„Pénzért bontják a bankoldalakat, kémkedésért a Pentagont, és senkinek sem kell az én projektem” – sajnos ezt gondolja a legtöbb személyes blog, internetes névjegykártya, kis cégek virtuális irodája tulajdonosa. Csak kevesen gondolkodnak azon, hogyan védjék meg az oldalt, de hiába. A modern valóságban a hackerek szemében abszolút minden platform, függetlenül a típustól és a népszerűségtől, érdekes. Kinek lehet szüksége az Ön erőforrására és miért? Találjuk ki:
1. A scriptkiddis csínytevései. A szakzsargon a törekvő hackerekre utal, akik megteszik első lépéseiket a "sötét oldalon". Több eszköz beszerzése, vagy néhány saját program megírása után szívesen tesztelik teljesítményüket az első áldozaton, akivel találkoznak, és általában a legegyszerűbb (gyengén védett és nem frissített CMS-t) választják.
2. Fekete SEO. A tisztességtelen optimalizálók szolgáltatásait továbbra is használják - a 10-nél több TCI-vel rendelkező projektek kódjába rejtett linkek elhelyezését továbbra is gyakorolják. És mindenekelőtt a nyílt forráskódú motorok (Joomla, Drupal, OpenCart és így tovább) erőforrásait érik támadások.
3. Botnet építése. A WordPress htaccess-szel és bővítményekkel való védelme azért is lényeges, mert abszolút bármilyen erőforrás felhasználható zombihálózat létrehozására, amelyet DDoS támadásoknál, spamelésnél stb. használnak.
4. Járulékos kár. Végül, lehet, hogy nem támadnak meg – a fő cél a tárhely lesz, és az oldal csak a szolgáltató informatikai infrastruktúrájának egyik nagy sebezhetőségeként fog szolgálni. Természetesen a hackerek nem törődnek a sorsával.
A hackelés következményei lehetnek a legkellemetlenebbek: tartalom, vagy az erőforrás egészének elvesztése, pesszimista a keresőmotorok találataiban, közönségvesztés a „Az oldal veszélyeztetheti számítógép vagy mobileszköz biztonságát” felirat miatt, ill. akár a büntetőügyben való részvétel kockázata is, ha az Ön internetes forrása alapján jogellenes cselekményeket követtek el.
Tehát bátran kijelenthetjük, hogy a biztonsági problémák abszolút minden webmestert érintenek. És ha figyelmen kívül hagyja őket, a keresőmotorok népszerűsítésére tett erőfeszítések (és ez pénz és értékes idő) egyik napról a másikra kárba mehet. A probléma nagyon sürgős, ezért úgy döntöttem, hogy elindítok egy cikksorozatot, amely a hálózati fenyegetésekről és azok kezelési módszereiről szól. A népszerű CMS rendszer - Wordpress három kérdésben kerül szóba.
Módszerek a WordPress webhely biztonságossá tételére
Az egyik legprimitívebb hackelési módszer a nyers erőszak. Szó szerint a kifejezést „brute force”-nak fordítják, és azt jelenti, hogy a lehetséges opciók brutális erővel történő felsorolásával be kell szerezni egy pár bejelentkezési/jelszót. A brute-forcerek gyakran a motor- és szerverbeállítások hibáinak kihasználásával próbálják megkönnyíteni az életüket – ez segít nekik például megtalálni a fiók nevét, ami jelentősen csökkenti a kombinációk számát. Ezen sérülékenységek megszüntetéséről, valamint a jogosulatlan hozzáférési kísérletek elleni küzdelem módszereiről lesz szó.
1. Használjon egyedi rendszergazdai bejelentkezést
Alapértelmezés szerint a rendszer felajánlja egy admin nevű felhasználó létrehozását. A WordPress webhely védelme érdekében azonban a legjobb, ha véletlenszerű betűkből és számokból álló bejelentkezést használ. Élő erőforráson az adminisztrátor neve probléma nélkül módosítható a következő két módszer egyikével:
Az adminisztrációs panelen keresztül. Lépjen a „Felhasználók” részre, kattintson az „Új hozzáadása” gombra, és hozzon létre egy fiókot. A „Szerep” mezőben válassza az „Adminisztrátor” lehetőséget, és erősítse meg a műveletet. Ezután jelentkezzen be újra az újonnan létrehozott fiók nevében, térjen vissza a „Felhasználók” részhez, válassza az „admin” lehetőséget, és kattintson a „Törlés” gombra. A megnyíló ablakban helyezze a rádiógombot a „Minden tartalom összekapcsolása” pozícióba, és válasszon új rendszergazdát a legördülő listából, majd kattintson a „Törlés megerősítése” gombra.
... A phpMyAdmin használatával. Sokkal egyszerűbb ugyanezt az eljárást végrehajtani az adatbázis-vezérlőpulton keresztül. Válassza ki a kívánt adatbázist, keresse meg a wp_users táblát, keresse meg az „admin” sort (ID = 1), kattintson a „Change” gombra, és írja be a kívánt nevet.
2. Hozzon létre egy dedikált közzétételi fiókot
Ha az adminisztrátor "kimarad", ez további védelmet biztosít. Hozzon létre egy külön fiókot a cikkek közzétételéhez, és kapcsolja össze az összes korábban közzétett anyagot az 1. bekezdésben leírt módon. Ezután adjon hozzá információkat, és csak egy új fiókból kommunikáljon az olvasókkal.
3. Írjon be egy erős jelszót
Kövesse az általánosan elfogadott ajánlásokat: a jelszónak legalább 10 karakter hosszúnak kell lennie, egyedinek kell lennie, és véletlenszerű nagy- és kisbetűkből, számokból és speciális karakterekből állhat.
Semmi esetre sem szabad:
... értelmes kifejezésekből állítson össze jelszót
... bármilyen tényszerű adatot használjon (születési idő, leánykori név, bankszámlaszám, folyó év...)
Ez kiküszöböli annak kockázatát, hogy egy jelszót szótár segítségével válasszunk, és jelentősen megnöveli a nyers erőszakhoz szükséges időt. Tehát egy 10 karakterből álló, csak kisbetűket és számokat tartalmazó sorozat (hki458p1fa) feltörése 10 napot vesz igénybe egy számítógépen, de ha nagybetűket és további karaktereket ad hozzá (Nv6 $ 3PZ ~ w1), akkor ez az időszak 526 évre nő, ami szinte abszolút WordPress védelmet garantál. Ezeket a jelszavakat meglehetősen nehéz kitalálni és megjegyezni, különösen, ha több projektért is felelős. Ezért ezek előállításához és tárolásához jobb speciális kezelőket használni, például az ingyenesen terjesztett KeePassX-et vagy egy szokásos tesztdokumentumot (jobb, ha egy archívumba csomagolják jelszóval).
4. Változtassa meg az adatbázis jelszavát
A fenti szabályok a MySQL hozzáférési kód biztonságára is érvényesek. Végül is ott van az összes tartalom, valamint az adminisztrátor titkos kifejezésének hash-je. Ha már gyenge jelszót használunk, érdemes venni a fáradságot és megváltoztatni. Ez a következőképpen történik:
1. Nyissa meg a phpMyAdmin vezérlőpultját
2. Nyissa meg a „Felhasználók” lapot, és válassza ki az adatbázis tulajdonosát
3. Kattintson a „Jogosultságok szerkesztése” lehetőségre.
4. Keresse meg a "Jelszó módosítása" oszlopot, és írja be az új titkos sorozatot a megfelelő mezőkbe
5. Mentse el a változtatásokat az "OK" gombra kattintva
Most már csak a wp-config.php szerkesztése van hátra, különben a WordPress nem tud csatlakozni az adatbázishoz. Keresse meg a define sort ('DB_PASSWORD', "jelszó"); és a jelszó szó helyett írja be az új jelszót. Vegye figyelembe, hogy mivel a (') karakter az SQL-parancsok elválasztására szolgál, nem szabad jelmondat részeként használni.
5. Rendszeresen frissítse a jelszavakat
Ezeket legalább hathavonta cserélni kell. A kódmondatok rendkívüli megváltoztatását MINDIG el kell végezni, miután:
Adatok továbbítása hitelesítés céljából harmadik feleknek (programozóknak, rendszergazdáknak, optimalizálóknak és egyéb szakembereknek, még akkor is, ha a tárhely cég munkatársainál dolgoznak)
... bejelentkezés egy webes erőforrásba valaki más számítógépéről (buliban, internetkávézóban)
... engedély olyan berendezéstől, amely feltörhetett (vírussal fertőzött gép)
6. Ne felejtse el megváltoztatni a cookie-k titkos kulcsait
Ezek a wp-config.php fájlban találhatók. 8 van belőlük:
| define ("AUTH_KEY", "egyedi kulcs"); define ("SECURE_AUTH_KEY", "egyedi kulcs"); define ("LOGGED_IN_KEY", "egyedi kulcs"); define ("NONCE_KEY", "egyedi kulcs"); define ("AUTH_SALT", "egyedi kulcs"); define ("SECURE_AUTH_SALT", "egyedi kulcs"); define ("LOGGED_IN_SALT", "egyedi kulcs"); define ("NONCE_SALT", "egyedi kulcs"); |
define ("AUTH_KEY", "egyedi kulcs"); define ("SECURE_AUTH_KEY", "egyedi kulcs"); define ("LOGGED_IN_KEY", "egyedi kulcs"); define ("NONCE_KEY", "egyedi kulcs"); define ("AUTH_SALT", "egyedi kulcs"); define ("SECURE_AUTH_SALT", "egyedi kulcs"); define ("LOGGED_IN_SALT", "egyedi kulcs"); define ("NONCE_SALT", "egyedi kulcs");
Ahogy a változók nevéből sejthető, a kulcsok felelősek a cookie-k titkosításáért (a jól ismert szleng: cookie - cookie, só - só, sós sütikkel etetjük a hackereket), amelyekből az oldal készül. „emlékezzen” a számítógépére az engedélyezés után. A lényeg az, hogy ha a támadó a rendelkezésére bocsátja is az adminisztrátori jelszó hash-ét, a felsorolt titkos kifejezések nélkül nem tudja generálni az oldal eléréséhez szükséges cookie-kat.
A biztonság javítása érdekében az alapértelmezett karaktersorozatokat a CMS telepítése után azonnal egyedi karakterekre kell cserélni. A kényelem kedvéért a fejlesztők létrehoztak egy webgenerátort, amely a www.api.wordpress.org/secret-key/1.1/salt/ címen található - amikor belép, látni fogja a kulcsokat, és ha frissíti az oldalt, a kombinációk frissülnek. .
7. Dupla jogosultság az adminisztrációs területhez
A Htaccess lehetővé teszi a WordPress webhely további biztonságosabbá tételét szerverszintű hitelesítés hozzáadásával. A kód így fog kinézni:
| < Files wp- login. php> # Beállítjuk az alapvető hitelesítési típust – ez azt jelenti, hogy amikor megpróbálja# a megadott könyvtár vagy fájl elérésekor jelszót kell megadni: AuthType alap # Írja be az űrlap fejlécében megjelenő szöveget: AuthName "Azonosítsa magát" # Adja meg a jelszót tartalmazó fájl elérési útját: AuthUserFile "/home/site/.htpasswd" # Jelezzük, hogy a wp-login.php fájl elérésekor meg kell adnia a jelszót:Érvényes felhasználó megkövetelése # A .htpasswd fájlhoz való hozzáférés megtagadása harmadik felektől:< Files . htpasswd>parancs engedélyezni, tagadni tagadni mindentől |
# Válassza ki az engedélyezési szkriptfájlt:
Ugyanakkor jó lenne magának a htaccessnek a biztonságáról is gondoskodni. Szigorúan véve egy ilyen direktívát a fő hosting beállításokban kell megfogalmazni, de bizonyos szolgáltatók figyelmetlensége miatt óvatosan kell eljárnia:
Helyettesítse a kívánt nevet a „bejelentkezés” helyett. Marad a jelszó generálása, valamint titkosítása, mert az ilyen adatok tiszta szövegben való tárolása megengedhetetlen luxus. Számos szolgáltatás létezik erre, de jobb, ha saját maga írja meg a szükséges szkriptet. Ez a következőképpen történik:
1) Hozzon létre egy .php fájlt a Jegyzettömbben, például crypt.php
2) Írja be a kódot a "Jelszó" szó helyett a jelszavával helyettesítve:
3) Mentse el a fájlt, és töltse fel a gyökérkönyvtárba
4) Kövesse a site_name.ru / crypt.php hivatkozást - a jelszó-kivonat megjelenik a képernyőn
5) Mentse el ezt az értéket .htpasswd fájlba, és töltse fel a gyökérkönyvtárba, és törölje a crypt.php fájlt
Az utolsó simítás a webes erőforrás-könyvtár tartalmának megtekintésének tilalma. Elég egyetlen sort hozzáadni a htaccesshez:
| Opciók Összes - Indexek |
Opciók Összes -Indexek
Ez azért történik, hogy a hackerek ne tudják megtudni, mely fájlok vannak a projektkönyvtárban. Sok tárhelyen ez a direktíva már szerepel a szerver beállításaiban, de ha ezt a pontot figyelmen kívül hagyják, akkor regisztrálnia kell magát.
8. Telepítse a captcha-t
A captcha használata lehetővé teszi, hogy levágja, ha nem az összeset, akkor legalább a legtöbb brute-force botot, és ezzel egyidejűleg. A WordPress webhelyvédelmi beépülő modulok könyvtára számos lehetőséget kínál. A Google saját fejlesztésű megoldása mellett nagy érdeklődés övezi a vegyes (grafikus és szöveges) típusú BestWebSoft Captcha-ját, amely matematikai műveleteken alapul. A szolgáltatásfüggetlenség, az áttekinthetőség és az elfogadható szintű komplexitás a modult a legjobbak közé emeli.
A testreszabás nem jelent nagy problémát. Az „Alap” lapon kiválaszthatja, hol jelenítse meg a captcha-t, valamint megadhat egy címet és egy szimbólumot a kötelező mezők megjelölésére.
A „Speciális” rész lehetővé teszi saját hibaüzenetek létrehozását, valamint további képcsomagok aktiválását, hogy még megnehezítsék a robotok életét.
Egy másik hasznos funkció az IP-címek beépített engedélyezési listája, amelyeknél a captcha nem jelenik meg.
A bővítmény telepítésének és aktiválásának eredményeként egy űrlap jelenik meg az engedélyezési oldalon:
9. Módosítsa az adminisztrátori címet
Ha egy WordPress oldal védelméről beszélünk, érdemes megemlíteni egy radikálisabb, de egyben bonyolultabb módot is - a bejelentkezési oldal URL-jének megváltoztatását szkript szinten. Az eljárást több szakaszban hajtják végre:
1. Nevezze át a wp-login.php fájlt. Használjon kisbetűs latin betűk, számok és kötőjelek véletlenszerű sorozatát. Például: abc-123.php
2. Keresse meg az összes hivatkozást a wp-login.php fájlra a kapott fájlban, és cserélje ki őket az új névre.
3. Az oldal megfelelő működéséhez a cserét a következő helyen is el kell végezni: 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
Ezeket a manipulációkat követően az adminisztrációs panel az / abc-123.php webhelyen található. Az új fájlhoz való hozzáférést korlátozni kell, és jelszóval kell védeni a fent leírtak szerint. A potenciális hackerek félrevezetése egy hamis wp-login.php fájl létrehozásával és jelszó beállításával is lehetséges.
Még egyszerűbb lehetőség a "wp-login.php átnevezése" kiegészítő használata. A webhely védelmét szolgáló bővítmény telepítése után egy új mező jelenik meg a "Beállítások" -> "Permalinks" menüben:
10. Adja meg az adminisztrátor IP-címét
Statikus IP-cím esetén további biztonság is biztosítható. Ha megtagadja a wp-login.php fájlhoz való hozzáférést a saját számítógépén kívül, az sokkal megnehezíti a hackerek életét:
| < Files wp- login. php>parancs megtagadás, megtagadás engedélyezése mindenből engedélyezés 127.0.0.1, 127.0.02 # Az IP-címeket vesszővel válassza el |
11. Tiltsa le az engedélyezési hibákat
A jelszavak brutális erőltetése során a támadó nagyon hasznosnak találja, ha tudja, hogy a megadott adatok helytelenek voltak. Ilyen üzenetek jelennek meg minden sikertelen bejelentkezési kísérletnél, és a WordPress jelzi azt is, hogy mit adtak meg rosszul, a felhasználónevet vagy a jelszót. Ahhoz, hogy megszabaduljon tőlük, csak egy sort kell hozzáadnia a functions.php fájlhoz:
| add_filter ("bejelentkezési_hibák", create_function ("$ a", "return null;")); |
add_filter ("bejelentkezési_hibák", create_function ("$ a", "return null;"));
Ehhez válassza a "Megjelenés" -> "Szerkesztő" -> "Témafunkciók" lehetőséget az adminisztrációs panelen. A kódot a nyitó tag után kell írni
12. Használjon biztonságos kapcsolatot.
A felhasználó számítógépe és a webszerver közötti forgalom titkosítására létezik a https protokoll, melynek használata kizárja a fontos adatok, esetünkben azonosító adatok elfogásának lehetőségét. Az aktiváláshoz először meg kell vásárolnia egy SSL-tanúsítványt, amely egyszerre két funkciót lát el: egy webes erőforrás hitelesítését és a továbbított információk titkosítását. Beszerezheti erre szakosodott központokban, vagy számos domain név regisztrátortól. Nem kereskedelmi célból elég egy ingyenes belépő szintű tanúsítvány beszerzése (ilyet a www.startssl.com cég kínál). Ami a telepítési folyamatot illeti, általában részletesen le van írva a tárhely súgójában.
Miután megkapta az SSL-tanúsítványt, be kell állítania a webes erőforrás adminisztratív részének biztonságos kapcsolatra való átirányítását. A WordPress esetében ez a következő konstrukcióval történik:
| < IfModule mod_rewrite. c>Options + FollowSymlinks RewriteEngine On RewriteCond% (HTTPS) = off RewriteCond% (REQUEST_URI) = / wp- bejelentkezés. php RewriteRule (. *) https: |
Az SSL-tanúsítványok használatát motorszinten is kikényszerítheti. Ehhez nyissa meg a wp-config.php fájlt, és adja hozzá
| define ("FORCE_SSL_ADMIN", igaz); |
define ("FORCE_SSL_ADMIN", igaz);
Ezenkívül beállíthat egy globális átirányítást a http-ről a https-re. Az új webhelyek esetében ez a megközelítés az optimális, mivel a Google ösztönzi a biztonságos projekteket, bizonyos prioritást biztosítva számukra a keresési eredményekben:
| < IfModule mod_rewrite. c>Options + FollowSymlinks RewriteEngine on RewriteCond% (HTTPS) = off RewriteRule ^ (. *) $ Https: //% (HTTP_HOST)% (REQUEST_URI) |
13. Blokkolja a behatolókat
Ha bizonyos IP-címekről gyanús tevékenységet észlelünk, érdemes letiltani az oldalhoz való hozzáférésüket. Ez az előző módszerrel analóg módon történik. A különbség az, hogy a direktívák a projekt egészére vonatkoznak, és felsoroljuk azoknak a címeit, akiket ki akarunk tiltani:
Rendeljen Engedélyezés, Megtagadás Engedélyezés az összestől Megtagadás 127.0.0.1-től, 127.0.02-től # Adja meg a nem kívánt IP-t
A módszer megbízható, de hatástalan. Először is valamilyen módon rögzíteni kell a brutális erőltető szolgáltatások kéréseit, és el kell különíteni őket a tekintélyes látogatóktól. Másodszor, egy hatalmas támadás esetén egyszerűen nem fogja tudni nyomon követni és meghajtani a hackerek és robotok IP-címét manuálisan. Ez a módszer csak akkor jó, ha az adminisztrátor megbízható feketelistával rendelkezik a címekről.
Ellenkező esetben használhat egy WP Cerber nevű WordPress webhelybiztonsági bővítményt. Ez a megoldás teljesen ingyenes, miközben rendkívül lenyűgöző eszközkészletet kínál a CMS-hackelés megelőzésére. Közvetlenül az adminisztrációs panelről telepítheti.
Alapértelmezés szerint meglehetősen ésszerű paramétereket kínálnak. A félreértések elkerülése érdekében azonban a próbálkozások számát 5-re kell növelni.
Az „IP blokkolása minden wp-login.php kérelemhez” jelölőnégyzetet be kell jelölni, ha a korábban leírt módon módosítja az adminisztrátori címet.
Erre a célra használhatja a WP Cerber saját eszközét is:
A Citadella webhely védelmére szolgáló bővítménymód szintén nem igényel további konfigurációt. Úgy tervezték, hogy „molylepkék” a projektet egy hatalmas brute force támadás során. Jobb, ha törölje a jelet a „Fájlba való bejelentkezési kísérletek rögzítése” jelölőnégyzetből – ez segít kiküszöbölni a szerver további terhelését.
A „Hozzáférési listák” lapon egy „fekete” és „fehér” IP-lista hozható létre (ha van statikus címe, feltétlenül adja hozzá a megbízhatóak listájához), az „Eszközök” részben pedig importálja és exportálja a korábban elvégzett beállításokat. Ezek a lehetőségek azonban nem igényelnek külön mérlegelést.
14. Helyezze át a konfigurációs fájlt
Mint fentebb megtudtuk, a wp-config.php olyan kritikus adatokat tárol, mint a MySQL eléréséhez szükséges bejelentkezési név és jelszó, valamint az API kulcsok. A következő lépés kézenfekvőnek tűnik – a WordPress védelme a htaccess segítségével a fájlhoz való hozzáférés korlátozásával:
| < Files wp- config. php>Parancs engedélyezni, megtagadni mindenkitől |
Van azonban egy megbízhatóbb módszer is. A WordPressnek van egy nagyon érdekes funkciója, amelyről kevesen tudnak. A motor lehetővé teszi, hogy a konfigurációs fájlt egy szinttel a gyökérkönyvtár fölé helyezzük. A php áthelyezhető a webhely könyvtárába. Ebben az esetben a fájl az interneten keresztül teljesen elérhetetlenné válik, miközben a benne lévő információkat a CMS továbbra is elolvassa.
15. Adja hozzá a REFERER csekket
Egy jól bevált módszer a WordPress spam elleni védelmére szintén segít a brute force támadásokkal szemben. Hiszen a jelszavak brutális kényszerítése semmiképpen sem kézi munka: erre a célra speciális programokat használnak. Ez azt jelenti, hogy a bejövő kérések fejlécellenőrzésének engedélyezésével levághatja azokat a robotokat, amelyek a semmiből jöttek üres HTTP REFERER-rel:
| < IfModule mod_rewrite. c>RewriteEngine On RewriteCond% (REQUEST_METHOD) POST RewriteCond% (REQUEST_URI). (wp- megjegyzések- bejegyzés | wp- bejelentkezés) \. php * RewriteCond% (HTTP_REFERER)!. * tekseo. su. * [VAGY] RewriteCond% (HTTP_USER_AGENT) ^ $ RewriteRule (. *) http: //% (REMOTE_ADDR) / $ 1 |
16. XML-RPC védelme
A 3.5-ös verzió óta a WordPressből eltűnt az XML-RPC távoli eljáráshívási protokoll letiltásának lehetősége. Alapvetően a mobilalkalmazásokkal való interakcióhoz szükséges, de nem mindenkinek van szüksége ilyen funkciókra. Ugyanakkor az xmlrpc.php-t aktívan használják DDoS-támadások végrehajtására, mivel ez az egész projekt Achilles-sarka.
Ezenkívül a hackerek arra gondoltak, hogy XML-RPC-t használnak brute force-hoz. A wp.getUsersBlogs metódus segítségével sokkal gyorsabban iterálhatja a hitelesítő adatokat, mint az adminisztrációs űrlap használatával. Mivel sok XML-RPC híváshoz engedély szükséges, egy ehhez hasonló kérés:
| < methodCall> < methodName>wp. getUsersBlogs < params>< param>< value>< string>admin < param>< value>< string> 12345 |
hatására a motor jelzi, hogy az átadott kombináció helyes-e. Ahhoz, hogy megszabaduljon ettől a csapástól, teljesen le kell tiltania a protokollt. Ez többféleképpen is megtehető:
1) Az xmlrpc.php fájlhoz való hozzáférés letiltásával a htaccess segítségével
igényel_egyszer (ABSPATH. "wp-settings.php");
regisztrálni kell
function remove_x_pingback ($ headers) (unset ($ headers ["X-Pingback"]); return $ headers;) add_filter ("wp_headers", "remove_x_pingback");
4) A Control XML-RPC közzétételi beépülő modul használatával a megfelelő opció visszaadása a Beállítások -> Írás menüpontban:
Figyelem: a bővítmény az aktiválás után azonnal letiltja a protokollt, és a beállításokban a megfelelő jelölőnégyzet bejelölésével engedélyezheti.
17. Kövesse nyomon a nyers erő támadásait
Végül érdemes megemlíteni egy érdekes beépülő modult a hackelési kísérletek naplózásához - Authentication és xmlrpc log writer. Bár ugyanaz a WP Cerber rendelkezik beépített megfigyelő eszközökkel, ez a modul továbbra is hasznos lesz, különösen azok számára, akiknek szükségük van a fent leírt protokoll képességeire. Az AX LogWriter képes nyomon követni a nyers erőt az xmlrpc.php-n keresztül, így felmérheti a fenyegetettség mértékét és azt, hogy tanácsos-e teljesen megtagadni a képességeit. Végül pedig azoknak, akik egyáltalán nem vettek részt projektjük biztonságában, az oldal védelmét szolgáló bővítmény felnyitja a szemét a felsorolt tevékenységek fontosságára.
Az AX LogWriter használata egyszerű. A telepítés után az adminisztrációs menüben megjelenik a megfelelő rész, ahol elvégezheti az összes szükséges módosítást:
A „Hiba típusa” mezőben válassza ki a mentési módot. Támogatja a rendszernaplóba, az Apache szervernaplóba való írást, valamint az egyéni fájl létrehozásának lehetőségét. Ez utóbbi esetben egyéni hibanapló-névvel és egyéni hibanapló-útvonallal is konfigurálható. Ez széles lehetőségeket nyit meg a rendszergazda számára – például a megoldás a fail2ban-nal együtt is használható. Ne felejtse el kiválasztani a megfelelő időzónát az Időzóna oszlopban.
Az egyéni napló közvetlenül az adminisztrációs panelről tekinthető meg az Egyéni naplónéző oldalon:
Összefoglaljuk:
A felsorolt módszerek jelentősen növelik az erőforrás biztonságát, és megvédik azt a botoktól, a brute-forcingtól, a hálózati huligánoktól és a gyakorló scriptkiddis-ektől. A fent leírtak azonban csak a jéghegy csúcsa. A támadók arzenáljában sokkal kifinomultabb módszerek vannak. A következő cikkben pedig arról fogunk beszélni, hogyan védheti meg magát a valódi hackerektől a motor és a kiszolgálószoftver különféle sebezhetőségeinek használatával. Mint ebben az anyagban, az általános "higiéniai szabályokon" kívül a kulcsfontosságú CMS-beállításokat, a kód módosításának módjait, valamint a legfontosabb beépülő modulokat is figyelembe veszik.
Ha az alkalmazások biztonságáról van szó, fontos, hogy ne csak a hardverre és az operációs rendszerre ügyeljünk, hanem a biztonságos szkriptek írására is. Ebből a cikkből megtudhatja, hogyan tarthatja alkalmazását biztonságossá és kevésbé sebezhetővé. Az alábbiakban felsoroljuk azokat az intézkedéseket, amelyek segítenek megvédeni alkalmazását mindenféle támadástól:
- Bejövő adatok ellenőrzése
- XSS támadások elleni védelem
- Védelem a CSRF támadások ellen
- Az SQL-befecskendezés megakadályozása
- Fájlrendszer védelme
- Munkamenet adatvédelem
- Hiba a feldolgozásban
- A mellékelt fájlok védelme
Bejövő adatok ellenőrzése
Az alkalmazás megtervezésekor törekedni kell arra, hogy megvédje azt a „rossz” bejövő adatoktól. A követendő szabály a következő: "Soha ne higgye el, amit a felhasználó beír." Bár a legtöbb felhasználó nem jelent veszélyt, mindig fennáll annak a lehetősége, hogy valaki fel akarja törni a webhelyét az űrlapokon vagy a címsoron keresztül bevitt „rossz” adatok segítségével. Ha mindig érvényesíti és szűri a bejövő adatokat, akkor jó eséllyel biztonságos alkalmazást írhat.
Mindig ellenőrizze az adatokat PHP-szkriptekben. Ha JavaScriptet használ az adatok ellenőrzésére, a támadó bármikor letilthatja azt a böngészőjében. Ebben az esetben az Ön alkalmazása veszélyben van. Senki sem ellenzi a JavaScript érvényesítését, de a jó védelem érdekében még egyszer ellenőrizni kell az adatokat a PHP szkriptekben.
XSS támadások elleni védelem
A webhelyek közötti szkriptelés vagy XSS-támadás olyan támadás, amely a potenciálisan sebezhető oldalakba kód bejuttatásán alapul. A veszély az, hogy a rosszindulatú kódokat űrlapokon keresztül lehet bevinni, majd megjeleníteni a böngészőben.
Tegyük fel, hogy webhelyén van egy űrlap a megjegyzések bevitelére, amelyek a hozzáadást követően azonnal megjelennek. A támadó beírhat egy JavaScript kódot tartalmazó megjegyzést. Az űrlap elküldése után az adatok elküldésre kerülnek a szerverre és bekerülnek az adatbázisba. Ezt követően a rendszer lekéri az adatokat az adatbázisból, és a HTML oldalon megjelenik az új megjegyzés, beleértve a beágyazott JavaScript kódot is. Átirányíthatja a felhasználót valamilyen rosszindulatú oldalra vagy adathalász webhelyre.
Alkalmazásai védelme érdekében futtassa a bejövő adatokat a strip_tags () függvényen keresztül, amely eltávolítja a jelenlévő címkéket. Amikor adatokat jelenít meg böngészőben, használja a htmlentities () függvényt.
Védelem a CSRF támadások ellen
A következő típusú támadás, amelyet megvizsgálunk, a CSRF-támadás vagy a webhelyek közötti kéréshamisítás. A támadó különféle trükköket alkalmaz, hogy bizalmas információkat szerezzen vagy üzletet kössön az áldozat tudta nélkül. Ez főleg a gyengén védett oldalakon történik, ahol az üzleti logika a GET kérések munkáján alapul.
Általánosságban elmondható, hogy a GET-kérések idempotensek. Az idempotencia ebben az összefüggésben azt jelenti, hogy egy és ugyanaz az oldal tetszőleges számú külső beavatkozás nélkül elérhető. Éppen ezért a GET kéréseket csak információhoz való hozzáférésre szabad felhasználni, de semmi esetre sem különféle tranzakciók végrehajtására.
A következő egyszerű példa bemutatja, hogyan lehet egy nem biztonságos webhelyet CSRF-támadásnak kitéve:
Tegyük fel, hogy Bob CSRF-támadást akar végrehajtani Alice ellen. Létrehozott egy speciális url-címet, és elküldte Alice-nek e-mailben:
Látogassa meg honlapomat!
Ha Alice jogosult az example.com webhelyre, és követi ezt a linket, akkor 1000 dollár kerül átutalásra a fiókjából Bob számlájára. Alternatív megoldásként Bob képet is küldhet, és kitöltheti a „rossz” URL-t az src attribútumban.
A böngésző nem tudja megjeleníteni ezt a képet, mivel nem létezik, de a kérés Alice tudta és közreműködése nélkül történik.
Az ilyen típusú támadások megelőzése érdekében csak POST kéréseket használjon az adatbázisban lévő információk megváltoztatására tervezett folyamatokhoz. Ne használja a $ _REQUEST. Használja a $ _GET-et a GET-paraméterek kezelésére, és a $ _POST-t a POST-paraméterek lekérésére.
További intézkedésként létrehozhat egy egyedi tokent, és csatolhatja azt minden POST-kéréshez. Amikor egy felhasználó bejelentkezik a rendszerbe, létrehozhat egy véletlenszerű tokent, és beírhatja a munkamenetbe. Mivel minden űrlap megjelenik a felhasználó számára, ezt a tokent egy rejtett mezőbe kell írni. Az alkalmazás üzleti logikájának olyan funkcionalitást kell biztosítania, amely ellenőrzi a tokent az űrlapokból és a munkamenetben tárolt tokent.
Az SQL-befecskendezés megakadályozása
Az adatbázis lekérdezéséhez PDO-t kell használnia. Paraméterezett lekérdezésekkel és előkészített utasításokkal mérsékelheti az SQL-befecskendezés veszélyét.
Vessünk egy pillantást a következő példára:
A fenti kódban kérést küldünk az előkészítés () metódusra, amely tartalmazza a megnevezett paramétereket:: név és: életkor. Így a lekérdezés előre össze van állítva a további adatpótláshoz. Az execute () metódus meghívásakor a kérés teljesen létrejön és végrehajtódik. Ha ezt a technikát használja, akkor a támadó minden SQL-injektálási kísérlete érvénytelen lesz.
Fájlrendszer védelme
Felelős fejlesztőként mindig olyan kódot kell írnia, amely nem veszélyezteti a fájlrendszert. Nézzük meg azt a kódot, amely a felhasználó által beküldött adatoktól függően küld egy fájlt letöltésre.
Ez a szkript nagyon veszélyes, mert lehetővé teszi minden olyan könyvtár elérését, amely a szkriptet tartalmazó fájlból elérhető: a szekciókat tartalmazó könyvtár, a rendszermappák és még sok más.
Munkamenet adatvédelem
Alapértelmezés szerint az összes munkamenet információ az ideiglenes könyvtárba kerül. Ha megosztott tárhelyet használ, akkor rajtad kívül valaki tud szkriptet írni és munkamenetadatokat olvasni. Ezért ügyeljen arra, hogy jelszavakat vagy hitelkártyaszámokat tároljon a munkamenetekben.
Ha továbbra is ilyen adatokat kell tárolnia egy munkamenetben, akkor a titkosítás a legjobb intézkedés. Ez nem oldja meg teljesen a problémát, mivel a titkosított adatok nem 100%-os biztonságban, de a tárolt információk olvashatatlanok lesznek. Azt is figyelembe kell vennie, hogy a munkamenet adatai máshol is tárolhatók, például egy adatbázisban. A PHP rendelkezik egy speciális session_set_save_handler () metódussal, amely lehetővé teszi a munkamenetek adatainak a saját módján történő tárolását.
A PHP 5.4 óta a SessionHandlerInterface típusú objektumot átadhatja a session_set_save_handler () számára.
Hiba a feldolgozásban
Egy-egy alkalmazás fejlesztése során érdemes odafigyelni mindenféle felmerülő hibára, azonban ezeket el kell rejteni a végfelhasználók elől. Ha hibák jelennek meg a felhasználók számára, akkor ez sebezhetővé teszi webhelyét. Így a legjobb megoldás a célszerver és a fejlesztőszerver eltérő konfigurációja lenne.
A nyilvános kiszolgálón le kell tiltania az olyan opciókat, mint a display_errors és a display_start_up_errors, de az olyan opcióknak, mint a error_reporting és log_errors aktívnak kell lenniük, hogy a felhasználók által tapasztalt összes hiba naplózásra kerüljön.
A set_error_handler segítségével saját hibakezelőt is megadhat. Azonban lehetnek korlátok, mert a natív kezelő rosszabb, mint a natív PHP mechanizmus. Az E_CORE_ERROR, E_STRICT vagy E_COMPILER_ERROR hibákat nem lehet elkapni ugyanabban a fájlban, mint egy adott kezelő. Ezenkívül a kezelőben előforduló hibákat sem lehet elkapni.
A kivételek elfogásának elegánsabb módja érdekében a potenciálisan veszélyes kódot a try / catch blokkban kell elhelyezni. Minden natív kivételnek a kivétel osztályainak vagy alosztályainak objektumainak kell lennie. Ha kivételeket dobtak, akkor azokat a try / catch blokkban lehet kezelni.
A mellékelt fájlok védelme
Gyakran más fájlok is betöltődnek PHP-szkriptekben, mint például az adatbázishoz való csatlakozás és sok más. Egyes fejlesztők ezeket a fájlokat .inc kiterjesztéssel látják el. A PHP alapértelmezés szerint nem elemzi az ilyen fájlokat. Ha közvetlenül megszólítja őket, a felhasználó láthatja ennek a fájlnak a szövegét. Ha a hackernek sikerül hozzáférnie az adatbázishoz való adatkapcsolatot tároló fájlhoz, akkor később az Ön alkalmazásának összes adatához hozzáférhet. Tehát mindig a .php kiterjesztést használja a feltöltött fájlokhoz, és tárolja azokat ott, ahol nincs közvetlen felhasználói hozzáférés.
Eredmény
Ha betartja a felsorolt 8 szabályt, akkor ez nagymértékben javítja alkalmazásának ellenálló képességét a különféle támadásokkal szemben. Ne bízzon a felhasználók által bevitt adatokban, védje fájljait és adatbázisait.
Gondoljunk csak bele, ki az a hacker? A hacker nem cracker! Az emberek gyakran összekeverik ezeket a fogalmakat. A hacker mindenekelőtt egy olyan ember, aki kiugróan gondolkodik, és úgymond ez az erőssége.
Ahhoz, hogy sikeresen ellenállhasson egy hackernek, meg kell tanulnia a dobozon kívül gondolkodni. Ahogy mondani szokás, az éket az ék kiüti.
Ma egy nagyon szokatlan módszert ajánlok Önnek, hogy megvédje magát az olyan támadásoktól, mint a php include. Persze nem mindenkinek való. És ha őszintén, nem magától a támadástól, hanem annak észlelésétől véd. Érdekelt?
Hogyan lehet megtalálni, beleértve...
Először is tisztázzuk, hogy a támadó pontosan hogyan próbálja megtalálni a sebezhetőséget.
Ez így néz ki. A támadó egyenként módosítja az összes bejövő paramétert, feltételezve, hogy ezen paraméterek adatai bekerülnek az include függvénybe. Nos, vagy ha egyszerű módon megpróbálja "csatolni" a fájlokat. És annak megállapításához, hogy van-e sebezhetőség vagy sem, be kell helyeznie néhány fájlt a célrendszerbe (ha tudja - van sebezhetőség, nem - nincs sebezhetőség).
Természetesen, ha egy támadó kívülről cselekszik, akkor nem ismeri a könyvtárak és fájlok helyének szerkezetét, és nem tud semmilyen fájlt csatolni, mivel nem ismeri az elérési utat. De vannak fájlok, amelyek mindig léteznek a rendszerben, és amelyekhez mindig van olvasási engedély. Linux esetén ez az / etc / passwd, Windows esetén pedig legyen C: \ boot.ini. De mellesleg a Windows kevéssé érdekel minket, ezért a továbbiakban a passwd-ről fogunk beszélni
/ etc / passwd
Valószínűleg az űrlap több rekordjával találkozott a naplóiban:
Művelet = .. / etc / passwd% 00
? action = .. / .. / etc / passwd% 00
? action = .. / .. / .. / etc / passwd% 00
? action = .. / .. / .. / .. / etc / passwd% 00
? action = .. / .. / .. / .. / .. / 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
Ha igen, akkor tudnod kell, hogy megpróbáltad megtalálni a php include-ot (na jó, vagy tetszőleges fájlok olvasásának képességét, de ez most nem érdekel). Tehát, ha az egyik paramétere nincs megfelelően feldolgozva, és egy függvénybe kerül tartalmazza (), akkor az / etc / passwd fájl kerülne hozzá, a tartalma php scriptként értelmezhető, és mivel nem tartalmaz php kódcímkéket, változatlanul jelenne meg a böngészőben. Ez „jelzőként” szolgálna a támadó sebezhetőségére.
Miért írom ezt, arra, hogy az include keresésekor a támadó biztosan (az esetek 90%-ában) megpróbálja hozzáadni a fájlt / etc / passwd.
Védje magát, uram!
Talán most arra gondol: "Akar-e felajánlani egy normál WAF-ot és szűrni a csomagokat az / etc / passwd jelenléte alapján?" Nem. Ez a szabványos módszer. Ez egy példa arra, hogyan gondolkodik egy hétköznapi ember.
Legyünk egy kicsit kreatívak. Miért nem adunk hozzá egy php kódot a passwd fájl tartalmához? És ha a támadónak hirtelen sikerül összekapcsolnia, akkor a mi php kódunk lefut. (Szerinted hülyeség? - nézd meg a következtetést)
Mivel tudjuk, hogy ezt a fájlt csak egy cracker találja ki, ezért a php kódunknak tiltania kell azt, és a rendszerünk további feltörésének elkerülése érdekében blokkolja a sebezhető fájlt, és célszerű értesíteni a rendszergazdát. az esetről.
De hogyan kell hozzáadni a php kódot az / etc / passwd fájlhoz, mert a szintaxisa szigorúan szabályozott? Minden felhasználónak van egy „megjegyzés” mezője - a felhasználó leírása, oda bármit megadhat, amit akar (természetesen a kettőspont kivételével). Ezért veszünk és hozzáadunk egy felhasználót a rendszerhez a szükséges megjegyzéssel. Ezt követően az / etc / passwd a következő sort fogja tartalmazni
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
biztonsági felhasználó: *: 1001: 1001::/:
Nos, a beépülő szkriptben már végrehajtjuk a szükséges műveleteket - kitiltjuk a felhasználót, blokkoljuk a kérést, értesítjük a rendszergazdát.
Ennek eredményeként van egyfajta csapdánk, amely megvédheti webhelyét a feltöréstől.
Következtetés
Igen, teljesen tisztában vagyok vele, hogy a fent leírtak hülyeségnek tűnnek. És tökéletesen megértem, hogy ezt senki sem fogja használni a gyakorlatban. De nem ezért írtam. Azért írtam, hogy példát mutassak egy nem szabványos megközelítésre a védelem területén.
Köszönöm a figyelmet =)
