Visi programmatūras produkti PHP skriptu aizsardzībai ir iedalīti divās kategorijās: tie, kuriem serverī ir jāinstalē papildu moduļi un kuri darbojas ar parasto tīmekļa serveru konfigurāciju. Pirmie ir uzticamāki drošības ziņā, jo pārvērš PHP skriptus no teksta formas īpašā binārā kodā, taču tiem ir nepieciešama piekļuve serverim ar administratora tiesībām. Pēdējie var strādāt gandrīz visos hostingos ar PHP atbalstu, ieskaitot bezmaksas, taču tos nav ļoti grūti uzlauzt. Avota kodu, kas neizmanto šifrēšanu vai saspiešanu, var iedalīt atsevišķā apakšgrupā.
Servera līmeņa aizsardzība:
Zend Encoder / Zend SafeGuard Suite ir vispopulārākā komerciālā aizsardzība, moduļi Zend atbalstam parasti tiek instalēti visā apmaksātajā mitināšanā. Zend nodrošina domēna un IP skriptēšanu, izmēģinājuma skripta laiku un jaudīgu neskaidrību. Tiek atbalstītas visas operētājsistēmas. Publiskajā domēnā Zend noņemšanas utilītprogrammām ir vairākas iespējas, tās visas ir modificētas PHP 4. un 5. versijas. Vecākās Zend versijas tiek noņemtas bez problēmām, pēdējās ir grūtības avota koda aptumšošanas dēļ.Jauna, aktīvi attīstās komercaizsardzība. Tas nodrošina mijiedarbību ar aizsargātiem skriptiem savu API līmenī; tiek atbalstītas Windows un Linux operētājsistēmas. Tā kā tas ir zems, tas netiek instalēts parastajā virtuālajā mitināšanā, taču lietotāji to var instalēt specializētos serveros. Nav publisko dekodētāju.
Komerciālā aizsardzība praktiski nav atrasta, tā nav instalēta virtuālajā mitināšanā. Ļauj iestatīt izmēģinājuma periodu skriptu darbībai ar datuma pārbaudi ārējos laika serveros, saistīt aizsargātos skriptus ar serveriem, IP adresi, tīkla kartes MAC adresi, un šie dati tiek izmantoti atšifrēšanai. Tiek atbalstītas visas operētājsistēmas. Nav publisko dekodētāju.
phpSHIELD. SourceGuardian PHP prototipam. Pēc abu izstrādātāju apvienošanās tas pārtrauca attīstīties kā neatkarīgs produkts. Galvenā funkcionalitāte ir tāda pati, nav publisko dekoderu.
ionCube PHP kodētājs. Otrs populārākais komerciālais skriptu aizsardzības produkts. Pēc Zend publisko dekoderu parādīšanās tas arvien vairāk tiek izmantots un instalēts dalītā mitināšanā. Ļauj šifrēt ne tikai skriptus, bet arī veidnes, xml-dokumentus, attēlus, bināros failus. Tas saista aizsargātus failus ar serveriem, ir spēcīgs obfuskators, tiek atbalstītas visas operētājsistēmas. Nav publisko dekoderu, taču dažos gadījumos to var noņemt deZender.
PHTML kodētājs. Reta komerciālā drošības sistēma, kas nodrošina šāda veida produktiem parasto funkcionalitāti, darbojas visās operētājsistēmās. Par atsevišķu samaksu varat iegādāties oriģinālos drošības kodus un modificēt tos atbilstoši savām vajadzībām. Nav publisko dekodētāju.
DWebEncoder. Eksotiska Windows aizsardzība, kas paredzēta skriptu prezentāciju un katalogu izveidei kompaktdiskos. Instalētajā formā tas ir kaut kas līdzīgs neatkarīgam tīmekļa serverim, kurā tiek izpildīti kodēti php skripti. Nav publisko dekodētāju.
PHP kompakts. Aizstāvība ir drīzāk teorētiska, nevis praktiska. Tas tika izstrādāts vienā no pašmāju forumiem, taču izskatās, ka tālāk par autora izlaidumiem tas netika sasniegts. Tomēr nav dekoderu, kā arī aizsargātu skriptu.
Atvērtā koda papildinājums senajiem php paātrinātājiem Turck MMCache un eAccelerator. Pārvērš skriptus par baitu kodu, lai palielinātu to izpildes ātrumu. Ir moduļu versijas operētājsistēmai Windows un Linux. Publisku dekoderu nav, bet, iespējams, projekta atvērtā pirmkoda kods kaut kā palīdzēs pētījumā.
Avota līmeņa aizsardzība:
PHP LockIt! ... Populāra komerciālā aizsardzība, tā ir ļoti izplatīta, galvenokārt ārvalstu izstrādātāju skriptos. Ļauj iestatīt izmēģinājuma periodu skriptu darbībai, saistīšanai ar domēniem un IP adresēm, saspiež skriptus, izmantojot standarta php rīkus (gzinflate). Vienīgā grūtā daļa ir labs obfuskators. Dažādās aizsardzības versijas atšķiras tikai ar izpakošanas moduļa modifikāciju. Viegli noņemams gan manuālajā, gan automātiskajā režīmā. Bez obfuskatora tas tiek noņemts tieši līdz avota kodam, ar obfuscatoru tas prasa papildu apstrādi.CNCkripts. Publiskā domēnā pat nav demonstrācijas versijas, analīze tika veikta, izmantojot aizsargātus skriptus. Šarnīru moduli nav grūti izpakot, aizsardzība balstās tikai uz labu avota koda aptumšošanu.
PHPCipher. Aizsardzība ir tiešsaistes pakalpojums. Vietnē tiek augšupielādēts arhīvs ar jūsu skriptiem, un jau aizsargātais tiek lejupielādēts atpakaļ. Maksas licence ļauj parakstīt aizsargātus skriptus ar saviem datiem un izmantot tos komerciāliem nolūkiem. Bezmaksas licence ļauj izmantot tikai personiskai lietošanai. Pati aizsardzība ir Zend aizsargāts php-modulis, kurš pieslēdzas aizsargātiem skriptiem.Pēc deZend aizsardzības modulis un visu nepieciešamo konstantu iegūšana no tā tiek pilnībā izņemts uz pirmkodu. Nav obfuskatora funkcijas.
ByteRun Protector PHP. Komerciāls produkts, atkarībā no licences veida, ļauj aizsargāt skriptus gan servera līmenī, gan avota koda līmenī. Servera aizsardzība ar standarta funkcijām, nekas īpašs. Skripta līmeņa aizsardzība tiek noņemta ļoti viegli automātiski un manuāli. Servera versijai nav publiska dekodētāja.
Aizsardzība ir ļoti populāra vietējo izstrādātāju vidū. Tas ir aizsardzības modulis, kas ir ļoti piepildīts ar tukšu kodu, kas ir savienots ar aizsargātiem skriptiem caur include. Dekodēšanas algoritms ir ļoti vienkāršs, tas nerada grūtības manuālā un automātiskā izņemšanā. Visos gadījumos tas tiek pilnībā noņemts avota kodā, nav obfuscator funkcijas. Īpašiem dekodēšanas gadījumiem ir nelielas funkcijas, taču tās šeit netiks aprakstītas.
CodeLock. Vēl viena populāra aizsardzība, lielisks analfabēta programmēšanas piemērs. Tā ir php lietojumprogramma, kas ļauj iekodēt gan pašus skriptus, gan to darba rezultātu pārlūkprogrammā, izmantojot javascript. Skriptus var aizsargāt ar paroli, taču viduvējas ieviešanas dēļ paroli ir viegli uzzināt pat nenoņemot eņģes aizsardzību. Aizsardzības modulis ir php skripts, kas piepildīts ar tukšu kodu, kas savienojas ar aizsargātiem skriptiem. Aizsardzības algoritms ir ļoti vienkāršs, tas tiek pilnībā noņemts avota kodā. Nav apmulsināšanas funkcijas.
TrueBug PHP Encoder, nesen TrueBug PHP Obfuscator & Encoder. Ļoti interesants protektors, ko izpētīt. Pirms versijas 1.0.2 tika izmantoti standarta php rīki gzip saspiešanai, kopš versijas 1.0.3 autori ir izstrādājuši savu saspiešanas algoritmu. Jaunais produkts TrueBug PHP Obfuscator & Encoder pievieno avota koda obfuscēšanas un optimizācijas funkciju. Vienīgais aizsardzības vājais punkts ir nemainīgais skripta dekodēšanas algoritms, taču pats algoritms mainās katrai aizsardzības versijai. Pēc parsēšanas aizsardzība tiek viegli noņemta tieši līdz avota kodam, protams, ar nosacījumu, ka nav izmantots obfuskators.
Zorex PHP CryptZ. Aizsardzība, tāpat kā CodeLock, ir php lietojumprogramma, tā darbībai nepieciešama MySQL datu bāze. Aizsardzības modulis ir spraudņa php skripts, kas šifrēts vairākos slāņos. Pēc analīzes algoritms tiek ļoti viegli noņemts tieši līdz avota kodam. Nav obfuskatora funkcijas.
Bezmaksas PHP kodētājs. Bezmaksas tiešsaistes pakalpojums php skriptu kodēšanai. Aizsardzības modulis ir spraudņa php-skripts, ko sedz Zend un kas ir jālejupielādē no vietnes.Pēc Zend noņemšanas un algoritma parsēšanas aizsardzību var viegli noņemt pilnībā no pirmkoda. Aizsardzības algoritms ir nemainīgs, nav obfuscator funkcijas.
Php skripts, primitīvs kodējums, standarta base64. Tas nav pelnījis lielāku uzmanību un praktiski neinteresē.
Mēs izveidojam savu reģistrācijas lapu vairākām vietnēm, nevis standarta wp-signup.php.
Tipiskā WordPress instalācijā reģistrācijas (pieteikšanās, paroles atiestatīšanas) lapā tiek parādīts fails wp-login.php.
- /wp-login.php — autorizācija
- /wp-login.php?action=register — reģistrācija
- /wp-login.php?action=lostpassword — atiestatiet paroli
Vietnē wp-login.php ir atsevišķi nosacījumi vairākām vietnēm. Tātad, noklikšķinot uz saites /wp-login.php?action=register vairākās vietnēs, WordPress novirzīs uz /wp-signup.php lapu. Daudzās tēmās lapa neizskatās īpaši pievilcīga, tāpēc veidosim paši.
Galvenā tīkla vietne
Pēc noklusējuma WordPress atver reģistrācijas lapu (wp-signup.php) tīkla galvenajā domēnā (vietnē). Tomēr katrai tīkla vietnei varat izveidot atsevišķu reģistrācijas lapu, pat ja tām ir dažādas tēmas. Mēs izskatīsim gadījumu, kad visām tīkla vietnēm ir sava reģistrācijas lapa, taču tiek izmantota viena un tā pati tēma un vietnes atšķiras tikai pēc valodas. Ja izmantojat dažādas tēmas, jums būs jāraksta vairāk koda.
Funkcijas.php?
Nē. Šķiet, ka šī faila nosaukums ir minēts katrā WordPress rakstā. Mūsu gadījumā, ņemot vērā to, ka reģistrācijas funkcionalitāte ir paredzēta vairākām vietnēm, ir lietderīgi to pārvietot uz MU spraudņiem, kas tiek ielādēti, atverot jebkuru vietni.
Liriska atkāpe
Ir vērts atzīmēt, ka MU spraudņi tiek ielādēti agrāk nekā parastie spraudņi un pirms WordPress kodola ir pilnībā ielādēts, tāpēc dažu funkciju izsaukšana var izraisīt fatālas kļūdas PHP. Šai "agrīnai" iekraušanai ir arī savas priekšrocības. Piemēram, jebkurā motīvā nevar pieķerties dažām darbībām, kas tiek aktivizētas pat pirms funkcijas.php faila ielādes no motīva. Piemērs tam ir darbības no Jetpack spraudņa formā jetpack_module_loaded_related-posts (related-posts - moduļa nosaukums), ar kuru palīdzību ir iespējams izsekot Jetpack moduļu darbībai. Šai darbībai no tēmas faila nav iespējams "pieķerties", jo darbība jau ir aktivizēta pirms tēmas ielādes - spraudņi tiek ielādēti pirms motīviem. Kodeksa lapā Darbības atsauce varat apskatīt vispārīgu WordPress ielādes secības attēlu.
Failu secība
MU spraudņi var saturēt neierobežotu skaitu failu un jebkuru struktūru, kas jums šķiet loģiska. Es pieturos pie kaut kā šāda hierarhijas:
| -mu-plugins | - | -load.php | - | - | -selena-network | - | - | - | -reģistrēšanās | - | - | - | - | -plugin.php | - | - | - | - | -... | - | - | - | -jetpack | - | - | - | - | -plugin.php
Visi mūsu tīklam nepieciešamie "spraudņi" ir savienoti failā load.php:
// Ielādēt tulkotājus visiem papildinājumiem load_muplugin_textdomain ("selena_network", "/ selena-network / languages /"); // Lai reģistrētos tīklā, nepieciešams WPMU_PLUGIN_DIR. "/selena-network/signup/plugin.php"; // Citiem spraudņiem // ir nepieciešams WPMU_PLUGIN_DIR ...
Spraudņu mapes tiek glabātas mapē selena-network, katrai no tām ir savs spraudnis.php, ko mēs iekļaujam mapē load.php. Tas sniedz jums elastību un iespēju ātri izslēgt un ieslēgt lietas.
Reģistrācijas lapas adrese
Lai norādītu reģistrācijas lapas adresi, tiek izmantots wp_signup_location filtrs. To var atrast failā wp-login.php, un tas ir atbildīgs par novirzīšanu uz wp-signup.php.
Case "register": if (is_multisite ()) (wp_redirect (apply_filters ("wp_signup_location", network_site_url ("wp-signup.php"))); iziet;
Pievienosim savu funkciju mu-plugins / selena-network / signup / plugin.php, kas atgriezīs pašreizējās vietnes reģistrācijas lapas adresi:
Funkcija selena_network_signup_page ($ url) (return home_url (). "/ Reģistrēšanās /";) add_filter ("wp_signup_location", "selena_network_signup_page", 99);
selena_network ir prefikss, ko savā vietnē izmantoju visu funkciju nosaukumos MU spraudņos, lai izvairītos no sadursmēm. Tas ir jāaizstāj ar savu unikālo prefiksu. Filtra prioritāte ir 99, jo daži spraudņi, piemēram, bbPress un BuddyPress, var pārrakstīt šo URL ar savu (MU spraudņi tiek ielādēti agrāk nekā parastie spraudņi, skatiet iepriekš). Ņemiet vērā, ka tīkla_vietnes_url () vietā tiek izmantots mājas_url (), lai apmeklētājs būtu tajā pašā domēnā. Kā adresi var izmantot jebkuru URL.
Izveidojiet lapu
Tagad izveidosim lapu ar adresi site.com/signup/, izmantojot parasto saskarni, un bērna motīva mapē mūsu jaunās lapas veidne ir page-signup.php. Vārda "reģistrēšanās" vietā var izmantot unikālu ID.
Jaunajā veidnē ir jāizsauc funkcija selena_network_signup_main (), kas parādīs reģistrācijas veidlapu.
Jāņem vērā, ka viss process ar veidnēm nav nepieciešams, un tā vietā varat izveidot savu īskodu, kas izsauks arī funkciju selena_network_signup_main ().
wp-signup.php un wp-activate.php
Tagad sāksim izveidot funkciju, kas parādīs reģistrācijas veidlapu. Lai to izdarītu, kopējiet failus wp-signup.php un wp-activate.php no WordPress saknes uz mu-plugings / selena-network / signup / (un neaizmirstiet tos savienot iekšā mu-plugins / selena-network / pierakstīšanās / plugin.php) ... Turpmākās manipulācijas ar failiem ir ārkārtīgi grūti un laikietilpīgas aprakstīt, tāpēc tās būs jādara pašam. Es tikai aprakstīšu, kas tieši ir jādara, un publicēšu sava projekta avota failus:
- Faila sākumā noņemiet visus prasību, funkciju izsaukumus un citus kodus ārpus funkcijām.
- Pārdēvējiet visas funkcijas, pievienojot nosaukumiem unikālus prefiksus.
- Aptiniet wp-signup.php koda apakšējo daļu funkcijā selena_network_signup_main un pašā sākumā ierakstiet globālu $ active_signup; ...
- Nomainiet izkārtojumu ar savu pareizajās vietās.
Vietnē wp-activate.php jums jādara apmēram tas pats:
- Noņemiet visu kodu ārpus funkcijām, ietiniet izkārtojumu atsevišķā funkcijā.
- Ja nepieciešams, mainiet izkārtojumu.
Fails wp-activate.php ir atbildīgs par konta aktivizācijas lapu. Tāpat kā reģistrācijas lapai, tai ir jāizveido atsevišķa veidne, kurā izsaucat funkciju no faila wp-activate.php.
Nosūtām aktivizācijas vēstules
Reģistrācijas lapa apmeklētājam nosūta e-pastu ar saiti konta aktivizēšanai. Pēc noklusējuma to veic funkcija wpmu_signup_user_notification () no faila ms-functions.php. Tās funkcionalitāti var aizņemties savām funkcijām. Iemesls pārtraukt šīs funkcijas izmantošanu ir tāpēc, ka tā nosūta konta aktivizācijas saiti no wp-activate.php. Šo funkciju var "atspējot", izmantojot filtru wpmu_signup_user_notification, norādot uz to false (ja jūs to nedarīsiet, aktivizācijas vēstule tiks nosūtīta divas reizes, labi, patiesībā divi dažādi burti).
Funkcija armyofselenagomez_wpmu_signup_user_notification ($ lietotājs, $ lietotāja_e-pasts, $ atslēga, $ meta = masīvs ()) (// ... // Kods no funkcijas wpmu_signup_user_notification () wp_mail ($ user_email, wp_specialchars_decode ($ message_headers), $ ziņojums; return false;) add_filter ("wpmu_signup_user_notification", "armyofselenagomez_wpmu_signup_user_notification", 10, 4);
Rezultātā Selēnas tēmas reģistrācijas lapa izskatās daudz tīrāka un precīzāka.
Secinājums
Internetā ir daudz citu ne pārāk pareizu veidu, kā to pašu izdarīt - Apache redirects, AJAX formas, kas nedarbosies bez Java Script utt. sava vietne.
Ņemiet vērā, ka faili ir rūpīgi jārediģē un jācenšas daudz neatkāpties no oriģināla, lai turpmāk, ja WordPress mainīs wp-signup.php un wp-activate.php failus, būtu vieglāk tos salīdzināt, lai atrastu. izmaiņas.
Neaizmirstiet izpētīt visu iepriekš aprakstīto funkciju avota kodu, lai pilnībā saprastu, kas un kā notiek kodā.
Bonuss. Surogātpasta aizsardzība
Pat mazākās WordPress vietnes tiek bieži reģistrētas surogātpastam. Botu filtrēšanai var rakstīt bezgalīgus nosacījumus, bieži vien vairāk kā mēģinājums radīt mākslīgo intelektu 🙂 Daudzvietņu gadījumā man ļoti palīdzēja ierastā novirzīšana Apache, ar kuru atverot /wp-signup.php un /wp- acitvate.php, es prasīju 404 (es neesmu Apache konfigurācijas eksperts, tāpēc mani noteikumi var nebūt īsti pareizi).
RewriteEngine vietnē RewriteBase / RewriteRule ^ wp-signup \ .php - RewriteRule ^ wp-activate \ .php - # BEGIN WordPress # Neaiztieciet WordPress noteikumus pēc noklusējuma :) # ... # END WordPress
P. S. Es cenšos pēc iespējas detalizētāk aprakstīt dažas trešo personu lietas, jo, kad es sāku, dažreiz nebija neviena, kas daudzas lietas pamudinātu un izskaidrotu. Es arī uzskatu, ka šādi nelieli padomi par citiem materiāliem kādu pamudinās apgūt ko jaunu un paplašināt savu zināšanu lauku. RewriteRule ierakstos tiek izmantotas regulārās izteiksmes, tās nebūt nav sarežģītas, piemēram, rakstzīme ^ nozīmē rindas sākumu.
"Viņi lauž banku vietnes naudas dēļ, Pentagons spiegošanai, un mans projekts nevienam nav vajadzīgs," diemžēl tā domā lielākā daļa personīgo emuāru, interneta vizītkaršu, mazo uzņēmumu virtuālo biroju īpašnieku. Tikai daži cilvēki domā par to, kā aizsargāt vietni, bet velti. Mūsdienu realitātē hakeru acīs interesē absolūti jebkura platforma, neatkarīgi no veida vai popularitātes. Kam un kāpēc var būt nepieciešams jūsu resurss? Izdomāsim:
1. scriptkiddis palaidnības. Žargons attiecas uz topošajiem hakeriem, kuri sper pirmos soļus "tumšajā pusē". Iegādājoties vairākus rīkus vai uzrakstot pāris savas programmas, viņi vēlas pārbaudīt savu darbību pirmajā cietušajā, ar kuru viņi saskaras, un, kā likums, izvēlas vieglākos (vāji aizsargātos un neatjauninātos CMS) mērķus.
2. Melnais SEO. Joprojām tiek izmantoti negodīgu optimizētāju pakalpojumi - joprojām tiek praktizēta slēpto saišu ievietošana to projektu kodā, kuros ir vairāk nekā 10 TCI. Un, pirmkārt, resursi uz atvērtā pirmkoda dzinējiem (Joomla, Drupal, OpenCart un tā tālāk) tiek pakļauti uzbrukumiem.
3. Bottīkla veidošana. WordPress aizsardzība ar htaccess un spraudņiem ir aktuāla arī tāpēc, ka pilnīgi jebkuru resursu var izmantot, lai izveidotu zombiju tīklu, ko izmanto DDoS uzbrukumos, surogātpasta sūtīšanā utt.
4. Nodrošinājuma bojājumi. Visbeidzot, jums var netikt uzbrukts – galvenais mērķis būs hostings, un vietne kalpos tikai kā viena liela nodrošinātāja IT infrastruktūras ievainojamība. Protams, hakeriem viņa liktenis būs vienalga.
Datorurķēšanas sekas var būt visnepatīkamākās: satura vai visa resursa zudums, pesimizācija meklētājprogrammu rezultātos, auditorijas zaudēšana uzraksta “Vietne var apdraudēt datora vai mobilās ierīces drošību” dēļ un pat risks iesaistīties krimināllietā, ja uz jūsu tīmekļa resursa pamata ir veiktas pretlikumīgas darbības.
Tātad, mēs varam droši teikt, ka drošības problēmas skar absolūti ikvienu tīmekļa pārzini. Un, ja jūs tos neievērosit, visi centieni veicināt meklētājprogrammu (un tā ir nauda un dārgais laiks) var iet velti vienas nakts laikā. Problēma ir ļoti aktuāla, tāpēc es nolēmu sākt rakstu sēriju, kas veltīta tīkla apdraudējumiem un metodēm, kā ar tiem cīnīties. Populārā CMS sistēma – Wordpress tiks aplūkota trīs izdevumos.
WordPress vietnes nodrošināšanas metodes
Viena no primitīvākajām uzlaušanas metodēm ir brutālais spēks. Burtiski šis termins tiek tulkots kā “brutāls spēks”, un tas nozīmē pieteikšanās/paroles pāra iegūšanu, brutālā veidā uzskaitot iespējamās iespējas. Bieži vien brutālie forsētāji cenšas atvieglot savu dzīvi, izmantojot kļūdas dzinēja un servera iestatījumos – tas viņiem palīdz, piemēram, uzzināt konta nosaukumu, kas ievērojami samazina kombināciju skaitu. Runa ir par šo ievainojamību novēršanu, kā arī par nesankcionētas piekļuves mēģinājumu apkarošanas metodēm.
1. Izmantojiet unikālu administratora pieteikšanos
Pēc noklusējuma sistēma piedāvā izveidot lietotāju ar nosaukumu admin. Tomēr, lai aizsargātu savu WordPress vietni, vislabāk ir izmantot pieteikšanos, kas sastāv no nejaušu burtu un ciparu kopas. Tiešajā resursā administratora vārdu var mainīt bez problēmām, izmantojot vienu no divām metodēm:
Caur admin paneli. Dodieties uz sadaļu "Lietotāji", noklikšķiniet uz pogas "Pievienot jaunu" un izveidojiet kontu. Laukā “Loma” atlasiet “Administrators” un apstipriniet darbību. Pēc tam atkārtoti piesakieties jaunizveidotā konta vārdā, atgriezieties sadaļā "Lietotāji", izvēlieties "admin" un noklikšķiniet uz "Dzēst". Atvērtajā logā ievietojiet radio pogu pozīcijā "Saistīt visu saturu" un nolaižamajā sarakstā atlasiet jaunu administratoru un pēc tam noklikšķiniet uz "Apstiprināt dzēšanu".
... Izmantojot phpMyAdmin. To pašu procedūru ir daudz vieglāk veikt, izmantojot datu bāzes vadības paneli. Atlasiet vajadzīgo datu bāzi, atrodiet tabulu wp_users, atrodiet rindiņu "admin" (ID = 1), noklikšķiniet uz "Mainīt" un ievadiet vajadzīgo nosaukumu.
2. Izveidojiet īpašu publicēšanas kontu
Ja administrators ir "atstāts", tas nodrošinās papildu aizsardzību. Izveidojiet atsevišķu kontu rakstu ievietošanai un saistiet ar to visus iepriekš publicētos materiālus, kā aprakstīts 1. punktā. Pēc tam pievienojiet informāciju un sazinieties ar lasītājiem tikai no jauna konta.
3. Ievadiet spēcīgu paroli
Ievērojiet vispārpieņemtos ieteikumus: parolei ir jābūt vismaz 10 rakstzīmēm garai, tai jābūt unikālai un jāsastāv no nejaušas lielo un mazo burtu, ciparu un speciālo rakstzīmju secības.
Nekādā gadījumā nevajadzētu:
... izveidojiet paroli no jēgpilnām frāzēm
... izmantot jebkādus faktiskos datus (dzimšanas datums, pirmslaulības uzvārds, bankas konta numurs, kārtējais gads ...)
Tas novērsīs risku meklēt ieejas frāzi, izmantojot vārdnīcu, kā arī ievērojami palielinās laiks, kas nepieciešams brutāla spēka izmantošanai. Tātad, lai uzlauztu 10 rakstzīmju secību, kas sastāv tikai no mazajiem burtiem un cipariem (hki458p1fa), vienam datoram būs nepieciešamas 10 dienas datorā, bet, ja pievienosit lielos burtus un papildu rakstzīmes (Nv6 $ 3PZ ~ w1), šis periods palielināsies līdz 526 gadiem, garantējot gandrīz absolūtu WordPress aizsardzību. Šo paroļu izdomāšana un iegaumēšana ir diezgan sarežģīta, it īpaši, ja esat atbildīgs par vairākiem projektiem. Tāpēc to ģenerēšanai un uzglabāšanai labāk izmantot īpašus pārvaldniekus, piemēram, KeePassX, kas tiek izplatīts bez maksas, vai parastu testa dokumentu (labāk, ja tas ir iepakots arhīvā ar paroli).
4. Mainiet datu bāzes paroli
Iepriekš minētie noteikumi attiecas arī uz MySQL piekļuves koda drošību. Galu galā tieši tur ir viss saturs, kā arī administratora slepenās frāzes hash. Ja jau izmantojat vāju paroli, ir vērts to nomainīt. Tas tiek darīts šādi:
1. Atveriet savu phpMyAdmin vadības paneli
2. Atveriet cilni "Lietotāji" un atlasiet datu bāzes īpašnieku
3. Noklikšķiniet uz “Rediģēt privilēģijas”.
4. Atrodiet sleju "Mainīt paroli" un ievadiet jauno slepeno secību attiecīgajos laukos
5. Saglabājiet izmaiņas, noklikšķinot uz Labi.
Tagad atliek tikai rediģēt wp-config.php, pretējā gadījumā WordPress nevarēs izveidot savienojumu ar datu bāzi. Atrodiet definēto līniju ('DB_PASSWORD', "parole"); un vārda parole vietā ievadiet jauno paroli. Ņemiet vērā: tā kā rakstzīme (') tiek izmantota, lai norobežotu SQL komandas, to nevajadzētu izmantot kā ieejas frāzes daļu.
5. Regulāri atjauniniet paroles
Tie jāmaina vismaz reizi sešos mēnešos. Ārkārtas koda frāžu maiņa VIENMĒR jāveic pēc:
Datu nodošana autentifikācijai trešajām personām (programmētājiem, sistēmu administratoriem, optimizētājiem un citiem speciālistiem, pat ja viņi strādā ar mitināšanas uzņēmuma darbiniekiem)
... pieteikšanās tīmekļa resursā no kāda cita datora (ballītē, interneta kafejnīcā)
... atļauja no aprīkojuma, kas varētu būt apdraudēts (ar vīrusu inficēta mašīna)
6. Neaizmirstiet nomainīt sīkfailu slepenās atslēgas
Tie atrodas failā wp-config.php. Ir 8 no tiem:
| definēt ("AUTH_KEY", "unikālā atslēga"); definēt ("SECURE_AUTH_KEY", "unikālā atslēga"); definēt ("LOGGED_IN_KEY", "unikālā atslēga"); definēt ("NONCE_KEY", "unikālā atslēga"); definēt ("AUTH_SALT", "unikālā atslēga"); definēt ("SECURE_AUTH_SALT", "unikālā atslēga"); definēt ("LOGGED_IN_SALT", "unikālā atslēga"); definēt ("NONCE_SALT", "unikālā atslēga"); |
definēt ("AUTH_KEY", "unikālā atslēga"); definēt ("SECURE_AUTH_KEY", "unikālā atslēga"); definēt ("LOGGED_IN_KEY", "unikālā atslēga"); definēt ("NONCE_KEY", "unikālā atslēga"); definēt ("AUTH_SALT", "unikālā atslēga"); definēt ("SECURE_AUTH_SALT", "unikālā atslēga"); definēt ("LOGGED_IN_SALT", "unikālā atslēga"); definēt ("NONCE_SALT", "unikālā atslēga");
Kā jūs varētu nojaust pēc mainīgo nosaukumiem, atslēgas ir atbildīgas par sīkfailu šifrēšanu (plaši pazīstamais slengs: cepums - cepumi, sāls - sāls, mēs barojam hakerus ar sāļiem cepumiem), kas tiek izmantoti vietnes izveidošanai. "atcerieties" savu datoru pēc autorizācijas. Būtība ir tāda, ka pat tad, ja uzbrucējs savā rīcībā nonāks administratora paroles jaucējkodā, viņš nevarēs ģenerēt sīkfailus, kas nepieciešami, lai piekļūtu vietnei bez uzskaitītajām slepenajām frāzēm.
Lai uzlabotu drošību, noklusējuma rakstzīmju secības ir jāaizstāj ar unikālām uzreiz pēc CMS izvietošanas. Ērtības labad izstrādātāji ir izveidojuši tīmekļa ģeneratoru, kas atrodas www.api.wordpress.org/secret-key/1.1/salt/ - ievadot jūs redzēsiet taustiņus, un, atsvaidzinot lapu, kombinācijas tiek atjauninātas. .
7. Dubultā autorizācija administrācijas apgabalam
Htaccess ļauj vēl vairāk aizsargāt jūsu WordPress vietni, pievienojot servera līmeņa autentifikāciju. Kods izskatīsies šādi:
| < Files wp- login. php> # Mēs iestatām pamata autentifikācijas veidu - tas nozīmē, ka tad, kad jūs mēģināt# piekļūstot norādītajam direktorijam vai failam, tiks prasīts ievadīt paroli: Pamata AuthType # Ievadiet tekstu, kas tiks parādīts veidlapas galvenē: AuthName "Identificējiet sevi" # Norādiet ceļu uz failu, kurā ir ieejas frāze: AuthUserFile "/home/site/.htpasswd" # Mēs norādām, ka, piekļūstot failam wp-login.php, jums jāievada parole: Nepieciešams derīgs lietotājs # Liegt trešajām pusēm piekļuvi .htpasswd failam:< Files . htpasswd>pasūtīt atļaut, liegt liegt no visiem |
# Atlasiet autorizācijas skripta failu:
Tajā pašā laikā būtu jauki parūpēties par paša htaccess drošību. Stingri sakot, šāda direktīva ir jāizklāsta galvenajos mitināšanas iestatījumos, taču, ņemot vērā dažu pakalpojumu sniedzēju neuzmanību, jums vajadzētu rīkoties droši:
Nomainiet vajadzīgo vārdu, nevis "pieteikties". Atliek ģenerēt pašu paroli, kā arī to šifrēt, jo šādu datu glabāšana skaidrā tekstā ir nepieļaujama greznība. Šim nolūkam ir daudz pakalpojumu, taču labāk ir uzrakstīt nepieciešamo skriptu pats. Tas tiek darīts šādi:
1) Notepad izveidojiet .php failu, piemēram, crypt.php
2) Ievadiet tur esošo kodu, vārda "Parole" vietā aizstājot savu paroli:
3) Saglabājiet failu un augšupielādējiet to saknes direktorijā
4) Izpildiet saiti site_name.ru / crypt.php - ekrānā parādīsies paroles jaucējkods
5) Saglabājiet šo vērtību .htpasswd failā un augšupielādējiet to saknes direktorijā un crypt.php izdzēsiet.
Pēdējais pieskāriens ir aizliegums skatīt tīmekļa resursu direktorijas saturu. Pietiek ar vienu rindiņu pievienot htaccess:
| Opcijas Visas — indeksi |
Opcijas Visi — indeksi
Tas tiek darīts, lai hakeri nevarētu uzzināt, kuri faili atrodas projekta direktorijās. Daudzās mitināšanas vietnēs šī direktīva jau ir iekļauta servera iestatījumos, taču, ja šis punkts netiek ņemts vērā, jums tā jāreģistrē pašam.
8. Instalējiet captcha
Izmantojot captcha, varēsit nogriezt, ja ne visus, tad vismaz lielāko daļu brutālā spēka robotu un tajā pašā laikā. WordPress vietņu aizsardzības spraudņu direktorijs piedāvā daudzas iespējas. Papildus Google patentēta risinājuma pievienošanai lielu interesi rada jaukta (grafiskā un teksta) tipa Captcha by BestWebSoft, kura pamatā ir matemātiskas darbības. Pakalpojuma neatkarība, skaidrība un pieņemams sarežģītības līmenis padara moduli par vienu no labākajiem.
Pielāgošana nav liela problēma. Cilne "Pamata" ļauj izvēlēties, kur parādīt captcha, kā arī norādīt nosaukumu un simbolu, lai atzīmētu obligātos laukus.
Sadaļā "Papildu" ir iespēja izveidot savus kļūdu ziņojumus, kā arī aktivizēt papildu attēlu pakotnes, lai padarītu botu dzīvi vēl grūtāku.
Vēl viena noderīga funkcija ir iebūvētais baltais to IP adrešu saraksts, kurām captcha netiks rādīta.
Spraudņa instalēšanas un aktivizēšanas rezultāts būs veidlapas parādīšanās autorizācijas lapā:
9. Mainiet administratora adresi
Runājot par to, kā aizsargāt WordPress vietni, ir vērts pieminēt radikālāku, bet arī sarežģītāku veidu - pieteikšanās lapas URL mainīšanu skripta līmenī. Procedūra tiek veikta vairākos posmos:
1. Pārdēvējiet failu wp-login.php. Izmantojiet nejaušu mazo latīņu burtu, ciparu un domuzīmju secību. Piemēram: abc-123.php
2. Atrodiet visas atsauces uz wp-login.php iegūtajā failā un aizstājiet tās ar jauno nosaukumu.
3. Lai vietne darbotos pareizi, nomaiņa ir jāveic arī šādās versijās: wp-activate.php, general-template.php, post-template.php, functions.php, class-wp-customize-manager.php, general -template.php, saites-veidne.php, admin-bar.php, post.php, pluggable.php, ms-functions.php, canonical.php, functions.wp-scripts.php, wp-signup.php, mans -sites.php, schema.php, ru_RU.po
Pēc šīm manipulācijām administratora panelis atradīsies vietnē / abc-123.php. Piekļuve jaunajam failam ir jāierobežo un jāaizsargā ar paroli, kā aprakstīts iepriekš. Ir iespējams arī maldināt potenciālos hakerus, izveidojot viltotu wp-login.php failu un uzstādot tam arī paroli.
Vēl vienkāršāka iespēja ir izmantot papildinājumu "Pārdēvēt wp-login.php". Pēc spraudņa instalēšanas, lai aizsargātu vietni, izvēlnē "Iestatījumi" -> "Pastāvīgās saites" parādīsies jauns lauks:
10. Norādiet administratora IP
Ja jums ir statiska IP adrese, var nodrošināt papildu drošību. Ja liedzat piekļuvi failam wp-login.php no jebkura cita datora, kas nav jūsu dators, hakeru dzīve būs daudz grūtāka:
| < Files wp- login. php>rīkojums liegt, atļaut liegt no visiem atļaut no 127.0.0.1, 127.0.02 # Atdaliet IP adreses ar komatiem |
11. Atspējojiet autorizācijas kļūdas
Veicot brutālu piespiešanu paroles, uzbrucējam būs ļoti noderīgi zināt, ka ievadītie dati ir bijuši nepareizi. Šādi ziņojumi tiek parādīti katrā neveiksmīgā pieteikšanās mēģinājumā, un WordPress ziņo arī par to, kas ir ievadīts nepareizi, lietotājvārds vai parole. Lai no tiem atbrīvotos, failam functions.php jāpievieno tikai viena rindiņa:
| add_filter ("pieteikšanās_kļūdas", izveides_funkcija ("$ a", "return null;")); |
add_filter ("pieteikšanās_kļūdas", izveides_funkcija ("$ a", "return null;"));
Lai to izdarītu, administratora panelī atlasiet "Izskats" -> "Redaktors" -> "Tēmas funkcijas". Kods ir jāraksta aiz sākuma taga
12. Izmantojiet drošu savienojumu.
Lai šifrētu trafiku starp lietotāja datoru un tīmekļa serveri, ir https protokols, kura izmantošana izslēdz iespēju pārtvert svarīgus datus, mūsu gadījumā identifikācijas datus. Lai to aktivizētu, vispirms ir jāiegādājas SSL sertifikāts, kas vienlaikus veic divas funkcijas: tīmekļa resursa autentifikāciju un pārsūtītās informācijas šifrēšanu. To var iegūt specializētos centros vai no vairākiem domēna vārdu reģistratoriem. Nekomerciāliem nolūkiem pilnīgi pietiek ar bezmaksas sākuma līmeņa sertifikāta iegūšanu (to piedāvā uzņēmums www.startssl.com). Kas attiecas uz instalēšanas procesu, parasti tas ir detalizēti aprakstīts mitinātāja palīdzības sadaļā.
Saņemot SSL sertifikātu, jums ir jākonfigurē tīmekļa resursa administratīvās daļas novirzīšana uz drošu savienojumu. WordPress gadījumā tas tiek darīts, izmantojot šādu konstrukciju:
| < IfModule mod_rewrite. c>Opcijas + FollowSymlinks RewriteEngine On RewriteCond% (HTTPS) = izslēgts RewriteCond% (REQUEST_URI) = / wp- login. php RewriteRule (. *) https: |
Varat arī piespiest izmantot SSL sertifikātus dzinēja līmenī. Lai to izdarītu, atveriet failu wp-config.php un pievienojiet pēc tam
| definēt ("FORCE_SSL_ADMIN", patiess); |
definēt ("FORCE_SSL_ADMIN", patiess);
Turklāt varat iestatīt globālu novirzīšanu no http uz https. Šī pieeja ir optimāla jaunām vietnēm, jo Google veicina drošus projektus, piešķirot tiem zināmu prioritāti meklēšanas rezultātos.
| < IfModule mod_rewrite. c>Opcijas + FollowSymlinks RewriteEngine ir RewriteCond% (HTTPS) = izslēgts RewriteRule ^ (. *) $ Https: //% (HTTP_HOST)% (REQUEST_URI) |
13. Bloķēt iebrucējus
Ja tiek atklātas aizdomīgas darbības no noteiktiem IP, ir vērts bloķēt to piekļuvi vietnei. To veic pēc analoģijas ar iepriekšējo metodi. Atšķirība ir tāda, ka direktīvas ir rakstītas projektam kopumā, un mēs uzskaitām to personu adreses, kuras vēlamies aizliegt:
Pasūtiet Atļaut, Aizliegt Atļaut no visiem Aizliegt no 127.0.0.1, 127.0.02 # Norādiet nevēlamo IP
Metode ir uzticama, bet neefektīva. Pirmkārt, kaut kā jāfiksē brutālo forsēšanas dienestu pieprasījumi un jānodala no cienījamiem apmeklētājiem. Otrkārt, ar masveida uzbrukumu jūs vienkārši nevarēsit manuāli izsekot un vadīt hakeru un robotu IP. Šī metode ir piemērota tikai tad, ja administratoram ir uzticams adrešu melnais saraksts.
Pretējā gadījumā varat izmantot WordPress vietnes drošības spraudni ar nosaukumu WP Cerber. Šis risinājums ir absolūti bezmaksas, vienlaikus piedāvājot ļoti iespaidīgu rīku komplektu, kas paredzēts CMS uzlaušanas novēršanai. Varat to instalēt tieši no administratora paneļa.
Pēc noklusējuma tiek piedāvāti diezgan saprātīgi parametri. Tomēr mēģinājumu skaits jāpalielina līdz 5, lai izvairītos no pārpratumiem.
Ja maināt administratora adresi iepriekš aprakstītajā veidā, ir jāatzīmē izvēles rūtiņa pretī “Bloķēt IP jebkuram wp-login.php pieprasījumam”.
Šiem nolūkiem varat izmantot arī pašu WP Cerber rīku:
Citadeles vietnes aizsardzības spraudņa režīmam arī nav nepieciešama papildu konfigurācija. Tas ir paredzēts, lai "mothball" projektu masveida brutālu spēku uzbrukuma laikā. Labāk ir noņemt atzīmi no izvēles rūtiņas blakus “Ierakstīt mēģinājumus pieteikties failā” - tas palīdzēs novērst papildu slodzi serverī.
Cilne "Piekļuves saraksti" tiek izmantota, lai izveidotu "melno" un "balto" IP sarakstu (ja jums ir statiska adrese, noteikti pievienojiet to uzticamo sarakstam), un sadaļā "Rīki" varat importēt un eksportēt iepriekš veiktos iestatījumus. Tomēr šīs iespējas nav atsevišķi jāapsver.
14. Pārvietojiet konfigurācijas failu
Kā mēs noskaidrojām iepriekš, wp-config.php saglabā tādus kritiskus datus kā pieteikšanās vārds un parole, lai piekļūtu MySQL, kā arī API atslēgas. Šķiet, ka nākamais solis ir acīmredzams - WordPress aizsardzība, izmantojot htaccess, ierobežojot piekļuvi failam:
| < Files wp- config. php>Pavēli atļaut, liegt Aizliegt no visiem |
Tomēr ir arī uzticamāka metode. WordPress ir ļoti interesanta funkcija, par kuru zina tikai daži cilvēki. Dzinējs ļauj novietot konfigurācijas failu vienu līmeni virs saknes direktorija .. php var pārvietot uz vietnes direktoriju. Šajā gadījumā fails kļūs pilnīgi nepieejams caur internetu, savukārt tajā esošo informāciju CMS joprojām nolasīs.
15. Pievienojiet REFERER čeku
Labi pārbaudīta metode WordPress aizsardzībai no surogātpasta arī palīdzēs, saskaroties ar brutāla spēka uzbrukumiem. Galu galā brutāla paroļu piespiešana nekādā gadījumā nav roku darbs: šiem nolūkiem tiek izmantotas specializētas programmas. Tas nozīmē, ka, iespējojot ienākošo pieprasījumu galvenes pārbaudi, varat atslēgt robotus, kas nākuši no nekurienes, izmantojot tukšu HTTP REFERER:
| < IfModule mod_rewrite. c>RewriteEngine On RewriteCond% (REQUEST_METHOD) POST RewriteCond% (REQUEST_URI). (wp- komentāri- ziņa | wp- pieteikšanās) \. php * RewriteCond% (HTTP_REFERER)!. * tekseo. su. * [VAI] RewriteCond% (HTTP_USER_AGENT) ^ $ RewriteRule (. *) http: //% (REMOTE_ADDR) / $ 1 |
16. Aizsargājiet XML-RPC
Kopš versijas 3.5 no WordPress ir pazudusi iespēja atspējot XML-RPC attālās procedūras izsaukuma protokolu. Būtībā tas ir nepieciešams, lai mijiedarbotos ar mobilajām aplikācijām, taču ne visiem šāda funkcionalitāte ir nepieciešama. Tajā pašā laikā xmlrpc.php tiek aktīvi izmantots DDoS uzbrukumu veikšanai, kas ir visa projekta Ahileja papēdis.
Turklāt hakeri ir iedomājušies izmantot XML-RPC brutālam spēkam. Metodes wp.getUsersBlogs izmantošana ļauj atkārtot akreditācijas datus daudz ātrāk nekā izmantojot administratora veidlapu. Tā kā daudziem XML-RPC izsaukumiem ir nepieciešama autorizācija, šāds pieprasījums:
| < methodCall> < methodName>wp. getUsersBlogs < params>< param>< value>< string>admin < param>< value>< string> 12345 |
liks dzinējam paziņot, vai izvēlētā kombinācija ir pareiza. Lai atbrīvotos no šī posta, protokols ir pilnībā jāatspējo. To var izdarīt vairākos veidos:
1) Bloķējot piekļuvi failam xmlrpc.php, izmantojot htaccess
request_once (ABSPATH. "wp-settings.php");
nepieciešams reģistrēties
funkcija remove_x_pingback ($ headers) (unset ($ headers ["X-Pingback"]); return $ headers;) add_filter ("wp_headers", "remove_x_pingback");
4) Izmantojot Control XML-RPC publicēšanas spraudni, atgriežot atbilstošo opciju sadaļā Iestatījumi -> Rakstīšana:
Lūdzu, ņemiet vērā: papildinājums atspējo protokolu tūlīt pēc aktivizēšanas, un iestatījumos varat to iespējot, atzīmējot atbilstošo izvēles rūtiņu.
17. Uzraudzīt brutālu spēku uzbrukumus
Visbeidzot, ir vērts pieminēt interesantu spraudni uzlaušanas mēģinājumu reģistrēšanai - Autentifikācija un xmlrpc žurnālu rakstītājs. Lai gan tajā pašā WP Cerber ir iebūvēti uzraudzības rīki, šis modulis joprojām būs noderīgs, īpaši tiem, kam nepieciešamas iepriekš aprakstītā protokola iespējas. AX LogWriter spēj izsekot brutālu spēku, izmantojot xmlrpc.php, lai jūs varētu novērtēt apdraudējuma pakāpi un to, vai ir ieteicams pilnībā atteikties izmantot tā iespējas. Visbeidzot, tiem, kuri vispār nav bijuši iesaistīti sava projekta drošībā, spraudnis vietnes aizsardzībai atvērs acis uz uzskaitīto darbību nozīmi.
AX LogWriter lietošana ir vienkārša. Pēc instalēšanas administratora izvēlnē parādīsies atbilstošā sadaļa, kurā varēsiet veikt visas nepieciešamās izmaiņas:
Laukā “Kļūdas veids” atlasiet saglabāšanas metodi. Atbalsta rakstīšanu sistēmas žurnālā, Apache servera žurnālā, kā arī iespēju izveidot pielāgotu failu. Pēdējā gadījumā to var konfigurēt arī ar pielāgotu kļūdu žurnāla nosaukumu un pielāgotu kļūdu žurnāla ceļu. Tas paver plašas iespējas sistēmas administratoram – piemēram, risinājumu var izmantot kopā ar fail2ban. Tāpat neaizmirstiet slejā Laika josla atlasīt atbilstošo laika joslu.
Pielāgotu žurnālu var skatīt tieši no administratora paneļa lapā Custom Log Viewer:
Apkoposim:
Norādītās metodes palīdzēs ievērojami palielināt jūsu resursa drošību un aizsargāt to no robotiem-brute-forcing, tīkla huligāniem un praktizējošiem scriptkiddis. Tomēr viss iepriekš aprakstītais ir tikai aisberga redzamā daļa. Uzbrucēju arsenālā ir daudz izsmalcinātākas metodes. Un nākamajā rakstā mēs runāsim par to, kā pasargāt sevi no īstiem hakeriem, izmantojot dažādas dzinēja un servera programmatūras ievainojamības. Tāpat kā šajā materiālā, papildus vispārīgajiem "higiēnas noteikumiem" tiks apskatīti galvenie CMS iestatījumi, koda modifikācijas veidi, kā arī visatbilstošākie spraudņi.
Runājot par lietojumprogrammu drošību, ir svarīgi parūpēties ne tikai par aparatūru un operētājsistēmu, bet arī par drošu skriptu rakstīšanu. Šajā rakstā jūs uzzināsit, kā saglabāt savu lietojumprogrammu drošu un mazāk ievainojamu. Tālāk ir sniegts pasākumu saraksts, kas palīdzēs aizsargāt lietojumprogrammu no visa veida uzbrukumiem.
- Ienākošo datu validācija
- Aizsardzība pret XSS uzbrukumiem
- Aizsardzība pret CSRF uzbrukumiem
- SQL injekcijas novēršana
- Failu sistēmas aizsardzība
- Sesijas datu aizsardzība
- Kļūda apstrādē
- Iekļauto failu aizsardzība
Ienākošo datu validācija
Izstrādājot savu lietojumprogrammu, jums jācenšas to aizsargāt no "sliktiem" ienākošajiem datiem. Noteikums, kas jāievēro, ir apmēram šāds: "Nekad neticiet tam, ko lietotājs ir ievadījis." Lai gan lielākā daļa lietotāju nav drauds, vienmēr pastāv iespēja, ka kāds vēlas uzlauzt jūsu vietni, izmantojot veidlapās vai adreses joslā ievadītos “sliktos” datus. Ja jūs vienmēr apstiprināt un filtrējat ienākošos datus, jums ir labas izredzes uzrakstīt drošu lietojumprogrammu.
Vienmēr pārbaudiet savus datus PHP skriptos. Ja datu validēšanai izmantojat JavaScript, uzbrucējs jebkurā laikā var to atspējot savā pārlūkprogrammā. Šajā gadījumā jūsu pieteikums ir apdraudēts. Neviens nav pret JavaScript validāciju, taču, lai nodrošinātu labu aizsardzību, jums ir vēlreiz jāpārbauda dati PHP skriptos.
Aizsardzība pret XSS uzbrukumiem
Starpvietņu skriptēšana jeb XSS uzbrukums ir uzbrukums, kura pamatā ir koda ievadīšana potenciāli neaizsargātās lapās. Bīstamība ir tāda, ka ļaunprātīgu kodu var ievadīt, izmantojot veidlapas, un pēc tam parādīt pārlūkprogrammā.
Pieņemsim, ka jūsu vietnē ir veidlapa komentāru ievadīšanai, kas tiek parādīti uzreiz pēc pievienošanas. Uzbrucējs var ievadīt komentāru ar JavaScript kodu. Pēc veidlapas iesniegšanas dati tiek nosūtīti uz serveri un ievadīti datu bāzē. Pēc tam dati tiek izgūti no datu bāzes un HTML lapā tiek parādīts jaunais komentārs, ieskaitot iegulto JavaScript kodu. Tas var novirzīt lietotāju uz kādu ļaunprātīgu lapu vai pikšķerēšanas vietni.
Lai aizsargātu savas lietojumprogrammas, palaidiet ienākošos datus, izmantojot funkciju strip_tags (), kas noņems visus esošos tagus. Parādot datus pārlūkprogrammā, izmantojiet funkciju htmlentities ().
Aizsardzība pret CSRF uzbrukumiem
Nākamais uzbrukuma veids, ko apskatīsim, ir CSRF uzbrukums vai starpvietņu pieprasījuma viltošana. Uzbrucējs izmanto dažādus trikus, lai bez upura ziņas iegūtu konfidenciālu informāciju vai noslēgtu darījumu. Tas galvenokārt notiek slikti aizsargātās vietnēs, kur biznesa loģika balstās uz GET pieprasījumu darbu.
Vispārīgi runājot, GET pieprasījumi ir idempotenti. Idempotence šajā kontekstā nozīmē, ka vienai un tai pašai lapai var piekļūt neierobežotu skaitu reižu bez jebkādas ārējas iejaukšanās. Tāpēc GET pieprasījumus vajadzētu izmantot tikai, lai piekļūtu informācijai, bet nekādā gadījumā nedrīkst veikt dažāda veida darījumus.
Šis vienkāršais piemērs parāda, kā nenodrošināta vietne var tikt pakļauta CSRF uzbrukumam:
Pieņemsim, ka Bobs vēlas veikt CSRF uzbrukumu Alisei. Viņš izveidoja īpašu url adresi un nosūtīja to Alisei pa e-pastu:
Apmeklējiet manu vietni!
Ja Alise ir pilnvarota vietnē example.com un seko šai saitei, 1000 $ tiks pārskaitīti no viņas konta uz Boba kontu. Alternatīvi, Bobs var arī nosūtīt attēlu un atribūtā src aizpildīt "slikto" URL.
Pārlūkprogramma nevarēs parādīt šo attēlu, jo tas neeksistē, taču pieprasījums tiks veikts bez Alises ziņas un līdzdalības.
Lai novērstu šāda veida uzbrukumus, izmantojiet tikai POST pieprasījumus procesiem, kas paredzēti, lai mainītu informāciju datu bāzē. Neizmantojiet $ _REQUEST. Izmantojiet $ _GET, lai apstrādātu GET parametrus, un $ _POST, lai izgūtu POST parametrus.
Kā papildu pasākumu varat ģenerēt unikālu pilnvaru un pievienot to katram POST pieprasījumam. Kad lietotājs piesakās sistēmā, varat ģenerēt nejaušu marķieri un ierakstīt to sesijā. Tā kā lietotājam tiek parādītas visas veidlapas, šis marķieris ir jāieraksta slēptā laukā. Lietojumprogrammas biznesa loģikai ir jānodrošina funkcionalitāte, kas pārbaudīs marķieri no veidlapām un sesijā saglabāto marķieri.
SQL injekcijas novēršana
Jums vajadzētu izmantot ACVN, lai izpildītu vaicājumus datu bāzē. Izmantojot parametrizētus vaicājumus un sagatavotus paziņojumus, varat mazināt SQL injekcijas draudus.
Apskatīsim šādu piemēru:
Iepriekš minētajā kodā mēs nosūtām pieprasījumu sagatavošanas () metodei, iekļaujot nosauktos parametrus:: vārds un vecums. Tādējādi vaicājums ir iepriekš apkopots turpmākai datu aizstāšanai. Kad tiek izsaukta izpildes () metode, pieprasījums tiek pilnībā izveidots un izpildīts. Ja izmantojat šo paņēmienu, visi uzbrucēja mēģinājumi veikt SQL injekciju tiks anulēti.
Failu sistēmas aizsardzība
Kā atbildīgam izstrādātājam jums vienmēr ir jāraksta kods, kas neapdraud jūsu failu sistēmu. Apskatīsim kodu, kas nosūta failu lejupielādei atkarībā no lietotāja iesniegtajiem datiem.
Šis skripts ir ļoti bīstams, jo tas ļauj piekļūt jebkuram direktorijam, kas pieejams no faila ar skriptu: direktoriju ar sesijām, sistēmas mapēm un daudz ko citu.
Sesijas datu aizsardzība
Pēc noklusējuma visa sesijas informācija tiek ierakstīta pagaidu direktorijā. Ja izmantojat dalītu mitināšanu, kāds bez jums var rakstīt skriptu un lasīt sesijas datus. Tāpēc uzmanieties no paroļu vai kredītkaršu numuru glabāšanas sesijās.
Ja jums joprojām ir jāsaglabā šādi dati sesijā, vislabākais pasākums ir šifrēšana. Tas pilnībā neatrisina problēmu, jo šifrētie dati nav 100% droši, bet saglabātā informācija būs nelasāma. Tāpat jāņem vērā, ka sesijas datus var glabāt citur, piemēram, datu bāzē. PHP ir īpaša session_set_save_handler () metode, kas ļauj saglabāt sesijas datus savā veidā.
Kopš PHP 5.4 jūs varat nodot SessionHandlerInterface tipa objektu sesijas_set_save_handler ().
Kļūda apstrādē
Lietojumprogrammas izstrādes laikā ir vērts pievērst uzmanību visa veida kļūdām, kas var rasties, tomēr tās ir jāslēpj no gala lietotājiem. Ja lietotājiem tiek rādītas kļūdas, tas padara jūsu vietni neaizsargātu. Tādējādi labākais risinājums būtu atšķirīga mērķa servera un izstrādes servera konfigurācija.
Publiskajā serverī ir jāatspējo tādas opcijas kā display_errors un display_start_up_errors, taču tādām opcijām kā error_reporting un log_errors jābūt aktīvām, lai visas lietotāju konstatētās kļūdas tiktu reģistrētas.
Varat arī izmantot set_error_handler, lai definētu savu kļūdu apdarinātāju. Tomēr var būt ierobežojumi, jo vietējais apdarinātājs ir zemāks par vietējo PHP mehānismu. Kļūdas E_CORE_ERROR, E_STRICT vai E_COMPILER_ERROR nevar uztvert tajā pašā failā ar konkrētu apdarinātāju. Turklāt kļūdas, kas var rasties pašā apdarinātājā, arī nevar tikt uztvertas.
Lai iegūtu elegantāku izņēmumu tveršanas veidu, potenciāli bīstams kods ir jāievieto try / catch blokā. Visiem vietējiem izņēmumiem ir jābūt izņēmuma klašu vai apakšklašu objektiem. Ja tika izmesti izņēmumi, tad tos var apstrādāt try / catch blokā.
Iekļauto failu aizsardzība
Bieži vien PHP skriptos tiek ielādēti citi faili, piemēram, savienošanās ar datu bāzi un daudzi citi. Daži izstrādātāji šiem failiem piešķir paplašinājumu .inc. PHP pēc noklusējuma neparsē šādus failus. Ja uzrunāsit tos tieši, lietotājs varēs redzēt šī faila tekstu. Ja hakeram izdodas piekļūt failam, kurā glabājas datu savienojums ar datu bāzi, tad vēlāk viņš var piekļūt visiem jūsu aplikācijas datiem. Tāpēc augšupielādētajiem failiem vienmēr izmantojiet paplašinājumu .php un glabājiet tos vietās, kur lietotājiem nav tiešas piekļuves.
Rezultāts
Ja ievērosit uzskaitītos 8 noteikumus, tas ievērojami uzlabos jūsu lietojumprogrammas izturību pret dažāda veida uzbrukumiem. Neuzticieties lietotāju ievadītajiem datiem, aizsargājiet savus failus un datubāzi.
Padomāsim par to, kas ir hakeris? Hakeris nav krekeris! Cilvēki bieži jauc šos jēdzienus. Hakeris, pirmkārt, ir cilvēks ar ārprātīgu domāšanu, un tas, tā teikt, ir viņa spēks.
Lai veiksmīgi pretotos hakeram, jāiemācās arī domāt ārpus rāmjiem. Kā saka, ķīli izsit ar ķīli.
Šodien es jums piedāvāšu ļoti neparastu veidu, kā pasargāt sevi no uzbrukumiem, piemēram, php include. Protams, viņš nav piemērots visiem. Un ja godīgi viņš pasargā nevis no paša uzbrukuma, bet gan no tā atklāšanas. Ieinteresēja?
Kā atrast, ieskaitot...
Vispirms sapratīsim, kā tieši uzbrucējs mēģina atrast ievainojamību.
Tas izskatās šādi. Uzbrucējs modificē visus ienākošos parametrus pa vienam, pieņemot, ka šo parametru dati nokļūst iekļautajā funkcijā. Nu, vai ja vienkāršā veidā tas mēģina "pievienot" failus. Un, lai noteiktu, vai ir vai nav ievainojamība, viņam mērķa sistēmā jāiekļauj kāds fails (ja viņš zina - ir ievainojamība, nē - ievainojamības nav).
Protams, ja uzbrucējs rīkojas no ārpuses, viņš nezina direktoriju un failu atrašanās vietas struktūru un nevar pievienot nevienu failu, jo viņš nezinās ceļu uz to. Bet ir faili, kas vienmēr pastāv sistēmā un kuriem vienmēr ir lasīšanas atļaujas. Operētājsistēmā Linux tas ir / etc / passwd, bet operētājsistēmā Windows tas ir C: \ boot.ini. Bet, starp citu, Windows mūs maz interesē, tāpēc tālāk mēs runāsim par passwd
/ etc / passwd
Iespējams, savos žurnālos esat saskāries ar vairākiem veidlapas ierakstiem:
Darbība = .. / etc / passwd% 00
? darbība = .. / .. / etc / passwd% 00
? darbība = .. / .. / .. / etc / passwd% 00
? darbība = .. / .. / .. / .. / etc / passwd% 00
? darbība = .. / .. / .. / .. / .. / 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
Ja jā, tad jums jāzina, ka mēģinājāt atrast php include (nu, vai arī iespēju lasīt patvaļīgus failus, bet mūs tas tagad neinteresē). Tātad, ja kāds no jūsu parametriem netiek pareizi apstrādāts un nonāk funkcijā iekļaut (), tad tiktu pievienots / etc / passwd fails, tā saturs tiktu interpretēts kā php skripts, un, tā kā tajā nav php koda tagu, tas pārlūkprogrammā tiktu rādīts nemainīts. Tas kalpotu kā “marķieris”, lai uzbrucējam būtu ievainojamība.
Kāpēc es to rakstu, uz to, ka, meklējot include, uzbrucējs noteikti (garantēju, ka 90% gadījumu) mēģinās pievienot failu / etc / passwd.
Sargājiet sevi, kungs!
Varbūt jūs tagad domājat: "Vai viņš vēlas piedāvāt parastu WAF un filtrēt paketes, ja tajās ir / etc / passwd?" Nē. Šis ir standarta veids. Šis ir parasta cilvēka domāšanas piemērs.
Kļūsim nedaudz radošs. Kāpēc mēs vienkārši nepievienojam php kodu passwd faila saturam? Un, ja pēkšņi uzbrucējam izdosies viņu savienot, tiks izpildīts mūsu php kods. (Vai jūs to uzskatāt par muļķībām? - paskatieties uz secinājumu)
Tā kā mēs zinām, ka vienīgais, kurš uzminēs iekļaut šo failu, ir krekeris, mūsu php kodam tas ir jāaizliedz un, lai mūsu sistēma netiktu uzlauzta tālāk, bloķējiet ievainojamo failu un vēlams par to paziņot administratoram. par incidentu.
Bet kā pievienot php kodu / etc / passwd, jo tā sintakse ir stingri reglamentēta? Katram lietotājam ir lauks “komentārs” – lietotāja apraksts, tur var ievadīt jebko, ko vēlies (protams, izņemot kolu). Tāpēc mēs ņemam un pievienojam sistēmai lietotāju ar mums nepieciešamo komentāru. Pēc tam / etc / passwd būs šāda rinda
sakne: x: 0: 0: Superlietotājs: /:
dēmons: *: 1: 5 :: /: / sbin / sh
bin: *: 2: 2 :: / usr / bin: / sbin / sh
sys: *: 3: 3 :: /:
adm: *: 4: 4 :: / var / adm: / sbin / sh
drošības lietotājs: *: 1001: 1001::/:
Nu, spraudņa skriptā mēs jau veicam jums nepieciešamās darbības - banājiet lietotāju, bloķējiet pieprasījumu, paziņojiet administratoram.
Tā rezultātā mums ir sava veida slazds, kas var aizsargāt jūsu vietni no uzlaušanas.
Secinājums
Jā, es pilnībā apzinos, ka viss iepriekš rakstītais izskatās pēc muļķības. Un es lieliski saprotu, ka neviens to praktiski neizmantos. Bet tas nav tas, par ko es rakstīju. Es rakstīju, lai parādītu piemēru nestandarta pieejai aizsardzības jomā.
Paldies par uzmanību =)
