Zaštita PHP skripti od analize i modifikacije. Ne zaboravite promijeniti svoje tajne kolačića

Svi softverski proizvodi za zaštitu PHP skripti podijeljeni su u dvije kategorije: oni koji zahtijevaju instaliranje dodatnih modula na serveru i oni koji rade sa uobičajenom konfiguracijom web servera. Prvi su pouzdaniji u smislu sigurnosti, jer prevode PHP skripte iz tekstualnog oblika u poseban binarni kod, ali zahtijevaju pristup serveru s administratorskim pravima. Potonji mogu raditi na gotovo svim hostingima sa PHP podrškom, uključujući i besplatne, ali ih nije teško hakovati. U zasebnoj podgrupi možete odabrati izvorni kod koji ne koristi enkripciju ili kompresiju.

Zaštita na nivou servera:

Zend Encoder / Zend SafeGuard Suite - najpopularnija komercijalna zaštita, moduli za podršku Zend-a se obično instaliraju na svim plaćenim hostingima. Zend omogućava vezivanje skripti za domene i IP, postavljanje vremena probnih skripti i moćno prikrivanje. Podržani su svi operativni sistemi. Postoji nekoliko opcija za uklanjanje Zend-a u javnom domenu, sve su modifikovane PHP verzije 4 i 5. Stare verzije Zend-a se uklanjaju bez problema, u potonjoj postoje poteškoće zbog zamagljivanja izvornog koda.

Nova komercijalna zaštita koja se aktivno razvija. Na nivou izvornih API-ja, pruža interakciju sa zaštićenim skriptama; podržani su Windows i Linux operativni sistemi. Zbog male rasprostranjenosti, ne instalira se na običan virtuelni hosting, ali ga korisnici mogu instalirati na namenskim serverima. Ne postoje javni dekoderi.

Komercijalna zaštita se gotovo nikada ne nalazi, nije instalirana na virtuelnim hostingima. Omogućava vam da postavite probni period za skripte sa provjerom datuma u odnosu na eksterne servere tačnog vremena, vezujete zaštićene skripte za servere, ip-adresu, MAC-adresu mrežne kartice, a ovi podaci se koriste za dešifriranje. Podržani su svi operativni sistemi. Ne postoje javni dekoderi.

phpSHIELD. SourceGuardian za PHP prototip. Nakon spajanja dva programera, prestao je da se razvija kao samostalan proizvod. Glavna funkcionalnost je ista, nema javnih dekodera.

ionCube PHP Encoder. Drugi najpopularniji proizvod za zaštitu komercijalnih skripti. Nakon pojave javnih dekodera za Zend, on se sve više koristi i instalira na virtuelnim hostingima. Omogućava vam šifriranje ne samo skripti, već i predložaka, xml dokumenata, slika, binarnih datoteka. Veže zaštićene datoteke za servere, postoji moćan obfuskator, svi operativni sistemi su podržani. Ne postoje javni dekoderi, ali u nekim slučajevima ih uklanja deZender.

PHTML Encoder. Rijedak komercijalni sistem zaštite koji pruža uobičajenu funkcionalnost za proizvode ovog tipa, radi pod svim operativnim sistemima. Uz naknadu, možete kupiti izvorne zaštitne kodove i modificirati ih tako da odgovaraju vašim potrebama. Ne postoje javni dekoderi.

DWebEncoder . Egzotična zaštita za Windows, dizajnirana za kreiranje skriptiranih prezentacija i kataloga na CD-ovima. Kada je instaliran, to je nešto poput nezavisnog web servera na kojem se izvršavaju kodirane php skripte. Ne postoje javni dekoderi.

PHP Compact. Odbrana je više teoretska nego praktična. Razvijen je na jednom od domaćih foruma, ali čini se da stvar nije odmakla dalje od autorskih objava. Međutim, nema dekodera, kao ni zaštićenih skripti.

Dodatak otvorenog koda za stare php akceleratore Turck MMCache i eAccelerator. Prevodi skripte u bytecode kako bi se povećala brzina njihovog izvršavanja. Postoje verzije modula za Windows i Linux. Ne postoje javni dekoderi, ali možda će otvoreni izvor projekta nekako pomoći u proučavanju.

Zaštita na nivou izvornog koda:

PHP LockIt! . Popularna komercijalna zaštita, koja se vrlo često nalazi, uglavnom na skriptama stranih programera. Omogućava vam da postavite probni period za skripte, vezuje se za domene i ip adrese, komprimuje skripte standardnim php alatima (gzinflate). Jedina poteškoća je dobar obfuskator. Različite verzije zaštite razlikuju se samo u modifikaciji modula za raspakivanje. Lako se uklanja u ručnom i automatskom načinu rada. Bez obfuskatora, uklanja se tačno u izvorni kod, a sa obfuskatorom je potrebna dodatna obrada.

CNCrypto. Ne postoji čak ni demo verzija u javnom domenu, analiza je obavljena pomoću sigurnih skripti. Zglobni modul ne predstavlja poteškoće pri raspakiranju, zaštita počiva samo na dobrom zamagljivanju izvornog koda.

PHPCipher . Zaštita je online usluga. Arhiva sa vašim skriptama se postavlja na stranicu i već zaštićena se preuzima nazad. Plaćena licenca vam omogućava da svojim podacima potpisujete zaštićene skripte i koristite ih u komercijalne svrhe. Besplatna licenca dozvoljava samo ličnu upotrebu. Sama zaštita je php modul zaštićen od strane Zenda, koji se povezuje sa zaštićenim skriptovima.Nakon deZenda, zaštitni modul i dobijanje svih potrebnih konstanti iz njega se u potpunosti uklanja u izvorni kod. Ne postoji funkcija obfuskatora.

ByteRun Protector za PHP. Komercijalni proizvod, u zavisnosti od vrste licence, omogućava vam da zaštitite skripte i na nivou servera i na nivou izvornog koda. Zaštita servera sa standardnim karakteristikama, ništa posebno. Zaštita na nivou skripte se vrlo lako uklanja automatski i ručno. Ne postoji javni dekoder za verziju servera.

Zaštita vrlo popularna kod domaćih programera. To je zaštitni modul prepun praznih kodova, koji je preko uključivanja povezan sa zaštićenim skriptama. Algoritam dekodiranja je vrlo jednostavan, ne uzrokuje nikakve poteškoće u ručnom i automatskom uklanjanju. U svim slučajevima, potpuno se uklanja u izvorni kod, nema funkcije zamagljivanja. Postoje male karakteristike za posebne slučajeve dekodiranja, ali one ovdje neće biti opisane.

Code Lock . Još jedna popularna odbrana, odličan primjer nepismenog programiranja. To je php aplikacija koja vam omogućava da kodirate i same skripte i rezultat njihovog rada u pretraživaču koristeći javascript. Skripte se mogu zaštititi lozinkom, ali zbog osrednje implementacije, lozinku je lako saznati čak i bez uklanjanja preklopne zaštite. Zaštitni modul je php skripta puna praznog koda koji se povezuje sa zaštićenim skriptama. Algoritam zaštite je vrlo jednostavan, potpuno uklonjen u izvorni kod. Ne postoji funkcija zamagljivanja.

TrueBug PHP Encoder, novije TrueBug PHP Obfuscator & Encoder. Vrlo zanimljiv zaštitnik za istraživanje. Pre verzije 1.0.2, korišćeni su standardni php alati za gzip kompresiju, počevši od verzije 1.0.3, autori su razvili sopstveni algoritam kompresije. Novi proizvod TrueBug PHP Obfuscator & Encoder je dodao funkciju zamagljivanja i optimizacije izvornog koda. Jedina slaba točka zaštite je nepromijenjen algoritam za dekodiranje skripte, ali sam algoritam se mijenja za svaku verziju zaštite. Nakon parsiranja, zaštita se lako uklanja točno na izvorni kod, naravno, pod uvjetom da nije korišten obfuskator.

Zorex PHP CryptZ. Protection, kao i CodeLock, je php aplikacija kojoj je potrebna MySQL baza podataka da bi radila. Zaštitni modul - plug-in skript u php-u, šifriran u nekoliko slojeva. Nakon raščlanjivanja algoritma, vrlo lako se uklanja tačno u izvorni kod. Ne postoji funkcija obfuskatora.

Besplatni PHP Encoder. Besplatan online servis za kodiranje php skripti. Zaštitni modul je plug-in php skript prekriven Zend-om, koji se mora preuzeti sa stranice.Nakon uklanjanja Zend-a i raščlanjivanja algoritma, zaštita se lako uklanja u potpunosti u izvorni kod. Algoritam zaštite je nepromijenjen, nema funkcije obfuskatora.

PHP skripta, primitivno kodiranje, standardni base64. Ne zaslužuje više pažnje i nije od praktičnog interesa.

Kreirajmo vlastitu stranicu za registraciju na više lokacija umjesto standardne wp-signup.php.

U tipičnoj instalaciji WordPress-a, stranica za registraciju (prijava, poništavanje lozinke) se prikazuje u datoteci wp-login.php.

  • /wp-login.php - autorizacija
  • /wp-login.php?action=register - registracija
  • /wp-login.php?action=lostpassword - resetovanje lozinke

Postoje odvojeni uslovi za više lokacija u wp-login.php. Dakle, kada kliknete na /wp-login.php?action=register na više stranica, WordPress će preusmjeriti na /wp-signup.php stranicu. U mnogim temama stranica ne izgleda baš atraktivno, pa ćemo napraviti svoju.

Glavna stranica mreže

WordPress podrazumevano otvara stranicu za registraciju (wp-signup.php) na glavnom domenu (web sajtu) veba. Međutim, moguće je napraviti posebnu stranicu za registraciju za svaku stranicu u mreži, čak i ako imaju različite teme. Razmotrićemo slučaj kada sve stranice u mreži imaju svoju stranicu za registraciju, ali se koristi ista tema i stranice se razlikuju samo po jeziku. Ako se koriste različite teme, bit će potrebno više koda.

functions.php?

br. Čini se da se naziv ove datoteke spominje u svakom WordPress članku. U našem slučaju, uzimajući u obzir činjenicu da je funkcionalnost registracije dizajnirana za nekoliko stranica, ima smisla premjestiti je na MU dodatke koji se učitavaju kada se otvori bilo koja web lokacija.

Lirska digresija

Vrijedi napomenuti da se MU dodaci učitavaju prije normalnih dodataka i prije nego što se WordPress jezgro potpuno učita, tako da pozivanje nekih funkcija može dovesti do fatalnih grešaka u PHP-u. Ovo "rano" punjenje ima svoje prednosti. Recimo da se unutar bilo koje teme ne možete držati nekih radnji koje rade čak i prije nego što se datoteka functions.php učita iz teme. Primjer za to su akcije iz Jetpack dodatka oblika jetpack_module_loaded_related-posts (related-posts je naziv modula) pomoću kojih je moguće pratiti aktivnost modula u Jetpacku. Ova radnja se ne može "prikačiti" iz datoteke teme jer se akcija već pokrenula prije nego što se tema učita - dodaci se učitavaju prije tema. Možete pogledati opću sliku redoslijeda učitavanja WordPress-a na stranici Referenca za akciju u kodeksu.

Redoslijed datoteka

MU dodaci mogu sadržavati bilo koji broj datoteka i bilo koju strukturu koja vam se čini logičnom. Pratim hijerarhiju poput ove:

|-mu-plugins |-|-load.php |-|-|-selena-network |-|-|-|-signup |-|-|-|-|-plugin.php |-|-|-| -|-... |-|-|-|-jetpack |-|-|-|-|-plugin.php

U datoteci load.php povezani su svi potrebni "pluginovi" za našu mrežu:

// Učitaj prevoditelje za sve dodatke load_muplugin_textdomain("selena_network", "/selena-network/languages/"); // Mrežna registracija zahtijeva WPMU_PLUGIN_DIR . "/selena-network/signup/plugin.php"; // Drugi dodaci // zahtijevaju WPMU_PLUGIN_DIR ...

Fascikle dodataka se pohranjuju unutar selena-network foldera, svaka ima svoj plugin.php, koji uključujemo u load.php. Ovo daje fleksibilnost i mogućnost brzog onemogućavanja i omogućavanja određenih stvari.

URL stranice registracije

Filter wp_signup_location se koristi za specificiranje adrese stranice za prijavu. Može se naći unutar datoteke wp-login.php i odgovoran je za preusmjeravanje na wp-signup.php.

Slučaj "registar" : if (is_multisite()) ( wp_redirect(apply_filters("wp_signup_location", network_site_url("wp-signup.php"))); izlaz;

Dodajmo našu funkciju u mu-plugins/selena-network/signup/plugin.php , koja će dati adresu stranice za registraciju na trenutnoj stranici:

Funkcija selena_network_signup_page ($url) ( return home_url () . "/signup/"; ) add_filter ("wp_signup_location", "selena_network_signup_page", 99);

selena_network je prefiks koji koristim u nazivima svih funkcija unutar MU dodataka na mojoj web stranici kako bih izbjegao kolizije, treba ga zamijeniti vašim vlastitim jedinstvenim prefiksom. Dodajte prioritet filtera 99 jer neki dodaci kao što su bbPress i BuddyPress mogu prepisati ovu adresu svojom (MU dodaci se učitavaju ranije od običnih dodataka, pogledajte gore). Imajte na umu da se home_url() koristi umjesto network_site_url() da posjetitelj ostane na istoj domeni. Bilo koji URL može se koristiti kao adresa.

Kreiranje stranice

Sada kreirajmo stranicu sa adresom site.com/signup/ kroz uobičajeni interfejs, au folderu podređene teme, šablon za našu novu stranicu je page-signup.php . Umjesto riječi "prijava" možete koristiti jedinstveni ID.

Unutar novog predloška, ​​trebate pozvati funkciju selena_network_signup_main() koja će prikazati obrazac za prijavu.

Vrijedi napomenuti da je cijeli proces s predlošcima opcionalan i umjesto toga možete kreirati vlastiti kratki kod, koji će također pozvati funkciju selena_network_signup_main().

wp-signup.php i wp-activate.php

Sada kreirajmo funkciju koja će prikazati obrazac za registraciju. Da biste to učinili, kopirajte datoteke wp-signup.php i wp-activate.php iz korijena WordPress-a u mu-plugings/selena-network/signup/ (i ne zaboravite ih uključiti u mu-plugins/selena-network /signup/plugin.php) . Dalje manipulacije fajlovima su izuzetno teške i dugačke za opisivanje, tako da ćete ih morati sami obaviti. Samo ću opisati šta tačno treba da se uradi i objaviću izvorne fajlove mog projekta:

  1. Na početku datoteke uklonite sav zahtjev , pozive funkcija i drugi kod izvan funkcija.
  2. Preimenujte sve funkcije dodavanjem jedinstvenih prefiksa imenima.
  3. Umotajte donji dio koda wp-signup.php u funkciju selena_network_signup_main i napišite globalni $active_signup na samom početku; .
  4. Zamijenite izgled svojim na pravim mjestima.

Unutar wp-activate.php morate uraditi istu stvar:

  1. Uklonite sav kod izvan funkcija, umotajte izgled u posebnu funkciju.
  2. Promijenite izgled gdje je potrebno.

Datoteka wp-activate.php je odgovorna za stranicu za aktivaciju naloga. Kao i kod stranice za registraciju, za nju morate kreirati poseban predložak, unutar kojeg trebate pozvati funkciju iz datoteke wp-activate.php.

Slanje aktivacijskih emailova

Stranica za registraciju šalje e-mail posjetitelju s vezom za aktivaciju računa. Prema zadanim postavkama, ovo rješava funkcija wpmu_signup_user_notification() iz datoteke ms-functions.php. Njegova funkcionalnost se može posuditi za njegovu funkciju. Razlog zašto morate da prestanete da koristite ovu funkciju je taj što ona šalje link za aktivaciju naloga sa wp-activate.php. Ovu funkciju možete “isključiti” koristeći filter wpmu_signup_user_notification tako što ćete mu dati false (ako se to ne učini, pismo za aktivaciju će biti poslano dvaput, ok, zapravo dva različita pisma).

Funkcija armyofselenagomez_wpmu_signup_user_notification($user, $user_email, $key, $meta = array()) ( // ... // Kod iz wpmu_signup_user_notification() funkcija wp_mail($user_email, wp_specialchars_decode), $message_decode($sage_head) ; vrati false; ) add_filter("wpmu_signup_user_notification", "armyofselenagomez_wpmu_signup_user_notification", 10, 4);

Kao rezultat toga, stranica za registraciju u temi Selena postala je mnogo čišća i urednija.

Zaključak

Postoji mnogo drugih ne baš ispravnih načina na internetu kako to učiniti - Apache preusmjeravanja, AJAX forme koje neće raditi bez Java Script-a itd. moguće na mom sajtu.

Napominjem da treba pažljivo uređivati ​​fajlove i truditi se da ne odstupate previše od originalnih, kako bi ubuduće, ako WordPress promijeni datoteke wp-signup.php i wp-activate.php, bilo lakše upoređivati da pronađu promjene.

Ne zaboravite pogledati izvorni kod svih gore opisanih funkcija kako biste u potpunosti razumjeli šta se i kako događa unutar koda.

Bonus. Zaštita od spamera

Čak su i najmanje WordPress stranice često bombardirane registracijama neželjene pošte. Možete pisati beskonačne uslove za filtriranje botova, često više kao pokušaj stvaranja umjetne inteligencije 🙂 U slučaju multisite-a dosta mi je pomoglo uobičajeno preusmjeravanje u Apache-u, s kojim sam tražio da izdam 404 prilikom otvaranja /wp-signup.php i /wp-acitvate.php (ja nisam stručnjak za podešavanje Apache-a, tako da moja pravila možda nisu baš tačna).

RewriteEngine na RewriteBase / RewriteRule ^wp-signup\.php - RewriteRule ^wp-activate\.php - # POČNI WordPress # Zadana pravila WordPressa :) # ... # KRAJ WordPress

P.S. Trudim se da što detaljnije opišem neke stvari treće strane, jer kada sam počinjao, ponekad nije imao ko da podstakne i objasni mnoge stvari. Također vjerujem da će takvi mali savjeti o drugim materijalima nekoga potaknuti da nauči nešto novo i proširi svoje područje znanja. Unosi RewriteRule koriste regularne izraze, nisu nimalo komplikovani, na primjer, znak ^ označava početak reda.

„Web stranice banaka su razbijene radi novca, Pentagon je radi špijunaže, a moj projekat nikome ne treba“, nažalost, upravo je to ono što većina vlasnika ličnih blogova, online vizitkarti i virtuelnih predstavništava misle male kompanije. Samo rijetki razmišljaju o tome kako zaštititi stranicu, ali uzalud. U modernoj stvarnosti, apsolutno svaka web lokacija, bez obzira na vrstu ili popularnost, interesantna je u očima hakera. Kome bi mogao biti potreban vaš resurs i zašto? Hajde da shvatimo:
1. Šale scriptkiddis. Žargon se odnosi na hakere početnike koji prave prve korake na „tamnoj strani“. Nakon što su nabavili nekoliko alata ili su napisali nekoliko vlastitih programa, željni su testirati svoje performanse na prvoj žrtvi na koju naiđu, i po pravilu biraju najlakše (slabo zaštićene i neažurirane CMS) mete.
2. Black hat SEO. Usluge nepoštenih optimizatora su još uvijek u upotrebi - postavljanje skrivenih linkova u kodu projekata sa više od 10 TCI-a se još uvijek prakticira. I, prije svega, resursi na open source motorima (Joomla, Drupal, OpenCart i tako dalje) su pod napadom.
3. Izgradnja bot-neta. Zaštita WordPress-a pomoću htaccess-a i dodataka je također relevantna jer se apsolutno svaki resurs može koristiti za kreiranje zombi mreže koja se koristi tokom DDoS napada, slanja neželjene pošte itd.
4. Kolateralna šteta. Konačno, možda nećete biti napadnuti – hosting će biti glavni cilj, a stranica će služiti samo kao jedna velika ranjivost IT infrastrukture provajdera. Naravno, njegova sudbina će biti ravnodušna prema hakerima.

Posljedice hakovanja mogu biti najneugodnije: gubitak sadržaja, odnosno resursa u cjelini, pesimizacija u rezultatima pretraživača, gubitak publike zbog natpisa „Sajt može ugroziti sigurnost računara ili mobilnog uređaja“ i čak i rizik da postanete optuženi u krivičnom predmetu ako su počinjene nezakonite radnje na osnovu vašeg web resursa.

Dakle, sa sigurnošću možemo reći da sigurnosni problemi pogađaju apsolutno svakog webmastera. A ako se zanemare, svi napori za promociju pretraživanja (a ovo je novac i dragocjeno vrijeme) mogu proći u nepovrat. Problem je vrlo relevantan, pa sam odlučio započeti seriju članaka o mrežnim prijetnjama i kako se nositi s njima. U tri broja biće razmatran popularni CMS sistem - WordPress.

WordPress metode zaštite stranice

Jedna od najprimitivnijih metoda hakovanja je gruba sila. Doslovno, termin je preveden kao „brute sile“ i znači dobijanje para login/lozinke kompletnim nabrajanjem mogućih opcija. Često brute-forceri pokušavaju olakšati svoj život iskorištavanjem grešaka u postavkama motora i servera - to im pomaže, na primjer, da saznaju naziv računa, što značajno smanjuje broj kombinacija. Riječ je o otklanjanju ovih ranjivosti, kao io metodama za suzbijanje pokušaja neovlaštenog pristupa.

1. Koristite jedinstvenu prijavu administratora

Podrazumevano, sistem od vas traži da kreirate korisnika pod imenom admin. Međutim, kako biste zaštitili svoju WordPress stranicu, najbolje je koristiti login koji se sastoji od skupa nasumičnih slova i brojeva. Na trenutnom resursu, ime administratora se može promijeniti bez ikakvih problema na jedan od dva načina:

Preko admina. Idite na odjeljak „Korisnici“, kliknite na dugme „Dodaj novo“ i kreirajte nalog. U polju "Uloga" odaberite "Administrator" i potvrdite operaciju. Zatim se prijavite u ime novokreiranog naloga, vratite se na odjeljak "Korisnici", odaberite "admin" i kliknite "Izbriši". U prozoru koji se otvori, postavite radio dugme na “Poveži sav sadržaj” i sa padajuće liste izaberite novog administratora, a zatim kliknite na “Potvrdi brisanje”.
. Koristeći phpMyAdmin. Mnogo je lakše provesti istu proceduru preko kontrolne table baze podataka. Odaberite potrebnu bazu podataka, pronađite tabelu wp_users, pronađite red “admin” (ID=1), kliknite na “Edit” i unesite željeno ime.

2. Kreirajte namenski nalog za objavljivanje

Ako administrator nije “sjajan”, to će pružiti dodatnu zaštitu. Napravite poseban nalog za objavljivanje članaka i povežite sve ranije objavljene materijale sa njim na način opisan u paragrafu 1. Zatim dodajte informacije i komunicirajte sa čitaocima samo sa novog naloga.

3. Postavite složenu lozinku

Slijedite opšte prihvaćene smjernice: Lozinke moraju imati najmanje 10 znakova, biti jedinstvene i sadržavati nasumični niz velikih i malih slova, brojeva i posebnih znakova.
Ni u kom slučaju ne bi trebalo da:
. sastavite lozinku od smislenih fraza
. koristiti sve činjenične podatke (datum rođenja, djevojačko prezime, broj bankovnog računa, tekuća godina...)
Ovo će eliminirati rizik od odabira pristupne fraze iz rječnika, a također će značajno povećati vrijeme potrebno za grubu silu. Dakle, razbijanje sekvence od 10 karaktera koja se sastoji samo od malih slova i brojeva (hki458p1fa) će trajati 10 dana mašinskog vremena za jedan računar, ali ako dodate velika slova i dodatne znakove (Nv6$3PZ~w1), ovaj period će se povećati do 526 godina, garantujući gotovo apsolutnu zaštitu za WordPress. Iznaći i zapamtiti takve lozinke je prilično teško, pogotovo ako nadgledate nekoliko projekata. Stoga je za njihovo generiranje i pohranjivanje bolje koristiti posebne menadžere, na primjer, besplatni KeePassX ili običan testni dokument (bolje je ako je upakiran u arhivu s lozinkom).

4. Promijenite lozinku baze podataka

Gore navedena pravila važe i za sigurnost MySQL pristupnog koda. Na kraju krajeva, tu se nalazi sav sadržaj, kao i heš adminove tajne fraze. Ako već koristite slabu lozinku, razmislite o njenoj promjeni. To se radi na sljedeći način:

1. Idite na phpMyAdmin kontrolni panel
2. Otvorite karticu “Korisnici” i odaberite vlasnika baze podataka
3. Kliknite na “Edit Privilege”
4. Pronađite kolonu "Promjena lozinke" i unesite novi tajni niz u odgovarajuća polja
5. Sačuvajte promjene klikom na “OK”

Sada ostaje da uredite wp-config.php, inače WordPress neće moći da se poveže sa bazom podataka. Pronađite red define('DB_PASSWORD', 'password'); i unesite novu lozinku umjesto riječi lozinka. Imajte na umu da, budući da se znak (‘) koristi za izolaciju SQL naredbi, ne bi se trebao koristiti kao dio pristupne fraze.

5. Redovno ažurirajte svoje lozinke

Treba ih mijenjati najmanje jednom u šest mjeseci. Vanredna promjena kodnih fraza mora se OBAVEZNO izvršiti nakon:

Prijenos podataka za autentifikaciju trećim stranama (programeri, sistem administratori, optimizatori i drugi stručnjaci, čak i ako rade za hosting kompaniju)
. ulazak u web resurs sa tuđeg računara (na zabavi, u internet kafeu)
. autorizacija opreme koja bi mogla biti ugrožena (mašina zaražena virusom)

6. Ne zaboravite promijeniti svoje tajne kolačića

Oni se nalaze u datoteci wp-config.php. Ima ih ukupno 8:

define("AUTH_KEY" , "jedinstveni ključ" ) ; define("SECURE_AUTH_KEY" , "jedinstveni ključ" ) ; define("LOGGED_IN_KEY" , "jedinstveni ključ" ) ; define("NONCE_KEY" , "jedinstveni ključ" ) ; define("AUTH_SALT" , "jedinstveni ključ" ) ; define("SECURE_AUTH_SALT" , "jedinstveni ključ" ) ; define("LOGGED_IN_SALT" , "jedinstveni ključ" ) ; define("NONCE_SALT" , "jedinstveni ključ" ) ;

define("AUTH_KEY", "jedinstveni ključ"); define("SECURE_AUTH_KEY", "jedinstveni ključ"); define("LOGGED_IN_KEY", "jedinstveni ključ"); define("NONCE_KEY", "jedinstveni ključ"); define("AUTH_SALT", "jedinstveni ključ"); define("SECURE_AUTH_SALT", "jedinstveni ključ"); define("LOGGED_IN_SALT", "jedinstveni ključ"); define("NONCE_SALT", "jedinstveni ključ");

Kao što možete pretpostaviti po nazivima varijabli, ključevi su odgovorni za šifriranje kolačića (poznati žargon: kolačić - kolačići, sol - sol, hranimo hakere slanim kolačićima), koji se koriste da bi stranica "zapamtila ” vaš računar nakon autorizacije. Suština je u tome da čak i ako napadač dobije heš administratorske lozinke na raspolaganju, neće moći generirati kolačiće potrebne za pristup stranici bez navedenih tajnih fraza.

Da bi se povećala sigurnost, zadane sekvence znakova treba zamijeniti jedinstvenim odmah nakon implementacije CMS-a. Radi praktičnosti, programeri su kreirali web generator koji se nalazi na www.api.wordpress.org/secret-key/1.1/salt/ - kada uđete, vidjet ćete tipke, a ako osvježite stranicu, kombinacije se ažuriraju .

7. Dvostruka autorizacija za admin panel

Htaccess vam omogućava da dodatno osigurate svoju WordPress stranicu dodavanjem autentifikacije na nivou servera. Kod će izgledati ovako:

< Files wp- login. php> # Postavite osnovni tip autentifikacije - to znači da kada pokušate# pristup navedenom direktoriju ili datoteci će biti zatražen za lozinku: AuthType basic # Unesite tekst koji će biti prikazan u zaglavlju obrasca: AuthName "Identifikujte se" # Odredite putanju do datoteke koja sadrži pristupnu frazu: AuthUserFile "/home/site/.htpasswd" # Navedite da kada pristupate datoteci wp-login.php, morate unijeti lozinku: Zahtijevajte važećeg korisnika # Zabrani pristup .htpasswd datoteci trećim stranama:< Files . htpasswd>naredi dozvoliti, odbiti odbiti od svih

# Odaberite datoteku skripte za autorizaciju: # Postavite osnovni tip autentifikacije - to znači da kada pokušate # pristupiti navedenom direktoriju ili datoteci, od vas će se tražiti lozinka: AuthType basic # Unesite tekst koji će biti prikazan u zaglavlju obrasca: AuthName "Identificiraj se" # Navedite putanju do datoteke koja sadrži pristupnu frazu: AuthUserFile "/home/site/.htpasswd" # Navedite da je lozinka potrebna kada se pristupa datoteci wp-login.php: Zahtijeva validan-user# Zabrani pristup .htpasswd datoteci trećim stranama: naredi dozvoli, zabrani odbije od svih

U isto vrijeme, bilo bi lijepo voditi računa o sigurnosti samog htaccess-a. Strogo govoreći, takva direktiva bi trebala biti napisana u glavnim postavkama hostinga, ali s obzirom na nepažnju nekih provajdera, trebali biste biti sigurni:

Umjesto "login", zamjenjujemo željeno ime. Ostaje da se sama generira šifra, kao i da je šifrira, jer je pohranjivanje takvih podataka u čistom tekstu nedopustiv luksuz. Postoji mnogo usluga za to, ali bolje je da sami napišete potrebnu skriptu. To se radi na sljedeći način:

1) Kreirajte .php datoteku u notepadu, na primjer crypt.php
2) Unesite kod tamo, zamjenjujući lozinku koju ste smislili umjesto riječi "Lozinka":

3) Sačuvajte datoteku i prenesite je u korijenski direktorij
4) Slijedite vezu site_name.ru/crypt.php - heš lozinke će se pojaviti na ekranu
5) Sačuvajte ovu vrijednost u .htpasswd datoteci i učitajte je u korijenski direktorij i izbrišite crypt.php

Posljednji dodir je zabrana pregleda sadržaja direktorija web resursa. Dovoljno je dodati jedan red u htaccess:

Opcije Sve - Indeksi

Opcije Svi indeksi

Ovo je učinjeno tako da hakeri ne mogu da saznaju koji se tačno fajlovi nalaze u direktorijumima projekta. Na mnogim hostingima ova direktiva je već uključena u postavkama servera, ali ako se ova tačka previdi, trebali biste je sami napisati.

8. Instalirajte captcha

Korištenje captcha će odsjeći, ako ne sve, onda barem većinu brutalnih botova, ali u isto vrijeme. Direktorij WordPress dodataka za zaštitu stranica nudi mnogo opcija. Pored povezivanja vlasničkog rješenja iz Google-a, veliki je interes Captcha by BestWebSoft mješovitog (grafičkog i tekstualnog) tipa, koji se bazira na matematičkim operacijama. Nezavisnost od usluga, vidljivost i prihvatljiv nivo složenosti čine modul jednim od najboljih.

Postavljanje nije veliki problem. Kartica “Osnovno” vam omogućava da odaberete gdje će se prikazati captcha, kao i da odredite naslov i znak za označavanje potrebnih polja.

Odjeljak "Napredno" pruža mogućnost kreiranja prilagođenih poruka o grešci, kao i aktiviranje dodatnih paketa slika kako bi život bio još težim botovima.

Još jedna korisna karakteristika je ugrađena bijela lista IP adresa za koje captcha neće biti prikazana.

Rezultat instaliranja i aktiviranja dodatka bit će izgled obrasca na stranici za autorizaciju:

9. Promijenite adresu administratora

Kada govorimo o tome kako zaštititi WordPress stranicu, vrijedi spomenuti radikalniji, ali i složeniji način - promjenu URL-a autorizacijske stranice na nivou skripte. Postupak se provodi u nekoliko faza:

1. Preimenujte datoteku wp-login.php. Koristite nasumični niz malih engleskih slova, brojeva i crtica. Na primjer: abc-123.php
2. U rezultirajućem fajlu pronađite sva spominjanja wp-login.php i zamijenite ih novim imenom.
3. Da bi sajt ispravno funkcionisao, zamena se takođe mora izvršiti u: 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, moj -sites.php, schema.php, ru_RU.po

Nakon ovih manipulacija, admin panel će se nalaziti na site/abc-123.php. Pristup novoj datoteci treba biti ograničen i zaštićen lozinkom kao što je gore opisano. Osim toga, možete prevariti potencijalne hakere kreiranjem lažne datoteke wp-login.php i postavljanjem lozinke za nju.

Još jednostavnija opcija je korištenje dodatka "Preimenuj wp-login.php". Nakon instaliranja dodatka za zaštitu stranice, pojavit će se novo polje u meniju “Postavke” -> “Permalinks”:

10. Navedite admin IP

Dodatna sigurnost se može pružiti ako imate statičku IP adresu. Onemogućavanjem pristupa wp-login.php sa bilo kog drugog računara osim vašeg, hakerima ćete mnogo otežati život:

< Files wp- login. php>narudžba zabrani, dozvoli zabrani od svih dozvoli od 127.0.0.1, 127.0.02 #Odvojite svoje IP adrese zarezom

naruči zabrani, dozvoli zabrani od svih dozvoli od 127.0.0.1, 127.0.02 #Navedite svoje IP adrese odvojene zarezima

11. Onemogućite greške pri autorizaciji

Prilikom grubog nametanja lozinki, napadaču će biti od velike koristi saznati da su se uneseni podaci pokazali netačnim. Takve poruke se prikazuju pri svakom neuspješnom pokušaju prijave, a WordPress također javlja šta je tačno uneseno pogrešno, login ili lozinka. Da biste ih se riješili, samo dodajte samo jedan red u functions.php:

add_filter("login_errors" , create_function ("$a" , "return null;" ) ) ;

add_filter("login_errors",create_function("$a", "return null;"));

Da biste to učinili, odaberite "Izgled" -\u003e "Uređivač" -\u003e "Funkcije teme" na administrativnoj ploči. Kod mora biti napisan nakon uvodne oznake.

12. Koristite sigurnu vezu.

Za šifrovanje saobraćaja između računara korisnika i web servera postoji protokol https, čija upotreba isključuje mogućnost presretanja važnih podataka, u našem slučaju identifikacionih podataka. Da biste ga aktivirali, prvo morate kupiti SSL certifikat koji istovremeno obavlja dvije funkcije: provjeru autentičnosti web resursa i enkripciju prenesenih informacija. Možete ga dobiti u specijalizovanim centrima ili kod brojnih registratora imena domena. Za nekomercijalne svrhe dovoljno je dobiti besplatan početni sertifikat (takvog nudi kompanija www.startssl.com). Što se tiče procesa instalacije, u pravilu je detaljno opisan u odjeljku pomoći hostera.

Nakon što ste dobili SSL certifikat, potrebno je konfigurirati preusmjeravanje administrativnog dijela web resursa na sigurnu vezu. U slučaju WordPress-a, to se radi pomoću sljedeće konstrukcije:

< IfModule mod_rewrite. c>Opcije + FollowSymlinks RewriteEngine On RewriteCond % ( HTTPS) = isključen RewriteCond % ( REQUEST_URI) = / wp-login. php RewriteRule (.* ) https:

Opcije +FollowSymlinks RewriteEngine On RewriteCond %(HTTPS) =off RewriteCond %(REQUEST_URI) =/wp-login.php RewriteRule (.*) https://%(HTTP_HOST)%(REQUEST_URI)

Također možete prisiliti korištenje SSL certifikata na razini motora. Da biste to učinili, otvorite datoteku wp-config.php i dodajte nakon

define("FORCE_SSL_ADMIN" , istina ) ;

define("FORCE_SSL_ADMIN", istina);

Osim toga, možete postaviti globalno preusmjeravanje sa http na https. Za nove stranice ovaj pristup je optimalan, s obzirom na to da Google potiče zaštićene projekte, dajući im određeni prioritet u rezultatima pretraživanja:

< IfModule mod_rewrite. c>Opcije + FollowSymlinks RewriteEngine na RewriteCond % ( HTTPS) = isključeno RewriteRule ^(.* ) $ https: //%(HTTP_HOST)%(REQUEST_URI)

Opcije +FollowSymlinks RewriteEngine na RewriteCond %(HTTPS) =off RewriteRule ^(.*)$ https://%(HTTP_HOST)%(REQUEST_URI)

13. Blokirajte uljeze

Ako se otkrije sumnjiva aktivnost s određenih IP adresa, vrijedi blokirati pristup web stranici za njih. Ovo se radi po analogiji s prethodnom metodom. Razlika je u tome što su direktive pisane za projekat kao celinu, a mi navodimo adrese onih koje želimo da zabranimo:

Naruči Dozvoli,Odbij Dozvoli od svih Zabrani od 127.0.0.1, 127.0.02 #Odredi neželjene IP adrese

Metoda je pouzdana, ali neefikasna. Prije svega, potrebno je nekako uhvatiti zahtjeve brutalnih sila i odvojiti ih od uglednih posjetilaca. Drugo, sa masivnim napadom, jednostavno ne možete ručno pratiti i unositi IP adrese hakera i botova. Ova metoda je dobra samo ako administrator ima pouzdanu "crnu listu" adresa.

U drugim slučajevima, možete koristiti sigurnosni dodatak za WordPress web lokaciju pod nazivom WP Cerber. Ovo rješenje je potpuno besplatno, dok nudi vrlo impresivan skup alata dizajniranih da spriječe CMS hakovanje. Možete ga instalirati direktno sa admin panela.

Standardno su ponuđeni prilično razumni parametri. Međutim, potrebno je povećati broj pokušaja na 5, kako ne bi došlo do nesporazuma.

Polje pored “Blokiraj IP na bilo kojem zahtjevu wp-login.php” treba biti označeno ako promijenite adresu administratora na način opisan ranije.

U ove svrhe možete koristiti vlastiti WP Cerber alat:

Način dodatka za zaštitu lokacije “Citadel” također ne zahtijeva dodatnu konfiguraciju. Dizajniran je da "očuva" projekat tokom masovnog napada grubom silom. Bolje je da poništite okvir pored "Snimi pokušaje prijave u datoteku" - to će pomoći u uklanjanju dodatnog opterećenja na serveru.

Kartica “Liste pristupa” se koristi za kreiranje “crne” i “bijele” liste IP adresa (ako imate statičku adresu, obavezno je dodajte na listu pouzdanih), a odjeljak “Alati” vam omogućava za uvoz i izvoz prethodno napravljenih postavki. Međutim, ove mogućnosti ne zahtijevaju posebno razmatranje.

14. Premjestite konfiguracijski fajl

Kao što smo gore saznali, wp-config.php pohranjuje kritične podatke kao što su korisničko ime i lozinka za pristup MySQL-u, kao i API ključevi. Čini se da je sljedeći korak očigledan - zaštita WordPress-a putem htaccess-a uz ograničenje pristupa fajlu:

< Files wp- config. php>Naredi dozvoli, odbij Odbije od svih

Naredi dozvoli, odbij Odbije od svih

Međutim, postoji pouzdanija metoda. WordPress ima vrlo zanimljivu funkciju za koju malo ljudi zna. Motor omogućava postavljanje konfiguracijskog fajla jedan nivo iznad korijenskog direktorija..php se može premjestiti u direktorij stranice. U tom slučaju, datoteka će postati općenito nedostupna putem Interneta, dok će informacije sadržane u njoj i dalje čitati CMS.

15. Dodajte provjeru REFERER

Metoda koja je dobro funkcionisala u zaštiti WordPress-a od neželjene pošte takođe će pomoći u slučaju suprotstavljanja brute-forcerima. Na kraju krajeva, nabrajanje lozinki ni u kom slučaju nije ručni posao: u te svrhe se koriste specijalizovani programi. Dakle, omogućavanjem provjere zaglavlja u dolaznim zahtjevima, možete odsjeći botove koji su "došli niotkuda" sa praznim HTTP REFERER-om:

< IfModule mod_rewrite. c>RewriteEngine na RewriteCond % ( REQUEST_METHOD) POST RewriteCond % ( REQUEST_URI) . (wp-comments-post|wp-login)\. php* RewriteCond % ( HTTP_REFERER) !.* tekseo. su.* [ OR] RewriteCond % ( HTTP_USER_AGENT) ^$ RewriteRule (.* ) http: //%(REMOTE_ADDR)/$1

RewriteEngine na RewriteCond %(REQUEST_METHOD) POST RewriteCond %(REQUEST_URI) .(wp-comments-post|wp-login)\.php* RewriteCond %(HTTP_REFERER) !.*site.* RewriteCond %(HTTP_USER_USER.$AGwENT) *) http://%(REMOTE_ADDR)/$1

16. Sigurni XML-RPC

Počevši od verzije 3.5, WordPress više nema mogućnost da onemogući XML-RPC protokol poziva udaljene procedure. U osnovi, potrebna je za interakciju s mobilnim aplikacijama, ali nije svima potrebna takva funkcionalnost. U isto vrijeme, xmlrpc.php se aktivno koristi za DDoS napade, kao Ahilova peta cijelog projekta.

Osim toga, hakeri su razmišljali o korištenju XML-RPC-a za brutalnu silu. Korištenje wp.getUsersBlogs metode omogućava vam da sortirate vjerodajnice mnogo brže nego putem administratorskog obrasca. Budući da mnogi XML-RPC pozivi zahtijevaju autorizaciju, zahtjev poput:

< methodCall> < methodName>wp. getUsersBlogs < params>< param>< value>< string>admin < param>< value>< string> 12345

wp.getUsersBlogs admin 12345

će uzrokovati da motor prijavi da li je prošla kombinacija važeća. Da biste se riješili ove pošasti, morate potpuno onemogućiti protokol. To možete učiniti na nekoliko načina:

1) Blokiranjem pristupa datoteci xmlrpc.php putem htaccess-a

require_once(ABSPATH . "wp-settings.php");

potrebno je registrovati se

funkcija remove_x_pingback($headers) ( unset($headers["X-Pingback"]); vrati $headers; ) add_filter("wp_headers", "remove_x_pingback");

4) Korištenje Control XML-RPC dodatka za objavljivanje, koji vraća odgovarajuću opciju u “Postavke” -> “Pisanje”:

Napomena: dodatak onemogućuje protokol odmah nakon aktivacije, a u postavkama ga možete omogućiti tako što ćete označiti odgovarajući kvadratić.

17. Pratite napade grube sile

Na kraju, vrijedi spomenuti zanimljiv dodatak za evidentiranje pokušaja hakovanja - Authentication i xmlrpc log writer. Iako WP Cerber ima ugrađene alate za praćenje, ovaj modul će i dalje biti koristan, posebno za one kojima su potrebne mogućnosti gore opisanog protokola. AX LogWriter može pratiti grubu silu preko xmlrpc.php, zahvaljujući čemu možete procijeniti stepen prijetnje i svrsishodnost potpunog odbijanja korištenja njegovih mogućnosti. Konačno, onima koji uopšte nisu bili uključeni u sigurnost svog projekta, dodatak za zaštitu sajta otvoriće im oči za važnost gore navedenih mera.

Korištenje AX LogWriter-a je jednostavno. Nakon instalacije, odgovarajući odjeljak će se pojaviti u administratorskom meniju, gdje možete izvršiti sve potrebne promjene:

U polju „Vrsta greške“ odaberite metodu spremanja. Podržava pisanje u sistemski dnevnik, dnevnik servera Apache, kao i mogućnost kreiranja prilagođene datoteke. U potonjem slučaju, također možete prilagoditi ime (Custom Error Log Name) i direktorij (Custom Error Log Path) za njega. Ovo otvara široke mogućnosti za administratora sistema - na primjer, rješenje se može koristiti zajedno sa fail2ban. Također ne zaboravite odabrati odgovarajuću vremensku zonu u koloni Vremenska zona.

Prilagođeni dnevnik se može pogledati direktno sa administrativnog panela na stranici Custom Log Viewer:

Da rezimiramo:

Gore navedene metode pomoći će vam da značajno povećate sigurnost vašeg resursa i zaštitite ga od botova grube sile, online huligana i praktikanata skripti. Međutim, sve gore opisano samo je vrh ledenog brega. U arsenalu napadača postoje daleko sofisticiranije metode. A u sljedećem članku ćemo govoriti o tome kako se zaštititi od pravih hakera koristeći različite ranjivosti u softveru motora i servera. Kao iu ovom materijalu, pored općih „pravila higijene“, bit će razmotrene ključne postavke CMS-a, načini izmjene koda, kao i najrelevantniji dodaci.


Kada je u pitanju sigurnost aplikacija, važno je voditi računa ne samo o hardveru i operativnom sistemu, već io pisanju sigurnih skripti. U ovom članku ćete naučiti kako osigurati svoju aplikaciju i učiniti je manje ranjivom. Ispod je lista mjera koje će vam pomoći da zaštitite svoju aplikaciju od svih vrsta napada:

  1. Validacija ulaznih podataka
  2. Zaštita od XSS napada
  3. Zaštita od CSRF napada
  4. Prevencija SQL injekcija
  5. Zaštita sistema datoteka
  6. Zaštita podataka sesije
  7. Greška u obradi
  8. Zaštita priloga

Validacija ulaznih podataka

Kada dizajnirate aplikaciju, trebali biste nastojati zaštititi je od "lošeg" unosa. Pravilo koje treba slijediti je otprilike ovo: "Nikad ne vjerujte onome što je korisnik unio." Unatoč činjenici da većina korisnika ne predstavlja prijetnju, uvijek postoji mogućnost da će neko poželjeti hakovati vašu stranicu koristeći „loše“ podatke unesene putem formulara ili adresne trake. Ako uvijek provjeravate i filtrirate dolazne podatke, onda imate dobre šanse da napišete sigurnu aplikaciju.

Uvijek provjerite svoje podatke u PHP skriptama. Ako koristite JavaScript za provjeru valjanosti podataka, napadač ga u svakom trenutku može onemogućiti u svom pretraživaču. U ovom slučaju, vaša aplikacija je u opasnosti. Niko nije protiv JavaScript validacije, ali za dobru zaštitu morate još jednom provjeriti podatke u PHP skriptama.

Zaštita od XSS napada

Cross-site scripting ili XSS napad je napad zasnovan na ubacivanju koda na potencijalno ranjive stranice. Opasnost je u tome što se zlonamjerni kod može unijeti kroz formulare i zatim prikazati u pretraživaču.

Pretpostavimo da vaša stranica ima obrazac za unos komentara, koji se odmah prikazuju nakon dodavanja. Napadač može unijeti komentar koji sadrži JavaScript kod. Nakon slanja obrasca, podaci se šalju na server i unose u bazu podataka. Nakon toga, podaci se preuzimaju iz baze podataka i novi komentar se prikazuje na HTML stranici, uključujući ugrađeni JavaScript kod. Može preusmjeriti korisnika na neku zlonamjernu stranicu ili web lokaciju za krađu identiteta.

Da biste zaštitili svoje aplikacije, proslijedite dolazne podatke kroz funkciju strip_tags(), koja će ukloniti sve prisutne oznake. Kada prikazujete podatke u pretraživaču, koristite funkciju htmlentities().

Zaštita od CSRF napada

Sljedeći tip napada koji ćemo razmotriti je CSRF napad, ili krivotvorenje zahtjeva na više lokacija. Napadač koristi razne trikove kako bi dobio povjerljive informacije ili izvršio transakciju bez znanja žrtve. To se uglavnom dešava na loše zaštićenim sajtovima, gde se poslovna logika zasniva na radu GET zahteva.

Uopšteno govoreći, GET zahtjevi su idempotentni. Idempotencija, u ovom kontekstu, znači da se istoj stranici može pristupiti koliko god puta želite bez ikakve intervencije treće strane. Zato GET zahtjeve treba koristiti samo za pristup informacijama, ali ni u kom slučaju za obavljanje raznih vrsta transakcija.

Sljedeći jednostavan primjer pokazuje kako nesigurno mjesto može biti podložno CSRF napadu:

Pretpostavimo da Bob želi izvesti CSRF napad na Alice. Generirao je posebnu url adresu i poslao je Alice na e-mail:

Posjetite moju stranicu!

Ako je Alice ovlaštena na example.com i prati ovu vezu, tada će 1000 dolara biti prebačeno sa njenog računa na Bobov račun. Alternativno, Bob može poslati i sliku i staviti "lošu" adresu u atribut src.

Pretraživač neće moći prikazati ovu sliku, jer ona ne postoji, međutim, zahtjev će biti napravljen bez znanja i učešća Alice.

Da biste spriječili ovu vrstu napada, koristite samo POST zahtjeve za procese koji su namijenjeni za promjenu informacija u bazi podataka. Nemojte koristiti $_REQUEST . Koristite $_GET za obradu GET parametara i $_POST za preuzimanje POST parametara.

Kao dodatnu mjeru, možete generirati neku vrstu jedinstvenog tokena i priložiti ga svakom POST zahtjevu. Kada se korisnik prijavi, može se generirati nasumični token i upisati u sesiju. Pošto su svi obrasci prikazani korisniku, ovaj token mora biti upisan u skriveno polje. Poslovna logika aplikacije mora osigurati funkcionalnost koja će provjeriti token iz obrazaca i token pohranjen u sesiji.

Prevencija SQL injekcija

PDO bi se trebao koristiti za ispitivanje baze podataka. Sa parametriziranim upitima i pripremljenim izrazima, možete eliminirati prijetnju SQL injekcije.

Pogledajmo sljedeći primjer:

U kodu iznad, šaljemo zahtjev metodi pripreme(), uključujući imenovane parametre: :name i :age . Dakle, upit je unaprijed kompajliran za dalju zamjenu podataka. Kada se pozove metoda execute(), zahtjev se u potpunosti formira i izvršava. Ako koristite ovu tehniku, tada će svi pokušaji napadača da izvrši SQL injekciju biti poništeni.

Zaštita sistema datoteka

Kao odgovoran programer, uvijek biste trebali pisati kod koji ne kompromituje vaš sistem datoteka. Pogledajmo kod koji šalje datoteku na preuzimanje u zavisnosti od podataka koje je korisnik dostavio.

Ova skripta je veoma opasna, jer zbog nje možete dobiti pristup bilo kom direktorijumu koji je dostupan iz datoteke sa skriptom: direktorijumu sa sesijama, sistemskim fasciklama i još mnogo toga.

Zaštita podataka sesije

Po defaultu, sve informacije o sesiji se zapisuju u privremeni direktorij. Ako koristite dijeljeni hosting, neko drugi osim vas može napisati skriptu i pročitati podatke sesije. Stoga se čuvajte pohranjivanja lozinki ili brojeva kreditnih kartica u sesijama.

Ako i dalje trebate pohraniti takve podatke u sesiji, onda je šifriranje najbolja mjera. Ovo ne rješava u potpunosti problem, jer šifrirani podaci nisu 100% sigurni, međutim, pohranjene informacije će biti nečitljive. Također biste trebali razmotriti pohranjivanje podataka sesije na drugom mjestu, kao što je baza podataka. PHP ima poseban session_set_save_handler() metod koji vam omogućava da pohranjujete podatke sesije na svoj način.

Od PHP 5.4 možete proslijediti objekt tipa SessionHandlerInterface u session_set_save_handler() .

Greška u obradi

Prilikom razvoja aplikacije vrijedi obratiti pažnju na sve vrste grešaka koje se mogu pojaviti, međutim, one moraju biti skrivene od krajnjih korisnika. Ako se korisnicima prikažu greške, to čini vašu stranicu ranjivom. Dakle, najbolje rješenje bi bila drugačija konfiguracija za odredišni i razvojni server.

Na javnom serveru morate onemogućiti opcije kao što su display_errors i display_start_up_errors, ali opcije kao što su error_reporting i log_errors moraju biti omogućene tako da se sve greške na koje naiđu korisnici bilježe.

Također možete koristiti set_error_handler za definiranje vlastitog rukovatelja greškama. Međutim, ovdje mogu postojati ograničenja, jer je izvorni rukovalac inferioran u odnosu na izvorni PHP mehanizam. Greške E_CORE_ERROR, E_STRICT ili E_COMPILER_ERROR ne mogu biti uhvaćene u istoj datoteci kao određeni rukovalac. Štaviše, greške koje se mogu pojaviti u samom rukovatelju također se ne mogu uhvatiti.

Za elegantniji način hvatanja izuzetaka, potencijalno opasan kod treba staviti u blok try/catch. Svi izvorni izuzeci moraju biti objekti klasa ili podklasa Exceptiona. Ako su izuzeci izbačeni, onda se njima može rukovati u bloku try/catch.

Zaštita priloga

Često se u PHP skriptama učitavaju druge datoteke, kao što je povezivanje sa bazom podataka i mnoge druge. Neki programeri daju ovim datotekama ekstenziju .inc. PHP po defaultu ne analizira takve datoteke. Ako im pristupite direktno na adresi, korisnik će moći vidjeti tekst ove datoteke. Ako haker uspije pristupiti datoteci koja pohranjuje podatkovnu vezu s bazom podataka, onda kasnije može dobiti pristup svim podacima u vašoj aplikaciji. Zato uvijek koristite ekstenziju .php za otpremljene datoteke i pohranite ih tamo gdje nema direktnog korisničkog pristupa.

Ishod

Ako slijedite ovih 8 pravila, to će uvelike povećati otpornost vaše aplikacije na razne vrste napada. Ne vjerujte podacima koje unose korisnici, zaštitite svoje datoteke i bazu podataka.

Hajde da razmislimo šta je haker? Haker nije kreker! Ljudi često brkaju ove koncepte. Haker je, prije svega, osoba nekonvencionalnog razmišljanja i u tome je njegova snaga, ako mogu tako reći.

Da biste se uspješno suprotstavili hakeru, također morate naučiti razmišljati izvan okvira. Kako kažu, klin se izbija klinom.

Danas ću vam ponuditi vrlo neobičan način da se zaštitite od php include napada. To svakako ne odgovara svima. I iskreno, štiti ne od samog napada, već od njegovog otkrivanja. Zaintrigirani?

Kako tražiti inkluziju...

Hajde da prvo shvatimo kako tačno napadač pokušava da otkrije ranjivost.

To izgleda ovako. Napadač modifikuje sve dolazne parametre jedan po jedan, pod pretpostavkom da podaci ovih parametara dospeju u funkciju uključivanja. Pa, ili ako na jednostavan način pokušava da „uključuje“ fajlove. A da bi se utvrdilo da li postoji ranjivost ili ne, treba da uključi neku vrstu fajla na ciljni sistem (to je bio nagoveštaj - postoji ranjivost, ne - nema ranjivosti).

Naravno, ako napadač djeluje izvana, onda ne zna strukturu lokacije direktorija i datoteka i ne može uključiti nijedan fajl, jer neće znati put do njega. Ali postoje datoteke koje uvijek postoje u sistemu i na koje uvijek postoje prava čitanja. Za Linux, ovo je /etc/passwd, a za Windows neka bude C:\boot.ini. Ali usput, Windows nas malo zanima, pa ćemo dalje govoriti o passwd

/etc/passwd

Vjerovatno ste u svojim logovima naišli na više unosa obrasca:

Akcija=../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

Ako da, onda znate, pokušali su da pronađu php uključen na vašoj web lokaciji (pa, ili mogućnost čitanja proizvoljnih datoteka, ali nas to sada ne zanima). Dakle, ako se jednim od vaših parametara ne rukuje ispravno i završi u funkciji uključiti(), tada bi datoteka /etc/passwd bila uključena, njen sadržaj bi se tumačio kao php skripta, a pošto ne sadrži oznake php koda, bio bi prikazan u pretraživaču nepromijenjen. Ovo bi poslužilo kao „marker“ da kreker ima ranjivost.

Zašto ovo pišem, na činjenicu da će napadač prilikom traženja uključuje sigurno (garantujem da će u 90% slučajeva) pokušati uključiti fajl /etc/passwd.

Zaštitite se, gospodine!

Možda sada razmišljate: “Da li želi da ponudi običan WAF i filter pakete po prisustvu /etc/passwd u njima?”. br. Ovo je standardni način. Ovo je primjer kako običan čovjek razmišlja.

Pokažimo malo mašte. Zašto jednostavno ne bismo dodali neki php kod u sadržaj passwd datoteke? A ako iznenada napadač uspije da ga uključi, onda će se naš php kod izvršiti. (Mislite li da je to glupost? - pogledajte zaključak)

Pošto znamo da je jedini koji pogodi da uključi ovaj fajl haker, onda bi ga naš php kod trebao zabraniti, a kako bismo spriječili dalje hakovanje našeg sistema, blokirati ranjivu datoteku i po mogućnosti obavijestiti administratora o incidentu .

Ali kako dodati php kod u /etc/passwd jer je njegova sintaksa strogo regulirana? Svaki korisnik ima polje "komentar" - opis korisnika, tu možete unijeti šta god želite (osim dvotočke, naravno). Stoga uzimamo i dodajemo korisnika u sistem sa komentarom koji nam je potreban. Nakon toga će /etc/passwd sadržavati sljedeći red

root:x:0:0:Superuser:/:
daemon:*:1:5::/:/sbin/sh
bin:*:2:2::/usr/bin:/sbin/sh
sys:*:3:3::/:
adm:*:4:4::/var/adm:/sbin/sh
sigurnosni korisnik:*:1001:1001::/:

Pa, u povezanoj skripti već izvodimo radnje koje su vam potrebne - zabranjujemo korisnika, blokiramo žalbu, obavještavamo administratora.

Kao rezultat toga, dobili smo neku vrstu zamke koja može zaštititi vašu web stranicu od hakovanja.

Zaključak

Da, potpuno sam svjestan da sve gore napisano izgleda kao glupost. I savršeno razumijem da to niko neće koristiti u praksi. Ali nisam pisao za to. Napisao sam kako bih pokazao primjer nestandardnog pristupa u oblasti zaštite.

Hvala na pažnji =)