PHP ranjivost i zaštita od PHP injekcija. Pravila za sigurno programiranje u PHP-u

Svi mi, na ovaj ili onaj način, želimo biti sigurni da niko ne može hakovati našu web stranicu ili blog. Ali, nažalost, realnost je takva da je svaki sistem ranjiv, ma koliko jak bio zaštićen. Sve zavisi samo od sredstava i upornosti provalnika... Hmm... Nešto me je povuklo u pogrešnom pravcu... Hajde da ovo smatramo predgovorom =)

Nedavno sam pisao o tome kako. Ali recimo da ste uzeli gotov CMS i ne znate kako se tamo implementira učitavanje, a zapravo i sva zaštita. Naravno, posebno radoznali i kompetentni programeri će proučiti kod ovog CMS-a prije nego što ga stave na svoju web stranicu. Ali šta je sa onima koji nemaju toliko vremena?

U redu, ili recimo da ste jedan od onih koji vjeruju da je sigurnost i ispravno podešavanje Zar ne postoji dodatni server? Ako je tako, onda dobrodošli u mačku.

Ne, u članku nećete pronaći neki super duper dodatak koji filtrira sve podatke, koji moraju biti uključeni u sve datoteke. Moja ideja je da koristim auto_prepend_file direktivu i napravim listu dozvoljenih fajlova... Ali generalno, pročitajte sami...

Dugo sam imao ovu ideju u glavi, ali sam je konačno uspio, iako tu nema ništa komplikovano, i uspio sam implementirati ovaj sistem i napisati članak =)

Princip rada

Kao što sam rekao gore, sistem je zasnovan na auto_prepend_file direktivi u php.ini. Ona je odgovorna za instalaciju skripte, koja će se izvršiti PRIJE izvršavanja glavne.

Na primjer, otvorili ste index.php i prije nego što ga izvršite, pokreće se datoteka navedena u auto_prepend_file. Poenta je da ćemo u ovoj skripti moći da kontrolišemo dalji rad druge skripte. Grubo govoreći, nastavite sa radom i pokrenite traženu skriptu ili odmah izađite (die()).

Na primjer, situacija u kojoj je napadač učitao ljusku na vašu web stranicu kroz neku vrstu ranjivosti i pokušava je otvoriti u pretraživaču. I umjesto njegove ljuske, bez razloga mu se daje ova greška:

Tako nešto bi me prestrašilo...

Da bi moj sistem radio, potrebna mi je lista dozvoljenih datoteka pristup datotekama koje se ne nalaze na ovoj listi.

(Ne znam da li je ovaj dijagram potreban, izgleda da bi sve trebalo biti jasno...)

Naravno, ručno sastavljanje takve liste nije plemenit zadatak, pa sam došao do zaključka da ima smisla implementirati takozvani „režim učenja“. Režim u kojem će svi pozivi svim skriptama biti automatski dodani na listu dozvoljenih datoteka.

Šta ovo daje? Možete pokrenuti ovaj sistem u režimu obuke i nastaviti koristiti svoju stranicu. Kako je koristite, vaša baza podataka će se popunjavati stranicama koje koristite (izvinite na igri riječi). I recimo da će za mjesec dana vaša lista sadržavati sve datoteke koje se odnose na vašu web lokaciju (kojoj ste direktno pristupili).

Imajte na umu da će lista sadržavati samo one datoteke s kojima ćete direktno raditi. Prosječni mehanizam web stranice ima gomilu plug-in datoteka (sa klasama, funkcijama, bibliotekama, modulima, itd.), te datoteke neće biti uključene u ovu listu, a pristup će im biti blokiran u budućnosti na nivou naša zaštita (naravno, prosječni motori imaju zaštitu od direktnog lansiranja, ali odjednom negdje ova zaštita nedostaje).

Šta možemo da uradimo

Pošto je ovo koncept, ne možemo mnogo učiniti.

  • Blokiranje neovlaštenih skripti (zapravo glavna funkcija). Ali opet, ovo je prilagodljivo, ne morate blokirati vezu, već samo obavijestite administratora putem e-pošte
  • Obavještavanje administratora o nelegitimnim zahtjevima putem e-pošte (kratak izvještaj ili potpuni izvještaj, potonji uključuje zaglavlja paketa i podatke POST zahtjev ako ih ima)
  • Možete odrediti IP administratora, koji će imati pristup svim skriptama, tj. ovaj sistem to neće biti pogođeno (ove IP adrese neće učestvovati u režimu obuke). Na primjer, sada ne morate zatvarati softver poput PhpMyAdmin, SupexDumper i druge sistemske uslužne programe pomoću .htaccess.
  • Ksati IP adrese podržavaju jednostavne maske =)
  • Potpuno komentiran kod, a svaka konfiguracijska direktiva je detaljno opisana
  • pa šta još...
Postavke

Hajde sada da razgovaramo o tome kako da ugradite ovu zaštitu u svoju web stranicu...

Da biste to uradili, potreban vam je pristup datoteci php.ini

  • Prvo preuzmite samu skriptu: PrependSecuritySystem
  • Raspakujte sadržaj arhive (data.txt i main.php) u neki folder na serveru, po mogućnosti u folder koji nije dostupan sa weba (nije neophodno, jer će raditi na bilo kojoj lokaciji, ovo ima smisla zadržati scenarij dalje od očiju napadača)
  • Otvorite datoteku main.php i uredite postavke. Potrebno je promijeniti IP adresu i email administratora. Ostala podešavanja su po vašem nahođenju.
  • Postavite prava pristupa raspakovanim fajlovima. Pod nadimcima, preporučljivo je promijeniti vlasnika za oba fajla, različitog od korisnika pod kojim web server radi. Datoteka main.php mora biti dostupna svima. Za datoteku data.txt morate postaviti dozvole za čitanje i pisanje za sve (ovo je privremeno, za period obuke)
  • Otvorite php.ini i unesite sljedeće:
    auto_prepend_file=[put do raspakiranog main.php fajla]
  • WITH u ovom momentu počinje sistemska obuka. Čekamo određeno vrijeme, dovoljno, po vašem mišljenju, da se sistem u potpunosti osposobi.
  • Na kraju treninga otvorite main.php fajl i uredite konstantu PSS_STATUS_BLOCK, postavite njenu vrijednost na true, sačuvajte
  • Promijenite prava pristupa datoteci data.txt. Zabranjujemo uređivanje ovaj fajl za sve.
  • Sada je sistem prešao u način blokiranja neovlaštenih skripti
  • Naravno, ima puno koraka, ali čini mi se da i dijete to može podnijeti.

    Ako trebate ponovo osposobiti sistem (od nule ili dodati mu), tada morate:

  • Dozvoli pisanje u data.txt datoteku
  • Obrišite sadržaj datoteke data.txt (SAMO ako trebate ponovo obučiti sistem od nule)
  • Uredite konstantu PSS_STATUS_BLOCK u datoteci main.php, postavljajući njenu vrijednost na false
  • Preobučavamo se...
  • Na kraju preobuke, uredite konstantu PSS_STATUS_BLOCK i vratite njenu vrijednost na true
  • Zabranjujemo pisanje datoteke data.txt
  • Pa, sad o tužnom

    Neću lagati, a sada ću vam reći o nedostacima.

    • Možda je glavni nedostatak, u poređenju sa kojim svi drugi blede u poređenju, to što se ovaj sistem može zaobići. Možete pitati: kako je to moguće? Sve je vrlo jednostavno, auto_prepend_file direktiva se također može specificirati u .htaccess. A ako tome pristupite trezveno, ako je napadač iznenada uspio da poplavi školjku, onda će vjerovatno moći preplaviti svoj .htaccess u kojem može onemogućiti originalnu direktivu.
      Ovo radi samo pod apacheom, ali na primjer pod nginxom ovaj trik neće raditi (nginx nema .htaccess fajlove). ALI! Pod Nginxom općenito možete uploadati .
    • Napadač može urediti „dozvoljenu“ skriptu ako za to postoje valjana prava, a naš sistem, nažalost, ne može ništa učiniti po tom pitanju. Osim ako ne morate postaviti ispravne dozvole za sve izvršne datoteke
    • Pored PHP-a postoje i svakakvi perl, cgi itd... ovaj sistem ne radi sa njima.
    • Dodatno opterećenje. Ali mislili su da će ovo opterećenje biti primjetno.

    Zato se, čini se, takav originalni sistem ne može nazvati idealnim. Ali sasvim je prikladan kao jednostavna preventivna mjera koja će zaustaviti ne najtvrdoglavije tvrdoglave provalnike. U najmanju ruku, ovaj sistem će moći oduzeti napadaču vrijeme da izvrši napad. Na primjer, sistem će obavijestiti administratora o pokušaju hakovanja, dajući tako administratoru priliku da eliminira ranjivost sve dok napadač ne shvati razlog svojih neuspjeha.

    Zaključak

    Ipak, na ovaj ili onaj način, ovo je koncept, možda na osnovu njega možete smisliti nešto bolje. Ili će vam možda moj sistem odgovarati.

    Po mom mišljenju, razumne zaštite nikada nije previše. Na vama je da odlučite da li ćete koristiti nešto ovakvo ili ne na svojim stranicama.

    Phew. Pa, napisao sam, nije me bilo skoro cijeli dan. Izvinite ako sam malo haotično opisao. Općenito, postavljajte svoja pitanja u komentarima, pokušat ću odgovoriti.

    PS: iako sam kodirao što je moguće adekvatnije, skripta može imati greške. Testirano na win/apache/php 5.2 - sve je bilo ok.

    Širom svijeta na aerodromima se može naći slogan „Sigurnost nije šala“. Svaki isti slogan Administrator sistema trebalo je da ga zakačim pored mog PHP servera. I svako ko se povezuje na server na Internetu mora poduzeti odgovarajuće sigurnosne mjere ili rizikovati gubitak podataka, pa čak i novca od zlonamjernih hakera. softverće moći da prouzrokuju štetu koristeći tastaturu svog računara.

    Programer web stranice zabrinut zbog sigurnosnih problema mora stalno ponavljati: "Ne vjerujte mreži." Ako ste zabrinuti za zaštitu vaše web lokacije, ponovite ovu izjavu dok kodirate buduće stranice na vašoj web-lokaciji. Sve informacije koje se prenose na server preko mreže (bilo da je to URL, podaci sa HTML forme ili podaci koji stižu preko nekog drugog mrežni port), treba smatrati potencijalno opasnim. Ovaj članak predlaže nekoliko metoda za osiguranje dolaznih informacija. Neophodno je ne samo primijeniti ove metode, već i obratiti pažnju određeno vrijeme identificirati druge potencijalne opasnosti i pronaći načine da ih spriječi.

    Drugo pravilo za kreiranje sigurne stranice je: “Smanjite štetu”. Šta se dešava ako se program koji pišete, a za koji mislite da je potpuno pouzdan, zaista pokaže ranjivim? Čak i samo da ostanem unutra potpuna sigurnost, ograničiti štetu koju bi napadač mogao uzrokovati iskorištavanjem ove ranjivosti.

    Kada posjetitelji dođu na Vašu stranicu, nadaju se da stranica sadrži valjane informacije koje neće naštetiti njima ili njihovim računarima, te da će informacije koje daju biti pravilno tretirane. Uvijek postoji određeni rizik od narušavanja sigurnosti posjetitelja prilikom interakcije s bilo kojom web lokacijom, bez obzira da li se radi o zabavnoj, informativnoj ili e-trgovini. Odgovornost za zaštitu posjetitelja od takvih rizika leži na dizajneru stranice. To znači da ne samo da morate bezbedno da čuvate informacije koje su dali posetioci na vašem serveru, već i da preduzmete korake da zaštitite date informacije dok se prenose sa računara posetilaca na vaš server.

    Ali sva ova razmatranja ne bi se trebala miješati u vaše namjere, na primjer, u vezi s dovođenjem vaše web stranice za e-trgovinu na internet.

    Mogući napadi

    Povezivanje servera na Internet može se uporediti sa otvaranjem prodavnice u prometnoj ulici. Željeli biste da imate puno posjetitelja, ali bez preduzimanja mjera opreza, možda ćete otkriti da će vašu nepažnju iskoristiti ne obični posjetitelji, već vrlo neželjeni gosti.

    Obično hakeri navedite one koji bi bili tačnije imenovani provalnici softverska zaštita . U kompjuterskoj zajednici, sigurnosni krekeri su stručnjaci koji, koristeći sreću ili svoje vještine, savladavaju sigurnost kompjuterski sistemi i uzrokovati štetu. A hakeri su programeri koji znaju kako majstorski pišu programe i sposobni su ne samo da razumiju složeni kod, već i samostalno pišu efikasan (i često nedostupan autsajderima) kod na mnogim jezicima. Za programera je sticanje titule hakera čast, a titula krekera softvera očigledno znači da njegov vlasnik mora paziti na postove "Traži se".

    Ne shvaćajući koliko je ponižavajuća titula softverskog krekera, mnogi programeri početnici kreću tim putem pribjegavajući alatima i skriptama koje pronađu na internetu. Takvi krekeri početnici se nazivaju script-kiddies ili, na našem jeziku, kulhatskeri. Ovi ljudi često jedva razumiju šta rade. Tipično, ova kategorija prestupnika stoji iza primitivnih napada kao što su kompromitacija web stranice, XSS i SQL injekcije.

    Kompromitacija stranice i XSS napadi

    Slučajevi kompromitovanja sajta, koji su često više smetnja nego zapravo štetna, prilično su česti, jer mnoge stranice pružaju priliku hakeru za sigurnost softvera da objavi svijetu da je uspio u postizanju svog cilja. Da biste ugrozili loše dizajniranu web stranicu, ponekad je sve što je potrebno koristiti samo web preglednik. Razmotrite, na primjer, sljedeći program:

    Stranica sa jednostavnim formularom za komentare PHP Basics

    Ovaj program implementira sistem komentara u vrlo primitivnom obliku (ako proučavate moj PHP tutorijal od početka, možda još niste upoznati sa operacijama baze podataka; ako jeste, onda preporučujem da se vratite na ovaj članak nakon što pročitate relevantne materijal na MySQL).

    Čitajući ovaj kod, iskusni programer počinje da se ne osjeća sasvim samouvjereno (zapamtite - „Ne vjerujte mreži“). Takav program prihvata podatke obrasca za koje se očekuje da sadrže tekst komentara. Ovaj tekst se dodjeljuje varijabli $comment i pohranjuje u bazu podataka kako bi se prikazao budućim posjetiteljima. Ako su uneseni podaci ono što očekujemo, onda neće biti problema.

    Sada se na trenutak stavite u kožu hladnjaka i zamislite šta bi se dogodilo da unos sadrži HTML deskriptore. Ovo jednostavan programće mehanički ubaciti takve deskriptore u generiranu stranicu, a ova iskrivljena stranica će se otvoriti u pretraživačima drugih posjetitelja umjesto na uobičajenoj. Jedan deskriptor koji može biti posebno opasan iz perspektive sigurnosti podataka je . Sigurnosni kreker bi mogao umetnuti sljedeći komentar:

    Ubacivanje zlonamjernog JavaScript koda

    Ova vrsta napada je poznata kao cross-site scripting ili XSS. Nakon zatvaranja i otvaranja ove stranice, pretraživač će dobiti takav ručnik i odmah početi učitavati stranicu lažne stranice, a ne stranicu hakovane stranice. Uz malo domišljatosti, sigurnosni haker tada može iskoristiti povjerenje koje posjetitelji imaju u vašu web-lokaciju da izvuče lične podatke kao što su lozinke ili brojevi kreditnih kartica (putem krađe identiteta, što je proces imitacije dizajna i strukture zlonamjerne stranice kako bi ličila na hakovana stranica).

    Rješenje za takav problem je da ulazne podatke treba unaprijed obraditi iz sigurnosnih razloga. U ovom slučaju, potrebno je pretvoriti sve znakove koji imaju posebno značenje za pretraživač u neki siguran oblik. Srećom, PHP ima način da izvrši upravo ovu konverziju. Funkcija htmlentities() pretvara znakove , " i & u reprezentacije tih znakova u obliku takozvanih HTML znakovnih entiteta (kao što je

    Učitavanje...
    Top