Kõik PHP-skriptide kaitsmiseks mõeldud tarkvaratooted jagunevad kahte kategooriasse: need, mis nõuavad serverisse lisamoodulite installimist, ja need, mis töötavad veebiserverite tavapärase konfiguratsiooniga. Esimesed on turvalisuse mõttes töökindlamad, kuna tõlgivad PHP skriptid tekstivormist spetsiaalseks binaarkoodiks, kuid nõuavad ligipääsu serverile administraatoriõigustega. Viimased saavad töötada peaaegu kõikidel PHP toega hostidel, ka tasuta, kuid neid pole väga raske häkkida. Eraldi alamrühmas saate valida lähtekoodi, mis ei kasuta krüptimist ega tihendamist.
Serveritaseme kaitsed:
Zend Encoder / Zend SafeGuard Suite - kõige populaarsem kaubanduslik kaitse, Zendi toetavad moodulid installitakse tavaliselt kogu tasulisele hostimisele. Zend pakub skriptide sidumist domeenide ja IP-ga, määrates prooviskriptide aja ja võimsa hägustamise. Kõik operatsioonisüsteemid on toetatud. Avalikus omandis oleva Zendi eemaldamiseks on mitu võimalust, kõik need on muudetud PHP versioonid 4 ja 5. Zendi vanad versioonid eemaldatakse probleemideta, viimase puhul on raskusi lähtekoodi hägustamine.Uus, aktiivselt arenev kaubanduslik kaitse. Natiivsete API-de tasemel pakub see suhtlemist kaitstud skriptidega; Windowsi ja Linuxi operatsioonisüsteeme toetatakse. Madala levimuse tõttu ei installita seda tavalisse virtuaalhostimisse, kuid kasutajad saavad seda installida spetsiaalsetes serverites. Avalikke dekoodereid pole.
Kommertskaitset ei leita peaaegu kunagi, seda ei installita virtuaalsetele hostidele. Võimaldab määrata skriptidele prooviperioodi kuupäevakontrolliga väliste täpse aja serverite suhtes, siduda kaitstud skripte serveritega, IP-aadressi, võrgukaardi MAC-aadressi ja neid andmeid kasutatakse dekrüpteerimiseks. Kõik operatsioonisüsteemid on toetatud. Avalikke dekoodereid pole.
phpSHIELD. SourceGuardian PHP prototüübi jaoks. Pärast kahe arendaja ühinemist lakkas see iseseisva tootena arenemast. Põhifunktsionaalsus on sama, avalikke dekoodereid pole.
ionCube PHP kodeerija. Teine populaarseim kaubanduslik skriptikaitsetoode. Pärast Zendi avalike dekooderite tulekut on seda üha enam kasutatud ja virtuaalsetele hostidele installitud. Võimaldab krüpteerida mitte ainult skripte, vaid ka malle, xml-dokumente, pilte, binaarfaile. Seob kaitstud failid serveritega, olemas on võimas obfuskaator, kõik operatsioonisüsteemid on toetatud. Avalikke dekoodereid pole, kuid mõnel juhul eemaldab selle deZender.
PHTML-kooder. Haruldane kaubanduslik kaitsesüsteem, mis pakub seda tüüpi toodetele tavapäraseid funktsioone, töötab kõigi operatsioonisüsteemidega. Tasu eest saate osta lähtekaitsekoode ja muuta neid vastavalt oma vajadustele. Avalikke dekoodereid pole.
DWebEncoder. Eksootiline kaitse Windowsile, mis on loodud skriptitud esitluste ja kataloogide loomiseks CD-del. Kui see on installitud, on see midagi iseseisva veebiserveri sarnast, millel käivitatakse kodeeritud php-skriptid. Avalikke dekoodereid pole.
PHP kompaktne. Kaitsmine on pigem teoreetiline kui praktiline. See töötati välja ühel kodumaisel foorumil, kuid tundub, et autori väljaannetest kaugemale pole asi jõudnud. Puuduvad aga dekooderid, samuti kaitstud skriptid.
Avatud lähtekoodiga lisand vanadele php-kiirenditele Turck MMCache ja eAccelerator. Tõlgib skriptid baitkoodiks, et suurendada nende täitmise kiirust. Moodulitest on Windowsi ja Linuxi versioonid. Avalikke dekoodereid pole, kuid võib-olla aitab projekti avatud lähtekoodiga kuidagi uuringus kaasa aidata.
Lähtekoodi taseme kaitsed:
PHP LockIt! . Populaarne kaubanduslik kaitse, mida leidub väga sageli, peamiselt välismaiste arendajate skriptidel. Võimaldab määrata skriptidele prooviperioodi, siduda domeenide ja IP-aadressidega, tihendada skripte tavaliste php tööriistadega (gzinflate). Ainus raskus on hea obfuskaator. Kaitse erinevad versioonid erinevad ainult lahtipakkimismooduli modifikatsiooni poolest. Kergesti eemaldatav nii käsitsi kui ka automaatrežiimis. Ilma obfuskaatorita eemaldatakse see täpselt lähtekoodini, obfuskaatoriga nõuab see täiendavat töötlemist.CNC-krüpto. Avalikus omandis pole isegi demoversiooni, analüüs viidi läbi turvaliste skriptide abil. Hingedega moodul ei valmista lahtipakkimisel raskusi, kaitse tugineb ainult lähtekoodi heale hägustamisele.
PHPCipher . Kaitse on võrguteenus. Teie skriptidega arhiiv laaditakse saidile üles ja juba kaitstud laaditakse tagasi. Tasuline litsents võimaldab teil allkirjastada oma andmetega kaitstud skripte ja kasutada neid ärilistel eesmärkidel. Tasuta litsents võimaldab ainult isiklikuks kasutamiseks. Kaitse ise on Zendiga kaitstud php moodul, mis ühendub kaitstud skriptidega.Pärast deZendit eemaldatakse kaitsemoodul ja sealt kõigi vajalike konstantide saamine täielikult lähtekoodi. Obfuskaatori funktsiooni pole.
ByteRun Protector PHP jaoks. Kaubandustoode võimaldab olenevalt litsentsi tüübist kaitsta skripte nii serveri kui ka lähtekoodi tasemel. Serverikaitse standardfunktsioonidega, ei midagi erilist. Skriptitaseme kaitse eemaldatakse väga lihtsalt automaatselt ja käsitsi. Serveriversiooni jaoks pole avalikku dekoodrit.
Kaitse kodumaiste arendajate seas väga populaarne. See on kaitsemoodul, mis on tihedalt täis tühja koodi, mis on ühendatud kaudu kaitstud skriptidega. Dekodeerimisalgoritm on väga lihtne, see ei tekita raskusi käsitsi ja automaatsel eemaldamisel. Kõikidel juhtudel eemaldatakse see täielikult lähtekoodist, hägususfunktsioon puudub. Dekodeerimise erijuhtudel on väikesed funktsioonid, kuid neid siin ei kirjeldata.
Koodilukk. Veel üks populaarne kaitse, suurepärane näide kirjaoskamatust programmeerimisest. Tegemist on php-rakendusega, mis võimaldab javascripti abil brauseris kodeerida nii skripte endid kui ka nende töö tulemusi. Skripte saab kaitsta parooliga, kuid keskpärase teostuse tõttu on parooli lihtne teada saada ka ilma hingedega kaitset eemaldamata. Kaitsemoodul on php-skript, mis on täis tühja koodi, mis ühendub kaitstud skriptidega. Kaitsealgoritm on väga lihtne, lähtekoodist täielikult eemaldatud. Hägususfunktsioon puudub.
TrueBug PHP Encoder, hiljuti TrueBug PHP Obfuscator & Encoder. Väga huvitav kaitsja, mida uurida. Enne versiooni 1.0.2 kasutati standardseid php tööriistu gzip tihendamiseks, alates versioonist 1.0.3 töötasid autorid välja oma tihendusalgoritmi. Uus toode TrueBug PHP Obfuscator & Encoder on lisanud hägustamise ja lähtekoodi optimeerimise funktsiooni. Ainus kaitse nõrk koht on muutumatu skripti dekodeerimisalgoritm, kuid algoritm ise muutub iga kaitseversiooni puhul. Pärast sõelumist eemaldatakse kaitse lihtsalt täpselt lähtekoodini, muidugi eeldusel, et pole kasutatud obfuskaatorit.
Zorex PHP CryptZ. Kaitse, nagu CodeLock, on php-rakendus, mille tööks on vaja MySQL-i andmebaasi. Kaitsemoodul – php-s olev lisandmoodul, mis on krüpteeritud mitmes kihis. Pärast algoritmi sõelumist eemaldatakse see väga lihtsalt täpselt lähtekoodini. Obfuskaatori funktsiooni pole.
Tasuta PHP kodeerija. Tasuta võrguteenus php-skriptide kodeerimiseks. Kaitsemoodul on Zendiga kaetud plug-in php skript, mis tuleb saidilt alla laadida.Peale Zendi eemaldamist ja algoritmi parsimist eemaldatakse kaitse lihtsalt täielikult lähtekoodist. Kaitsealgoritm on muutumatu, obfuskaatori funktsioon puudub.
PHP skript, primitiivne kodeering, standardne base64. See ei vääri rohkem tähelepanu ega paku praktilist huvi.
Loome standardse wp-signup.php asemel oma mitme saidi registreerimislehe.
Tavalise WordPressi installi korral kuvatakse registreerimise leht (sisselogimine, parooli lähtestamine) failis wp-login.php.
- /wp-login.php – autoriseerimine
- /wp-login.php?action=register – registreerimine
- /wp-login.php?action=lostpassword – parooli lähtestamine
Mitme saidi jaoks on failis wp-login.php eraldi tingimused. Seega, kui klõpsate mitmel saidil /wp-login.php?action=register, suunab WordPress ümber lehele /wp-signup.php. Paljude teemade puhul ei tundu leht kuigi atraktiivne, seega teeme oma.
Võrgu põhisait
Vaikimisi avab WordPress registreerumislehe (wp-signup.php) veebi põhidomeenil (veebisaidil). Siiski on võimalik teha iga võrgu saidi jaoks eraldi registreerimisleht, isegi kui neil on erinev teema. Arvestame juhtumiga, kui kõigil võrgu saitidel on oma registreerimisleht, kuid kasutatakse sama teemat ja saidid erinevad ainult keele poolest. Kui kasutatakse erinevaid teemasid, on vaja rohkem koodi.
Funktsioonid.php?
Ei. Tundub, et selle faili nime mainitakse igas WordPressi artiklis. Võttes arvesse asjaolu, et registreerimisfunktsioon on mõeldud mitme saidi jaoks, on meie puhul mõttekas teisaldada see MU pistikprogrammidesse, mis laaditakse mis tahes saidi avamisel.
Lüüriline kõrvalepõige
Väärib märkimist, et MU-pluginad laaditakse enne tavalisi pluginaid ja enne WordPressi tuuma täielikku laadimist, seega võib mõne funktsiooni kutsumine põhjustada PHP-s saatuslikke vigu. Sellel "varajasel" laadimisel on oma eelised. Oletame, et mis tahes teema sees ei saa te klammerduda mõne toimingu külge, mis toimivad isegi enne, kui teemast on laaditud fail functions.php. Selle näiteks on toimingud Jetpacki pistikprogrammist kujul jetpack_module_loaded_related-posts (related-posts on mooduli nimi), millega on võimalik jälgida Jetpacki moodulite tegevust. Seda toimingut ei saa teemafailist "manustada", kuna toiming on juba käivitatud enne teema laadimist – pluginad laaditakse enne teemasid. Üldpilti WordPressi laadimisjärjekorrast saate vaadata koodeksi lehel Action Reference.
Faili järjekord
MU pistikprogrammid võivad sisaldada mis tahes arvu faile ja mis tahes struktuuri, mis tundub teile loogiline. Järgin sellist hierarhiat:
|-mu-plugins |-|-load.php |-|-|-selena-network |-|-|-|-registreeru |-|-|-|-|-plugin.php |-|-|-| -|-... |-|-|-|-jetpack |-|-|-|-|-plugin.php
Failis load.php on ühendatud kõik meie võrgu jaoks vajalikud "pluginad":
// Kõigi lisandmoodulite tõlgete laadimine load_muplugin_textdomain("selena_network", "/selena-network/languages/"); // Võrgu registreerimine nõuab WPMU_PLUGIN_DIR . "/selena-network/signup/plugin.php"; // Teised pluginad // nõuavad WPMU_PLUGIN_DIR ...
Pluginate kaustad on salvestatud selena-võrgukausta, igaühel neist on oma plugin.php , mille lisame kausta load.php . See annab paindlikkuse ja võimaluse teatud asju kiiresti keelata ja lubada.
Registreerimislehe URL
Filtrit wp_signup_location kasutatakse registreerumislehe aadressi määramiseks. Selle võib leida failist wp-login.php ja see vastutab saidile wp-signup.php ümbersuunamise eest.
Case "register" : if (is_multisite()) ( wp_redirect(apply_filters("wp_signup_location", network_site_url("wp-signup.php"))); exit;
Lisame oma funktsiooni failile mu-plugins/selena-network/signup/plugin.php , mis annab praeguse saidi registreerimislehe aadressi:
Funktsioon selena_network_signup_page ($url) ( return home_url () . "/signup/"; ) add_filter ("wp_signup_location", "selena_network_signup_page", 99);
selena_network on eesliide, mida kasutan kokkupõrgete vältimiseks oma saidil kõigi funktsioonide nimedes MU pistikprogrammides. See tuleks asendada teie unikaalse eesliitega. Lisage filtri prioriteet 99, sest mõned pistikprogrammid, nagu bbPress ja BuddyPress, võivad selle aadressi oma aadressiga üle kirjutada (MU pluginad laaditakse varem kui tavalised pluginad, vt ülal). Pange tähele, et kodu_url() kasutatakse network_site_url() asemel, et hoida külastaja samas domeenis. Aadressina võib kasutada mis tahes URL-i.
Lehekülje loomine
Nüüd loome tavalise liidese kaudu lehe aadressiga site.com/signup/ ja alamteema kaustas on meie uue lehe malliks page-signup.php . Sõna "registreerumine" asemel võite kasutada kordumatut ID-d.
Uue malli sees peate kutsuma funktsiooni selena_network_signup_main(), mis kuvab registreerumisvormi.
Väärib märkimist, et kogu protsess mallidega on valikuline ja selle asemel saate luua oma lühikoodi, mis kutsub ka funktsiooni selena_network_signup_main().
wp-signup.php ja wp-activate.php
Nüüd loome funktsiooni, mis kuvab registreerimisvormi. Selleks kopeerige failid wp-signup.php ja wp-activate.php WordPressi juurtest kausta mu-plugings/selena-network/signup/ (ja ärge unustage neid lisada mu-plugins/selena-network'i /signup/plugin.php) . Edasisi failitöötlusi on äärmiselt raske ja pikk kirjeldada, nii et peate need ise tegema. Kirjeldan lihtsalt, mida täpselt tuleb teha, ja avaldan oma projekti lähtefailid:
- Faili algusest eemaldage kõik nõuded , funktsioonikutsed ja muud funktsioonidest väljas olevad koodid.
- Nimetage kõik funktsioonid ümber, lisades nimedele kordumatud eesliited.
- Mähi wp-signup.php koodi alumine osa funktsiooni selena_network_signup_main ja kirjuta kohe alguses globaalne $active_signup; .
- Asendage paigutus õigetes kohtades enda omaga.
Wp-activate.php sees peate tegema sama:
- Eemaldage kogu kood väljaspool funktsioone, mähkige paigutus eraldi funktsiooniks.
- Vajadusel muutke paigutust.
Fail wp-activate.php vastutab konto aktiveerimislehe eest. Nagu registreerimislehe puhul, tuleb ka selle jaoks luua eraldi mall, mille sees tuleb wp-activate.php failist funktsioon välja kutsuda.
Aktiveerimismeilide saatmine
Registreerimisleht saadab külastajale e-kirja koos lingiga konto aktiveerimiseks. Vaikimisi tegeleb sellega faili ms-functions.php funktsioon wpmu_signup_user_notification(). Selle funktsionaalsust saab selle funktsiooni jaoks laenata. Põhjus, miks peate selle funktsiooni kasutamise lõpetama, on see, et see saadab saidilt wp-activate.php konto aktiveerimise lingi. Selle funktsiooni saab “välja lülitada” kasutades wpmu_signup_user_notification filtrit, andes sellele false (kui seda ei tehta, saadetakse aktiveerimiskiri kaks korda, ok, tegelikult kaks erinevat tähte).
Funktsioon armyofselenagomez_wpmu_signup_user_notification($user, $user_email, $key, $meta = array()) ( // ... // Kood funktsioonist wpmu_signup_user_notification() wp_mail($user_email, wp_specialchars_decode($subjecters)), ; return false; ) add_filter("wpmu_signup_user_notification", "armyofselenagomez_wpmu_signup_user_notification", 10, 4);
Tänu sellele on Selena teemaline registreerimisleht muutunud palju puhtamaks ja korralikumaks.
Järeldus
Internetis on palju muid mitte väga õigeid viise, kuidas sama teha - Apache ümbersuunamised, AJAX-vormid, mis ilma Java Scriptita ei tööta jne. Mulle see kõik ei meeldinud, nii et proovisin seda teha nii õigesti kui võimalik minu saidil.
Märgin, et faile tuleks hoolikalt redigeerida ja püüda mitte liiga palju algsetest kõrvale kalduda, et edaspidi, kui WordPress muudab faile wp-signup.php ja wp-activate.php, oleks lihtsam võrrelda. muudatuste leidmiseks.
Ärge unustage vaadata kõigi ülalkirjeldatud funktsioonide lähtekoodi, et täielikult mõista, mis ja kuidas koodi sees toimub.
Boonus. Rämpspostitajate kaitse
Isegi kõige väiksemaid WordPressi saite pommitatakse sageli rämpsposti registreerimisega. Botide filtreerimiseks saab kirjutada lõputult tingimusi, sageli pigem tehisintellekti loomise katseid 🙂 Multisaidi puhul aitas mind palju Apache'i tavapärane ümbersuunamine, millega palusin /wp-signup.php avamisel väljastada 404. ja /wp-acitvate.php (ma ei ole Apache seadistusekspert, seega ei pruugi mu reeglid väga õiged olla).
RewriteEngine rakenduses RewriteBase / RewriteRule ^wp-signup\.php - RewriteRule ^wp-activate\.php - # WordPressi alustamine # WordPressi vaikereeglid :) # ... # WordPressi LÕPP
P.S. Mõnda kolmanda osapoole asju püüan kirjeldada võimalikult üksikasjalikult, sest alustades polnud vahel kedagi, kes paljusid asju viiks ja seletaks. Usun ka, et sellised väikesed näpunäited muude materjalide kohta ajendavad kedagi uut õppima ja laiendavad oma teadmiste valdkonda. RewriteRule kirjed kasutavad regulaaravaldisi, need pole üldse keerulised, näiteks märk ^ tähendab rea algust.
"Pankade veebilehti rikutakse raha pärast, Pentagon on spionaaži pärast ja minu projekti pole kellelegi vaja," paraku on enamik isiklike ajaveebide, veebivisiitkaartide ja virtuaalsete esinduste omanikke just nii. väikefirmad arvavad. Vaid vähesed mõtlevad, kuidas saiti kaitsta, kuid asjata. Kaasaegses tegelikkuses pakub häkkerite silmis huvi absoluutselt iga sait, olenemata tüübist või populaarsusest. Kellel võib teie ressurssi vaja minna ja miks? Mõtleme selle välja:
1. Naeratab scriptkiddis. Kõrgoon viitab algajatele häkkeritele, kes astuvad esimesi samme "tumedale poolele". Olles soetanud mitu tööriista või kirjutanud paar oma programmi, on nad innukad testima oma jõudlust esimese ettejuhtuva ohvri peal ja valivad reeglina kõige lihtsamad (nõrgalt kaitstud ja uuendamata CMS-i) sihtmärgid.
2. Must müts SEO. Ebaausate optimeerijate teenused on endiselt kasutusel - rohkem kui 10 TCI-ga projektide koodidesse peidetud linkide paigutamist praktiseeritakse endiselt. Ja ennekõike langevad rünnaku alla avatud lähtekoodiga mootorite (Joomla, Drupal, OpenCart ja nii edasi) ressursid.
3. Bot-võrgu ehitamine. WordPressi kaitsmine htaccessi ja pistikprogrammidega on asjakohane ka seetõttu, et DDoS-i rünnakute, rämpsposti jms ajal kasutatava zombivõrgu loomiseks saab kasutada absoluutselt iga ressurssi.
4. Tagatiskahjustus. Lõpuks ei pruugi teid rünnata – hostimine on peamine eesmärk ja sait on vaid üks pakkuja IT-infrastruktuuri suur haavatavus. Muidugi jääb tema saatus häkkeritele ükskõikseks.
Häkkimise tagajärjed võivad olla kõige ebameeldivamad: sisu või ressursi kui terviku kadu, otsingumootori tulemuste pessimiseerumine, vaatajaskonna kaotus sildi "Sait võib ohustada arvuti või mobiilseadme turvalisust" tõttu ja isegi oht saada kriminaalasjas kostjaks, kui teie veebiressursi põhjal pandi toime ebaseaduslikke tegusid.
Seega võime kindlalt öelda, et turvaprobleemid puudutavad absoluutselt iga veebimeistrit. Ja kui need tähelepanuta jäetakse, võivad kõik otsingu edendamise jõupingutused (ja see on raha ja väärtuslik aeg) üleöö raisku minna. Probleem on väga asjakohane, seetõttu otsustasin alustada artiklite sarja võrguohtude ja nendega võitlemise kohta. Kolmes numbris tuleb kõne alla populaarne CMS-süsteem – WordPress.
WordPressi saidi kaitsemeetodid
Üks primitiivsemaid häkkimisviise on toore jõud. Sõna otseses mõttes tõlgitakse seda terminit kui "tooret jõudu" ja see tähendab sisselogimis- ja paroolipaari hankimist võimalike valikute täieliku loendi kaudu. Tihtipeale üritavad jõhkrad jõumehed oma elu lihtsamaks teha, kasutades ära vigu mootori- ja serveriseadetes – see aitab neil näiteks välja selgitada konto nime, mis vähendab oluliselt kombinatsioonide arvu. Arutletakse nende haavatavuste kõrvaldamise ja volitamata juurdepääsu katsete vastu võitlemise meetodite üle.
1. Kasutage ainulaadset administraatori sisselogimist
Vaikimisi palub süsteem teil luua kasutaja nimega admin. Kuid oma WordPressi saidi kaitsmiseks on kõige parem kasutada sisselogimist, mis koosneb juhuslikest tähtedest ja numbritest. Praeguses ressursis saab administraatori nime ilma probleemideta muuta, kasutades ühte kahest meetodist.
Adminni kaudu. Minge jaotisse "Kasutajad", klõpsake nuppu "Lisa uus" ja looge konto. Väljal "Roll" valige "Administraator" ja kinnitage toiming. Seejärel logige vastloodud konto nimel sisse, naaske jaotisesse "Kasutajad", valige "admin" ja klõpsake "Kustuta". Avanevas aknas seadke raadionupp valikule "Link kogu sisu" ja valige ripploendist uus administraator ning seejärel klõpsake nuppu "Kinnita kustutamine".
. phpMyAdmini kasutamine. Sama protseduuri on palju lihtsam läbi viia andmebaasi juhtpaneeli kaudu. Valige vajalik andmebaas, leidke tabel wp_users, leidke rida "admin" (ID=1), klõpsake "Muuda" ja sisestage soovitud nimi.
2. Looge spetsiaalne postitamiskonto
Kui administraator ei ole "särav", pakub see täiendavat kaitset. Looge artiklite postitamiseks eraldi konto ja linkige sellega kõik varem avaldatud materjalid lõikes 1 kirjeldatud viisil. Järgmiseks lisage teavet ja suhtlege lugejatega ainult uue konto kaudu.
3. Määrake keeruline parool
Järgige üldtunnustatud juhiseid: paroolid peavad olema vähemalt 10 tähemärgi pikkused, kordumatud ning sisaldama juhuslikku suur- ja väiketähtede, numbrite ja erimärkide jada.
Mitte mingil juhul ei tohiks te:
. koostage tähenduslikest fraasidest parool
. kasutada mis tahes faktilisi andmeid (sünniaeg, neiupõlvenimi, pangakonto number, jooksev aasta jne)
See välistab sõnastikust parooli valimise ohu ja pikendab oluliselt ka toore jõu kasutamiseks kuluvat aega. Seega kulub 10-tähemärgilise jada, mis koosneb ainult väiketähtedest ja numbritest (hki458p1fa) lahtimurdmine ühe arvuti jaoks 10 päeva, kuid kui lisate suurtähti ja lisamärke (Nv6$3PZ~w1), siis see periood pikeneb. kuni 526 aastat, tagades WordPressile peaaegu absoluutse kaitse. Selliste paroolide leidmine ja meeldejätmine on üsna keeruline, eriti kui jälgite mitut projekti. Seetõttu on nende genereerimiseks ja salvestamiseks parem kasutada spetsiaalseid haldureid, näiteks tasuta KeePassX-i või tavalist testdokumenti (parem, kui see on parooliga arhiivi pakitud).
4. Muutke andmebaasi parool
Ülaltoodud reeglid kehtivad ka MySQL-i pääsukoodi turvalisuse tagamiseks. Lõppude lõpuks on seal kogu sisu ja ka administraatori salafraasi räsi. Kui kasutate juba nõrka parooli, peaksite kaaluma selle muutmist. Seda tehakse järgmiselt.
1. Minge phpMyAdmini juhtpaneelile
2. Avage vahekaart "Kasutajad" ja valige andmebaasi omanik
3. Klõpsake valikul „Muuda õigusi”.
4. Leidke veerg "Muuda parooli" ja sisestage vastavatele väljadele uus salajane järjestus
5. Salvestage muudatused, klõpsates nuppu „OK”.
Nüüd jääb üle redigeerida wp-config.php, muidu ei saa WordPress andmebaasiga ühendust. Leia rida define('DB_PASSWORD', 'parool'); ja sisestage sõna parool asemel uus parool. Pange tähele, et kuna märki (') kasutatakse SQL-käskude eraldamiseks, ei tohiks seda kasutada paroolifraasi osana.
5. Värskendage oma paroole regulaarselt
Neid tuleks vahetada vähemalt kord kuue kuu jooksul. Koodifraaside erakorraline muutmine peab olema KOHUSTUSLIK pärast:
Andmete edastamine autentimiseks kolmandatele osapooltele (programmeerijatele, süsteemiadministraatoritele, optimeerijatele ja teistele spetsialistidele, isegi kui nad töötavad hostimisettevõtte heaks)
. veebiressursi sisestamine kellegi teise arvutist (peol, internetikohvikus)
. luba seadmetelt, mis võivad sattuda ohtu (viirusega nakatunud masin)
6. Ärge unustage muuta oma küpsiste saladusi
Need asuvad failis wp-config.php. Kokku on 8:
| define("AUTH_KEY" , "unikaalne võti" ) ; define("SECURE_AUTH_KEY" , "unikaalne võti" ) ; define("LOGGED_IN_KEY" , "unikaalne võti" ) ; define("NONCE_KEY" , "unikaalne võti" ) ; define("AUTH_SALT" , "unikaalne võti" ) ; define("SECURE_AUTH_SALT" , "unikaalne võti" ) ; define("LOGGED_IN_SALT" , "unikaalne võti" ) ; define("NONCE_SALT" , "unikaalne võti" ) ; |
define("AUTH_KEY", "unikaalne võti"); define("SECURE_AUTH_KEY", "ainulaadne võti"); define("LOGGED_IN_KEY", "ainulaadne võti"); define("NONCE_KEY", "unikaalne võti"); define("AUTH_SALT", "ainulaadne võti"); define("SECURE_AUTH_SALT", "ainulaadne võti"); define("LOGGED_IN_SALT", "unikaalne võti"); define("NONCE_SALT", "unikaalne võti");
Nagu muutujate nimedest arvata võis, vastutavad võtmed küpsiste krüptimise eest (tuntud kõnepruuk: küpsis - küpsised, sool - sool, toidame häkkereid soolatud küpsistega), mida kasutatakse saidi "mäleta" muutmiseks. ” arvuti pärast autoriseerimist. Põhimõte on see, et isegi kui ründaja saab oma käsutusse administraatori parooli räsi, ei saa ta ilma loetletud salafraasideta saidile juurdepääsuks vajalikke küpsiseid genereerida.
Turvalisuse suurendamiseks tuleks vaikemärgijadad kohe pärast CMS-i juurutamist asendada unikaalsetega. Mugavuse huvides on arendajad loonud veebigeneraatori, mis asub aadressil www.api.wordpress.org/secret-key/1.1/salt/ - sisenedes näed võtmeid ja kui lehte värskendad, siis kombinatsioonid uuendatakse. .
7. Topeltvolitus administraatori paneeli jaoks
Htaccess võimaldab teil oma WordPressi saiti veelgi turvalisemaks muuta, lisades serveritaseme autentimise. Kood näeb välja selline:
| < Files wp- login. php> # Määrake autentimise põhitüüp – see tähendab, et kui proovite# määratud kataloogile või failile juurdepääsul küsitakse parooli: Põhiline AuthType # Sisestage tekst, mis kuvatakse vormi päises: AuthName "Identifitseeri ennast" # Määrake parooli sisaldava faili tee: AuthUserFile "/home/site/.htpasswd" # Määrake, et failile wp-login.php juurde pääsedes peate sisestama parooli: Nõua kehtivat kasutajat # Keelake juurdepääs .htpasswd-failile kolmandatele osapooltele:< Files . htpasswd>käsk luba, keela keela kõigilt |
# Valige autoriseerimisskripti fail:
Samas oleks tore ka htaccessi enda turvalisuse eest hoolitseda. Rangelt võttes tuleks selline direktiiv kirjutada peamistes hostimisseadetes, kuid mõne teenusepakkuja ettevaatamatust arvesse võttes peaksite olema ohutu:
"Logi sisse" asemel asendame soovitud nime. Jääb üle parool ise genereerida ja ka krüpteerida, sest selliste andmete selge tekstina salvestamine on taskukohane luksus. Selleks on palju teenuseid, kuid parem on vajalik skript ise kirjutada. Seda tehakse järgmiselt.
1) Loo märkmikus .php fail, näiteks crypt.php
2) Sisestage sinna kood, asendades sõna "Parool" asemel enda väljamõeldud parooliga:
3) Salvestage fail ja laadige see juurkataloogi üles
4) Järgige linki site_name.ru/crypt.php – ekraanile ilmub parooliräsi
5) Salvestage see väärtus .htpasswd faili ja laadige see juurkataloogi üles ja kustutage crypt.php
Viimane lihv on veebiressursside kataloogi sisu vaatamise keeld. Piisab, kui lisada htaccessile üks rida:
| Valikud Kõik – indeksid |
Valikud Kõik indeksid
Seda tehakse selleks, et häkkerid ei saaks täpselt teada, millised failid projekti kataloogides on. Paljude hostide puhul on see käsk juba serveri seadetes, kuid kui see punkt tähelepanuta jääb, peaksite selle ise kirjutama.
8. Installige captcha
Captcha kasutamine katkestab, kui mitte kõik, siis vähemalt enamiku brute force robotitest, kuid samal ajal. WordPressi saidikaitse pistikprogrammide kataloog pakub palju võimalusi. Lisaks Google'i patenteeritud lahenduse ühendamisele pakub suurt huvi segatüüpi (graafika ja tekst) Captcha by BestWebSoft, mis põhineb matemaatilistel tehtetel. Sõltumatus teenustest, nähtavus ja vastuvõetav keerukusaste muudavad mooduli üheks parimaks.
Seadistamine pole eriti probleem. Vahekaart „Basic” võimaldab valida, kus captcha kuvada, samuti määrata pealkirja ja märgi, millega nõutud väljad märgistada.
Jaotis "Täpsemalt" annab võimaluse luua kohandatud veateateid, samuti aktiveerida täiendavaid pildipakette, et muuta robotite elu veelgi keerulisemaks.
Veel üks kasulik funktsioon on sisseehitatud valge loend IP-aadressidest, mille puhul captcha-d ei kuvata.
Pistikprogrammi installimise ja aktiveerimise tulemusena ilmub autoriseerimislehele vorm:
9. Muutke administraatori aadressi
Rääkides WordPressi saidi kaitsmisest, tasub mainida radikaalsemat, aga ka keerulisemat viisi - autoriseerimislehe URL-i muutmist skripti tasemel. Protseduur viiakse läbi mitmes etapis:
1. Nimetage fail wp-login.php ümber. Kasutage ingliskeelsete väiketähtede, numbrite ja sidekriipsude juhuslikku järjestust. Näiteks: abc-123.php
2. Leidke saadud failist kõik wp-login.php mainimised ja asendage need uue nimega.
3. Saidi korrektseks töötamiseks tuleb asendada ka järgmistes failides: 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, minu -saidid.php, schema.php, ru_RU.po
Pärast neid manipuleerimisi asub administraatori paneel aadressil site/abc-123.php. Juurdepääs uuele failile peaks olema piiratud ja kaitstud parooliga, nagu eespool kirjeldatud. Lisaks saate potentsiaalseid häkkereid petta, luues võltsitud wp-login.php faili ja määrates sellele ka parooli.
Veelgi lihtsam variant on kasutada lisandmoodulit "Nimeta ümber wp-login.php". Pärast saidikaitse pistikprogrammi installimist ilmub menüüsse "Seaded" -> "Püsilingid" uus väli:
10. Määrake administraatori IP
Täiendavat turvalisust saab pakkuda, kui teil on staatiline IP-aadress. Kui keelate juurdepääsu saidile wp-login.php mis tahes muust arvutist peale enda oma, muudate häkkerite elu palju raskemaks:
| < Files wp- login. php>käsk keelata, luba keelata kõigilt luba alates 127.0.0.1, 127.0.02 # Eraldage oma IP-aadressid komaga |
11. Keela autoriseerimisvead
Paroolide jõhkralt sundimisel on ründajal väga kasulik teada, et sisestatud andmed osutusid valed. Sellised teated kuvatakse igal ebaõnnestunud sisselogimiskatsel ning WordPress annab ka teada, mis täpselt valesti sisestati, kas sisselogimine või parool. Nendest vabanemiseks lisage faili functions.php vaid üks rida:
| add_filter("login_errors" , create_function ("$a" , "return null;" ) ) ; |
add_filter("login_errors",create_function("$a", "return null;"));
Selleks valige administraatoripaneelil "Välimus" -\u003e "Redaktor" -\u003e "Teema funktsioonid". Kood tuleb kirjutada avasildi järele.
12. Kasutage turvalist ühendust.
Liikluse krüptimiseks kasutaja arvuti ja veebiserveri vahel on https-protokoll, mille kasutamine välistab oluliste andmete, meie puhul identifitseerimisandmete pealtkuulamise võimaluse. Selle aktiveerimiseks peate esmalt ostma SSL-sertifikaadi, mis täidab korraga kahte funktsiooni: veebiressursi autentimine ja edastatava teabe krüpteerimine. Saate selle hankida spetsialiseeritud keskustes või mitmetes domeeninimede registripidajates. Mitteärilistel eesmärkidel piisab tasuta algtaseme sertifikaadi hankimisest (sellist pakub ettevõte www.startssl.com). Mis puutub installiprotsessi, siis reeglina on seda üksikasjalikult kirjeldatud hosti abi jaotises.
Pärast SSL-sertifikaadi hankimist peate konfigureerima veebiressursi administratiivse osa ümbersuunamise turvalisele ühendusele. WordPressi puhul tehakse seda järgmise konstruktsiooni abil:
| < IfModule mod_rewrite. c>Valikud + FollowSymlinks RewriteEngine sees RewriteCond % ( HTTPS) = väljas RewriteCond % ( REQUEST_URI) = / wp-login. php RewriteRule (.* ) https: |
Samuti saate sundida SSL-sertifikaate kasutama mootori tasemel. Selleks ava fail wp-config.php ja lisa pärast
| define("FORCE_SSL_ADMIN" , true ) ; |
define("FORCE_SSL_ADMIN", true);
Lisaks saate määrata globaalse ümbersuunamise http-lt https-le. Uute saitide jaoks on see lähenemisviis optimaalne, kuna Google julgustab kaitstud projekte, andes neile otsingutulemustes teatud prioriteedi.
| < IfModule mod_rewrite. c>Options + FollowSymlinks RewriteEngine on RewriteCond % ( HTTPS) = off RewriteRule ^(.* ) $ https: //%(HTTP_HOST)%(REQUEST_URI) |
13. Blokeeri sissetungijad
Kui teatud IP-delt tuvastatakse kahtlane tegevus, tasub nende juurdepääs saidile blokeerida. Seda tehakse analoogselt eelmise meetodiga. Erinevus seisneb selles, et direktiivid on kirjutatud projekti kui terviku jaoks ja loetleme nende aadressid, keda soovime keelata:
Telli Luba, Keela luba kõigist Keela alates 127.0.0.1, 127.0.02 #Määra soovimatud IP-d
Meetod on usaldusväärne, kuid ebaefektiivne. Esiteks on vaja kuidagi tabada jõhkrate jõumeeste palved ja eraldada nad lugupeetud külastajatest. Teiseks, massiivse rünnaku korral ei saa te lihtsalt häkkerite ja robotite IP-sid käsitsi jälgida ega sisse juhtida. See meetod on hea ainult siis, kui administraatoril on usaldusväärne aadresside "must nimekiri".
Muudel juhtudel saate kasutada WordPressi saidi turvapluginat nimega WP Cerber. See lahendus on täiesti tasuta, pakkudes samas väga muljetavaldavat tööriistakomplekti, mis on loodud CMS-i häkkimise vältimiseks. Saate selle installida otse administraatoripaneelilt.
Vaikimisi pakutakse üsna mõistlikke parameetreid. Arusaamatuste vältimiseks tuleks aga katsete arvu suurendada 5-ni.
Kui muudate administraatori aadressi eelnevalt kirjeldatud viisil, tuleks märkida ruut "Blokeeri IP mis tahes wp-login.php päringul".
Nendel eesmärkidel saate kasutada oma WP Cerberi tööriista:
Saidikaitse pistikprogrammi "Citadel" režiim ei vaja ka täiendavat konfigureerimist. See on loodud projekti "säilitamiseks" massilise toore jõu rünnaku ajal. Parem on tühjendada ruut "Salvesta faili sisselogimiskatsed" - see aitab kõrvaldada serveri lisakoormuse.
Vahekaarti "Juurdepääsuloendid" kasutatakse IP-de musta ja valge loendi loomiseks (kui teil on staatiline aadress, lisage see kindlasti usaldusväärsete aadresside loendisse) ja jaotis "Tööriistad" võimaldab teil varem tehtud sätete importimiseks ja eksportimiseks. Need võimalused ei vaja aga eraldi kaalumist.
14. Teisaldage konfiguratsioonifail
Nagu ülalpool teada saime, salvestab wp-config.php selliseid olulisi andmeid nagu kasutajanimi ja parool MySQL-ile juurdepääsuks ning API võtmed. Järgmine samm näib olevat ilmne – WordPressi kaitsmine htaccessi kaudu failijuurdepääsupiiranguga:
| < Files wp- config. php>Telli luba, keela Keela kõigilt |
Siiski on usaldusväärsem meetod. WordPressil on väga huvitav funktsioon, millest vähesed teavad. Mootor võimaldab paigutada konfiguratsioonifaili ühe taseme võrra kõrgemale juurkataloogist..php saab teisaldada saidi kataloogi. Sellisel juhul muutub fail Interneti kaudu üldiselt kättesaamatuks, samas kui selles sisalduvat teavet loeb CMS endiselt.
15. Lisage VIITAJA tšekk
Meetod, mis on WordPressi rämpsposti eest kaitsmisel hästi töötanud, aitab ka siis, kui vastandub jõhkratele jõumeestele. Paroolide loendamine pole ju sugugi käsitsitöö: selleks kasutatakse spetsiaalseid programme. Seega, kui lubate sissetulevate päringute päise kontrollimise, saate tühja HTTP REFEERERiga katkestada robotid, mis "tulid eikusagilt".
| < IfModule mod_rewrite. c>RewriteEngine On RewriteCond % ( REQUEST_METHOD) POST RewriteCond % ( REQUEST_URI) . (wp-comments-post|wp-login)\. php* RewriteCond % ( HTTP_REFERER) !.* tekseo. su.* [ VÕI] RewriteCond % ( HTTP_USER_AGENT) ^$ RewriteRule (.* ) http: //%(REMOTE_ADDR)/$1 |
16. Turvaline XML-RPC
Alates versioonist 3.5 ei ole WordPressil enam võimalik XML-RPC kaugprotseduurikõne protokolli keelata. Põhimõtteliselt on seda vaja mobiilirakendustega suhtlemiseks, kuid mitte igaüks ei vaja sellist funktsionaalsust. Samal ajal kasutatakse xmlrpc.php-d aktiivselt DDoS-i rünnakuteks, olles kogu projekti Achilleuse kand.
Lisaks mõtlesid häkkerid toore jõu jaoks kasutada XML-RPC-d. Meetodi wp.getUsersBlogs kasutamine võimaldab teil mandaate sorteerida palju kiiremini kui administraatorivormi kaudu. Kuna paljud XML-RPC kõned nõuavad autoriseerimist, on sellised taotlused nagu:
| < methodCall> < methodName>wp. getUsersBlogs < params>< param>< value>< string>admin < param>< value>< string> 12345 |
paneb mootori teatama, kas läbitud kombinatsioon on kehtiv. Sellest nuhtlusest vabanemiseks peate protokolli täielikult keelama. Seda saate teha mitmel viisil.
1) Blokeerides juurdepääsu failile xmlrpc.php htaccessi kaudu
nõuda_once(ABSPATH . "wp-settings.php");
on vaja registreerida
funktsioon remove_x_pingback($headers) ( unset($headers["X-Pingback"]); return $headers; ) add_filter("wp_headers", "remove_x_pingback");
4) Control XML-RPC avaldamisplugina kasutamine, mis tagastab vastava suvandi jaotises "Seaded" -> "Kirjutamine":
Pange tähele: lisandmoodul keelab protokolli kohe pärast aktiveerimist ja seadetes saate selle lubada, märkides vastava linnukese.
17. Jälgige jõhkra jõu rünnakuid
Lõpetuseks tasub mainida huvitavat pistikprogrammi häkkimiskatsete logimiseks – Autentimine ja xmlrpc logikirjutaja. Kuigi WP Cerberil on sisseehitatud jälgimistööriistad, on see moodul siiski kasulik, eriti neile, kes vajavad ülalkirjeldatud protokolli võimalusi. AX LogWriter suudab jälgida jõhkrat jõudu läbi xmlrpc.php, tänu millele saate hinnata ohu astet ja selle võimaluste kasutamisest täielikult keeldumise otstarbekust. Lõpetuseks, neile, kes pole oma projekti turvalisusega üldse tegelenud, avab saidikaitse pistikprogramm nende silmad ülaltoodud meetmete olulisuse suhtes.
AX-i LogWriteri kasutamine on lihtne. Pärast installimist ilmub administraatori menüüsse vastav jaotis, kus saate teha kõik vajalikud muudatused:
Valige väljal „Vea tüüp” salvestamisviis. See toetab kirjutamist süsteemilogi, Apache serveri logi ja ka kohandatud faili loomise võimalust. Viimasel juhul saate selle jaoks kohandada ka nime (Custom Error Log Name) ja kataloogi (Custom Error Log Path). See avab süsteemiadministraatorile laiad võimalused – näiteks saab lahendust kasutada koos fail2baniga. Ärge unustage ka veerus Ajavöönd valida sobivat ajavööndit.
Kohandatud logi saab vaadata otse kohandatud logivaaturi lehel olevalt administraatoripaneelilt:
Kokku võtma:
Ülaltoodud meetodid aitavad märkimisväärselt suurendada teie ressursi turvalisust ja kaitsta seda jõhkra jõuga robotite, veebihuligaanide ja praktiseerivate skriptide eest. Kõik ülalkirjeldatu on aga vaid jäämäe tipp. Ründajate arsenalis on palju keerukamaid meetodeid. Ja järgmises artiklis räägime sellest, kuidas kaitsta end tõeliste häkkerite eest, kasutades erinevaid mootori- ja serveritarkvara turvaauke. Nagu selles materjalis, kaalutakse lisaks üldistele hügieenireeglitele ka CMS-i võtmeseadeid, koodi muutmise viise ja kõige asjakohasemaid pistikprogramme.
Rakenduste turvalisuse osas on oluline hoolitseda mitte ainult riistvara ja operatsioonisüsteemi, vaid ka turvaliste skriptide kirjutamise eest. Sellest artiklist saate teada, kuidas oma rakendust kaitsta ja muuta see vähem haavatavaks. Allpool on loetelu meetmetest, mis aitavad teil oma rakendust igasuguste rünnakute eest kaitsta.
- Sissetulevate andmete valideerimine
- Kaitse XSS-i rünnakute eest
- Kaitse CSRF-i rünnakute eest
- SQL-i süstimise ennetamine
- Failisüsteemi kaitse
- Seansi andmete kaitse
- Viga töötlemisel
- Kinnituskaitse
Sissetulevate andmete valideerimine
Rakendust kujundades peaksite püüdma seda kaitsta "halva" sisendi eest. Reegel, mida järgida, on umbes selline: "Ära kunagi usalda seda, mida kasutaja on sisestanud." Vaatamata asjaolule, et enamik kasutajaid ei kujuta endast ohtu, on alati võimalus, et keegi soovib teie saiti häkkida, kasutades vormide või aadressiriba kaudu sisestatud "halbasid" andmeid. Kui valid ja filtreerite alati sissetulevaid andmeid, on teil hea võimalus kirjutada turvaline rakendus.
Kontrollige alati oma andmeid PHP-skriptides. Kui kasutate andmete kinnitamiseks JavaScripti, saab ründaja selle igal ajal oma brauseris keelata. Sel juhul on teie taotlus ohus. Keegi ei ole JavaScripti valideerimise vastu, kuid hea kaitse tagamiseks peate PHP-skriptides andmeid üle kontrollima.
Kaitse XSS-i rünnakute eest
Saidiülene skriptimine ehk XSS-rünnak on rünnak, mis põhineb potentsiaalselt haavatavatele lehtedele koodi sisestamisel. Oht seisneb selles, et pahatahtlikku koodi võidakse sisestada vormide kaudu ja seejärel brauseris kuvada.
Oletame, et teie saidil on vorm kommentaaride sisestamiseks, mis kuvatakse kohe pärast lisamist. Ründaja saab sisestada JavaScripti koodi sisaldava kommentaari. Pärast vormi esitamist saadetakse andmed serverisse ja sisestatakse andmebaasi. Pärast seda hangitakse andmed andmebaasist välja ja HTML-lehel kuvatakse uus kommentaar koos manustatud JavaScripti koodiga. See võib kasutaja suunata mõnele pahatahtlikule lehele või andmepüügisaidile.
Rakenduste kaitsmiseks edastage sissetulevad andmed funktsiooni strip_tags() kaudu, mis eemaldab kõik olemasolevad sildid. Andmete kuvamisel brauseris kasutage funktsiooni htmlentities().
Kaitse CSRF-i rünnakute eest
Järgmine ründetüüp, mida me vaatleme, on CSRF-rünnak ehk saidiülese taotluse võltsimine. Ründaja kasutab erinevaid nippe, et saada konfidentsiaalset teavet või sooritada tehing ilma ohvri teadmata. See juhtub peamiselt halvasti kaitstud saitidel, kus äriloogika põhineb GET-päringute tööl.
Üldiselt on GET-i päringud idempotentsed. Idempotentsus tähendab antud kontekstis, et samale lehele pääseb juurde nii mitu korda kui soovitakse ilma kolmanda osapoole sekkumiseta. Seetõttu tuleks GET-päringuid kasutada ainult teabele juurdepääsuks, kuid mitte mingil juhul mitmesuguste tehingute tegemiseks.
Järgmine lihtne näide näitab, kuidas ebaturvaline sait võib sattuda CSRF-i rünnaku alla:
Oletame, et Bob soovib Alice'ile CSRF-i rünnakut sooritada. Ta genereeris spetsiaalse URL-aadressi ja saatis selle e-postiga Alice'ile:
Külastage minu saiti!
Kui Alice on saidil example.com volitatud ja järgib seda linki, kantakse tema kontolt 1000 dollarit Bobi kontole. Teise võimalusena võib Bob saata ka pildi ja panna src atribuudisse "halva" aadressi.
Brauser ei saa seda pilti kuvada, kuna seda pole olemas, kuid taotlus esitatakse ilma Alice'i teadmata ja osaluseta.
Seda tüüpi rünnakute vältimiseks kasutage POST-i päringuid ainult protsessidele, mis on mõeldud andmebaasi teabe muutmiseks. Ärge kasutage $_REQUEST . Kasutage GET-parameetrite töötlemiseks $_GET-i ja POST-parameetrite toomiseks $_POST-i.
Täiendava meetmena saate luua unikaalse märgi ja lisada selle igale POST-i päringule. Kui kasutaja logib sisse, saab genereerida ja seansile kirjutada juhusliku märgi. Kuna kasutajale kuvatakse kõik vormid, tuleb see märk kirjutada peidetud väljale. Rakenduse äriloogika peab pakkuma funktsionaalsust, mis kontrollib vormidelt tokenit ja seansi salvestatud luba.
SQL-i süstimise ennetamine
Andmebaasi päringute tegemiseks tuleks kasutada kaitstud päritolunimetust. Parameetritega päringute ja ettevalmistatud avaldiste abil saate SQL-i sisestamise ohu kõrvaldada.
Vaatame järgmist näidet:
Ülaltoodud koodis saadame preparaadi () meetodile päringu, mis sisaldab nimelisi parameetreid: :name ja :age . Seega on päring eelkoostatud andmete edasiseks asendamiseks. Kui kutsutakse meetod execute(), on päring täielikult moodustatud ja täidetud. Kui kasutate seda tehnikat, tühistatakse kõik ründaja katsed SQL-i süstida.
Failisüsteemi kaitse
Vastutustundliku arendajana peaksite alati kirjutama koodi, mis ei kahjusta teie failisüsteemi. Vaatame koodi, mis saadab faili allalaadimiseks sõltuvalt kasutaja esitatud andmetest.
See skript on väga ohtlik, kuna tänu sellele pääsete ligi mis tahes kataloogile, mis on skriptiga failist saadaval: kataloogile, kus on seansid, süsteemikaustad ja palju muud.
Seansi andmete kaitse
Vaikimisi kirjutatakse kogu seansi teave ajutisse kataloogi. Kui kasutate jagatud hostimist, saab keegi teine peale teie kirjutada skripti ja lugeda seansi andmeid. Nii et hoiduge paroolide või krediitkaardinumbrite salvestamisest seansside ajal.
Kui teil on siiski vaja selliseid andmeid seansis salvestada, on krüptimine parim meede. See ei lahenda probleemi täielikult, kuna krüptitud andmed ei ole 100% turvalised, kuid salvestatud teave on loetamatu. Samuti peaksite kaaluma seansiandmete salvestamist mujale, näiteks andmebaasi. PHP-l on spetsiaalne meetod session_set_save_handler(), mis võimaldab salvestada seansiandmeid omal moel.
Alates PHP 5.4-st saate SessionHandlerInterface tüüpi objekti edastada käsule session_set_save_handler() .
Viga töötlemisel
Rakenduse arendamise käigus tasub tähelepanu pöörata kõikvõimalikele ettetulevatele vigadele, need tuleb aga lõppkasutajate eest varjata. Kui kasutajatele kuvatakse vigu, muudab see teie saidi haavatavaks. Seega oleks parim lahendus sihtserveri ja arendusserveri erinev konfiguratsioon.
Avalikus serveris peate keelama sellised suvandid nagu display_errors ja display_start_up_errors , kuid sellised valikud nagu error_reporting ja log_errors peavad olema lubatud, et kõik kasutajate ilmnenud vead logitaks.
Saate kasutada ka set_error_handler, et määrata oma veakäsitleja. Siiski võib siin esineda piiranguid, kuna algne töötleja on PHP algmehhanismist madalam. E_CORE_ERROR , E_STRICT või E_COMPILER_ERROR vigu ei saa konkreetse töötlejaga samasse faili püüda. Pealegi ei saa tabada ka tõrkeid, mis võivad esineda käitlejas endas.
Elegantsemaks erandite püüdmiseks tuleks potentsiaalselt ohtlik kood asetada proovi/püüdmise plokki. Kõik loomulikud erandid peavad olema erandi klasside või alamklasside objektid. Kui tehti erandeid, saab neid käsitleda try/catch plokis.
Kinnituskaitse
Sageli laaditakse PHP-skriptides muid faile, näiteks andmebaasiga ühenduse loomine ja paljud teised. Mõned arendajad annavad neile failidele laiendi .inc. PHP vaikimisi selliseid faile ei sõeluta. Kui pääsete neile juurde otse sellel aadressil, näeb kasutaja selle faili teksti. Kui häkkeril õnnestub pääseda ligi failile, mis salvestab andmeühenduse andmebaasiga, siis hiljem pääseb ta ligi kõikidele sinu rakenduses olevatele andmetele. Seega kasutage üleslaaditud failide jaoks alati laiendit .php ja salvestage need kohtadesse, kus kasutajal pole otsest juurdepääsu.
Tulemus
Kui järgite neid 8 reeglit, suurendab see oluliselt teie rakenduse vastupidavust erinevatele rünnakutele. Ärge usaldage kasutajate sisestatud andmeid, kaitske oma faile ja andmebaasi.
Mõelgem, mis on häkker? Häkker ei ole kreeker! Inimesed ajavad need mõisted sageli segamini. Häkker on ennekõike ebatavalise mõtlemisega inimene ja see on tema tugevus, kui nii võib öelda.
Häkkerile edukaks tõrjumiseks tuleb õppida ka kastist väljas mõtlema. Nagu öeldakse, kiil lüüakse kiiluga välja.
Täna pakun teile väga ebatavalist viisi, kuidas end php include rünnakute eest kaitsta. Kindlasti ei sobi see kõigile. Ja ausalt öeldes kaitseb see mitte rünnaku enda, vaid selle avastamise eest. Huvitatud?
Kuidas kaasatust otsida...
Alustuseks mõistame, kuidas täpselt ründaja haavatavust avastada püüab.
See näeb välja selline. Ründaja muudab kõiki sissetulevaid parameetreid ükshaaval, eeldades, et nende parameetrite andmed satuvad kaasamisfunktsiooni. Noh, või kui see lihtsal viisil proovib faile "kaasata". Ja selleks, et teha kindlaks, kas haavatavus on või mitte, peab ta sihtsüsteemi lisama mingi faili (see oli vihje - haavatavus on, ei - haavatavust pole).
Loomulikult, kui ründaja tegutseb väljastpoolt, ei tea ta kataloogide ja failide asukoha struktuuri ega saa lisada ühtegi faili, kuna ta ei tea selleni jõudmise teed. Kuid on faile, mis on alati süsteemis olemas ja millele on alati lugemisõigused. Linuxi puhul on see /etc/passwd ja Windowsi puhul olgu see C:\boot.ini. Kuid muide, Windows pakub meile vähe huvi, nii et edaspidi räägime passwd-st
/etc/passwd
Tõenäoliselt leidsite oma logides rohkem vormi kirjeid:
Toiming=../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
Kui jah, siis teate, et nad üritasid teie saidilt leida php-i (või suvaliste failide lugemise võimalust, kuid meid see praegu ei huvita). Seega, kui mõnda teie parameetrit ei käsitleta õigesti ja see jõuab funktsiooni sisaldama (), siis oleks kaasatud fail /etc/passwd, selle sisu tõlgendataks php-skriptina ja kuna see ei sisalda php koodisilte, siis kuvatakse see brauseris muutmata kujul. See toimiks "markerina", et kreekeril oleks haavatavus.
Miks ma seda kirjutan, et kaasade otsimisel püüab ründaja kindlasti (garanteerin, et 90% juhtudest) faili kaasata /etc/passwd.
Kaitske ennast, söör!
Võib-olla mõtlete nüüd järgmisele: "Kas ta soovib pakkuda tavalist WAF-i ja filtreerida pakette, kui neis on /etc/passwd?". Ei. See on standardne viis. See on näide sellest, kuidas tavaline inimene mõtleb.
Näitame veidi kujutlusvõimet. Miks me ei lisa passwd-faili sisule php-koodi? Ja kui äkki ründajal õnnestub see kaasata, käivitatakse meie php-kood. (Kas see on teie arvates jama? - vaadake järeldust)
Kuna me teame, et ainuke, kes arvab selle faili kaasata, on häkker, peaks meie php kood ta keelama ning meie süsteemi edasise häkkimise vältimiseks blokeerima haavatav fail ja soovitavalt teavitama juhtunust administraatorit. .
Aga kuidas lisada faili /etc/passwd php-koodi, kuna selle süntaks on rangelt reguleeritud? Igal kasutajal on "kommentaari" väli - kasutaja kirjeldus, sinna saab sisestada kõike, mis sulle meeldib (välja arvatud muidugi koolon). Seetõttu võtame ja lisame süsteemi kasutaja koos meile vajaliku kommentaariga. Pärast seda sisaldab /etc/passwd järgmist rida
root:x:0:0:Superkasutaja:/:
deemon:*:1:5::/:/sbin/sh
bin:*:2:2::/usr/bin:/sbin/sh
sys:*:3:3::/:
adm:*:4:4::/var/adm:/sbin/sh
turvakasutaja:*:1001:1001::/:
Noh, ühendatud skriptis teeme juba vajalikke toiminguid - keelame kasutaja, blokeerime apellatsiooni, teavitame administraatorit.
Selle tulemusena saime omamoodi lõksu, mis võib teie saiti häkkimise eest kaitsta.
Järeldus
Jah, ma olen täiesti teadlik, et kõik ülalkirjeldatu tundub jama. Ja ma saan suurepäraselt aru, et keegi seda praktikas ei kasuta. Aga ma ei kirjutanud selleks. Kirjutasin selleks, et näidata näidet ebastandardsest lähenemisest kaitse valdkonnas.
Tänan tähelepanu eest =)
