PHP este unul dintre cele mai populare limbaje pentru dezvoltarea web acest moment. Drept urmare, hackerii caută în mod constant modalități de a folosi scripturile PHP pentru a obține acces neautorizat sau pentru a deteriora sistemul. Securitatea codului PHP este esențială în orice aplicație web pe care o dezvoltați.

Există două categorii principale de metode de protecție a codului pentru securizarea unei aplicații PHP. Prima categorie presupune configurarea interpretului PHP propriu-zis prin fișierul php.ini, care are un impact asupra securității aplicației în ansamblu. A doua categorie implică utilizarea practicilor de programare dovedite și scrierea codului securizat pentru a preveni exploatarea vulnerabilităților.

Protejarea PHP cu php.ini

Există o serie de setări în PHP care afectează securitatea aplicațiilor dvs. Aceste setări pot fi controlate folosind fișierul php.ini. Controlându-se Job PHP, reduceți daunele potențiale pe care le pot provoca erorile.

Dezactivează Register Globals

Înainte de versiunea 4.2.0, PHP folosea variabile globale pentru a oferi acces la variabilele de intrare din cererile GET și POST. Această caracteristică a fost eliminată deoarece oferă o lacună de securitate. Atacatorii îl pot folosi pentru a manipula variabile în diferite scenarii. Dar pentru compatibilitate cu versiunea inversă, PHP vă permite să personalizați register_globalsîn php.ini. Când această opțiune este activată, PHP rulează în modul vechi și înregistrează variabilele globale pentru valorile de intrare. Pentru a menține PHP în siguranță, această setare ar trebui să fie întotdeauna dezactivată. Evitați să utilizați scripturi care necesită register_globals, deoarece acesta este de obicei un semn de scripturi potențial periculoase sau actualizate rar.

Control acces la fișiere

Scripturile PHP pot folosi funcția fopen pentru a citi și scrie fișiere Sistemul de fișiere Server. Aceasta este, desigur, o oportunitate foarte necesară. Cu toate acestea, poate prezenta și un risc de securitate. O eroare într-un script PHP ar putea permite unui atacator să citească sau să rescrie fișiere de sistem. Din fericire, PHP are o serie de opțiuni care vă permit să controlați care fișiere PHP pot avea acces.

Doriți să începeți să câștigați prin promovarea contului dvs. în în rețelele socialeși folosiți marketingul pe internet, dar nu știți de unde să începeți? Site-ul Pricesmm vă va ajuta să înțelegeți acest proces. Aici, un specialist tânăr, dar destul de experimentat, vă va spune despre ceea ce mulți oameni încă nu știu. Acest lucru vă va ajuta să creșteți rapid ratingul oricărei pagini, cont sau canal.

Una dintre opțiunile care pot fi utilizate în php.ini aceasta este open_basedir. Acest parametru acceptă un subdirector precum /home/user/html/. I/O-ul interpretului este limitat la subdirectorul specificat, ceea ce împiedică PHP să citească și să scrie fișiere în afara acelui subdirector.

De asemenea, puteți utiliza opțiunea safe_modeîn php.ini pentru a controla accesul la fișiere. LA modul sigur PHP poate deschide numai fișiere care sunt deținute de același utilizator ca serverul web. De asemenea, setarea împiedică PHP să ruleze executabile. Dacă trebuie să permiteți accesul PHP la fișiere care aparțin diferiților proprietari, puteți utiliza safe_mode_gid. Parametrul restricționează accesul PHP numai la acele fișiere care aparțin grupului în care rulează serverul web.

Ascunde PHP

Deși securitatea prin obscuritate nu este suficientă pentru a proteja aplicația, va fi mai greu pentru hackeri să încerce să pirateze, deoarece hackerii nu vor ști ce tehnologii folosiți. PHP își face identitatea în mai multe moduri, inclusiv anteturi și semnătura Apache. Aceasta poate fi dezactivată cu expose_php = dezactivatîn php.ini.

Un alt simptom pe care PHP îl aruncă este afișarea erorilor. Erorile includ adesea informații despre căi și alți parametri pe care un hacker îi va găsi de neprețuit. Mesajele de eroare sunt de neprețuit în timpul dezvoltării pentru testare și depanare, dar ar trebui să fie dezactivate atunci când aplicația este pusă în producție. Le puteți dezactiva setând: display_errors = Dezactivatîn php.ini. caracteristică utilă este să scrieți mesaje de eroare în fișierul jurnal, care pot fi activate setând: log_errors = Activat în php.ini.

În cele din urmă, Apache poate fi configurat să rescrie adresele URL pentru a ascunde extensia PHP.

Folosind tehnici de programare dovedite

După securitate setare PHP php.ini, trebuie să acordați atenție codului în sine. O altă modalitate de a proteja PHP este tehnica bună de programare. Există o serie de tehnici de programare încercate și adevărate, dar nu mai puține tehnici de evitat.

Control POST și trimiteri de formulare

Falsificarea formularelor este un atac comun asupra site-urilor web. Acest lucru se face de obicei prin efectuarea unei cereri POST și trimiterea acesteia la adresa URL specificată în atributul de acțiune din formular. De cele mai multe ori, spoofing-ul este inofensiv, dar enervant, cum ar fi atunci când spammerii spam scripturi care procesează un formular părere. Cu toate acestea, schimbarea formei poate fi periculoasă. Unii dezvoltatori consideră că utilizarea unei liste derulante într-un formular poate limita intrarea utilizatorului. După aceea, ei nu validează intrarea utilizatorului, deoarece cred că formularul a fost validat pentru ei. Acest lucru poate fi periculos dacă cineva trimite date către script fără a utiliza un formular. Datele transmise nu se vor limita la lista de selecție.

O modalitate de a vă proteja împotriva falsării formelor este să utilizați markere unice. Generați jetoane aleatoare și stocați împreună cu sesiunea. Apoi utilizați câmpuri de intrare ascunse pentru a trimite jetoane unice ca parte a formularului. Când procesați formularul, comparați simbolul din sesiune și simbolul din formular. Dacă se potrivesc, procesați formularul; dacă nu, afișați un mesaj de eroare. După procesare, simbolul ar trebui să fie eliminat din sesiune.

Markerele de unică folosință nu oferă protecție 100%. Chiar dacă utilizați sistemul de marcare, validați întotdeauna intrarea atunci când procesați un formular.

Protecția bazei de date

Când lucrați cu baze de date, nu trebuie să utilizați instrucțiuni SQL dinamice care se bazează pe intrarea utilizatorului. Acest lucru creează o oportunitate reală pentru atacatori de a trimite date greșite la baza de date. Uneori trebuie să utilizați intrarea utilizatorului în interogare SQL. Validați intrarea utilizatorului înainte de a o utiliza într-o interogare. Dacă bază Date MySQL, puteți folosi funcția mysql_real_escape_string(). Această funcție va elimina caracterele nevalide, gestionând eficient introducerea utilizatorului. Dacă codul dvs. folosește funcționalitatea PHP magic_quotes_gpc, acum este momentul să regândim scopul codului. Utilizarea magic_quotes_gpc va fi retrasă în PHP versiunea 6.

Obține feedul extern și îl analizează în date (o analizează).

Funcția este necesară pentru a obține fluxul RSS ca obiect SimplePie și pentru a stoca rezultatul în cache.

Pentru a obține și analiza un flux fetch_feed() folosește populara clasă SimplePie. Fluxul este stocat în cache, iar cache-ul este actualizat ulterior la fiecare 12 ore.

Datele sunt stocate în cache în baza de date în opțiuni temporare. Dacă este instalat pluginul de cache a obiectelor persistente, atunci funcția se va păstra în cache nu în baza de date, ci în stocarea pentru cache-ul obiectelor.

se intoarce

SimplePie/WP_Error. Obiect de date de alimentare SimplePie sau obiect WP_Error în cazul unei erori.

Utilizare

$feed = fetch_feed($uri); $uri (șir) (obligatoriu) Link (URL) către feedul pe care doriți să îl obțineți. Ca rezultat, un obiect SimplePie (matrice) va fi creat folosind acest link.
Implicit: nu

Exemple

#unu. Obțineți ultimele 5 postări dintr-un flux de pe un site extern

Un exemplu care primește și afișează linkuri către un flux RSS existent. În exemplu, limităm rezultatul la numai ultimele 5 postări din feed.

Cele mai recente știri de pe blogul blog.ru

get_item_quantity(5); // Creați o matrice cu toate intrările de feed, începând de la prima intrare (0 - start) $rss_items = $rss->get_items(0, $maxitems); ) ?>

Fără înregistrări."; ) else ( // Buclă prin matrice și scoate un link către fiecare intrare foreach ($rss_items ca $item) ( ?>
• get_permalink()); ?>" title="(!LANG:get_date("j F Y | g:i a"); ?>">get_title()); ?>

#2 Un alt exemplu: obțineți 5 intrări de feed terțe

Să citim feedul http://mysite.ru/feed/ și să obținem primele 5 înregistrări din acesta.

include_once(ABSPATH . WPINC . "/feed.php"); $rss = fetch_feed("http://mysite.ru/feed/"); $rss_items = $rss->get_items(0, $rss->get_item_quantity(5)); if (! $rss_items) ( echo "fără elemente"; ) else ( foreach ($rss_items ca $item) ( echo "

get_permalink() . "">" .$item->get_title() ."

"; } }

Gestionarea duratei de viață a fluxului cache

Rezultatul primirii feedului este stocat în cache timp de 12 ore. Pentru a modifica timpul de cache pentru funcția fetch_feed(), trebuie să utilizați hook-ul wp_feed_cache_transient_lifetime.

Add_filter("wp_feed_cache_transient_lifetime", "speed_up_feed", 10, 2); funcția speed_up_feed($interval, $url) ( if("http://mysite.ru/feed/" == $url) returnează 3600; // 1 oră returnează $interval; )

Dezactivați memoria cache în timpul dezvoltării

În timpul manipulării fluxului, este necesar să dezactivați stocarea în cache, altfel va interfera foarte mult. Acest lucru se poate face prin intermediul hook-ului wp_feed_options.

## dezactivează memorarea în cache a feedurilor. Numai dacă modul de dezvoltare WP_DEBUG este activat if(defined("WP_DEBUG") && WP_DEBUG)( add_action("wp_feed_options", function(&$feed)( $feed->enable_cache(false); )); )

IMPORTANT! Asigurați-vă că dezactivați acest cod pe site-ul de producție. Pentru că poate crește viteza de încărcare a paginilor site-ului uneori!

Memorarea în cache a fluxului nu funcționează cu constanta WP_DEBUG activată

Rețineți că, dacă constanta WP_DEBUG este activată, atunci fluxul nu este stocat în cache. Următorul cod de kernel funcționează:

Funcția do_not_cache_feeds(&$feed) ( $feed->enable_cache(false); ) if (defined("WP_DEBUG") && WP_DEBUG) add_action("wp_feed_options", "do_not_cache_feeds");

Memorarea în cache a browserului

De asemenea, rețineți că stocarea în cache poate apărea în browser, pentru a o ocoli, reîmprospătați pagina cu ctrl + F5. Sau puteți adăuga acest cârlig:

## dezactivați memorarea în cache a browserului pentru cererile de feed add_filter("wp_headers", function($headers)( if(!empty($GLOBALS["wp"]->query_vars["feed"]))( unset($headers[" ETag "], $headers["Last-Modified"]); ) returnează $headers; ));

Ștergerea memoriei cache a tuturor fluxurilor din WordPress

Pentru a rula codul, trebuie să adăugați parametrul ?clear_feeds_cache la adresa URL.

## Ștergeți memoria cache a tuturor fluxurilor WordPress if(isset($_GET["clear_feeds_cache"]))( global $wpdb; $cleared = $wpdb->query("ȘTERGERE DIN $wpdb->opțiuni WHERE opțiunea LIKE "\_transient% \_feed\_%""); die(var_dump(!!$cleared)); )

Notă: dacă stocarea în cache a obiectelor este activată pe site, atunci acest cod nu va funcționa...

Note

Lista modificărilor

Din versiunea 2.8.0

Introdus.

Codul preluați feedul: wp-includes/feed.php WP 5.3.2

set_sanitize_class("WP_SimplePie_Sanitize_KSES"); // Trebuie să suprascriem manual $feed->sanitize pentru că // constructorul SimplePie îl setează înainte de a avea șansa de a seta clasa de dezinfectare $feed->sanitize = new WP_SimplePie_Sanitize_KSES(); $feed->set_cache_class("WP_Feed_Cache" ); $feed->set_file_class("WP_SimplePie_File"); $feed->set_feed_url($url); /** Acest filtru este documentat în wp-includes/class-wp-feed-cache-transient.php */ $feed ->set_cache_duration(apply_filters("wp_feed_cache_transient_lifetime", 12 * HOUR_IN_SECONDS, $url)); /** * Se declanșează chiar înainte de procesarea obiectului de feed SimplePie. * * @since 3.0.0 * * @param object $feed Obiect de feed SimplePie ( transmis prin referință).* @param mixed $url URL al feedului de preluat. Dacă o matrice de adrese URL, fluxurile sunt îmbinate.*/ do_action_ref_array("wp_feed_options", array(&$feed, $url)); $feed- >init(); $feed->set_output_encoding(get_option("blog_charset")); if ($feed->error()) ( returnează nou WP_Error ("simplepie-error", $feed->error()); ) returnează $feed; )

Cu toții, într-un fel sau altul, am dori să fim siguri că nimeni nu ne poate sparge site-ul sau blogul. Dar, din păcate, realitatea este că orice sistem este vulnerabil, oricât de puternic ar fi protejat. Totul depinde doar de resurse și de perseverența unui hoț... Hmm... Ceva m-a tras în direcția greșită... Să considerăm asta o prefață =)

Nu cu mult timp în urmă am scris despre cum. Dar să presupunem că ați luat un CMS gata făcut și nu știți cum este implementată descărcarea acolo și faceți toată protecția. Desigur, dezvoltatorii deosebit de curioși și competenți vor studia codul acestui CMS înainte de a-l pune pe site-ul lor. Dar cum rămâne cu cei care nu au atât de mult timp?

Bine, sau să presupunem că sunteți unul dintre cei care cred că securitatea și configurarea corectă a serverului nu sunt niciodată de prisos? Dacă da, atunci bine ați venit sub cat.

Nu, în articol nu veți găsi un plugin super duper care filtrează toate datele care trebuie incluse în toate fișierele. Ideea mea este să folosesc directiva auto_prepend_fileși construirea unei liste de fișiere permise ... Dar, în general, citiți pentru dvs. ...

Această idee îmi stă în cap de mult timp, dar în cele din urmă am pus mâna pe ea, deși nu este nimic complicat aici, și am putut implementa acest sistem și am putut scrie un articol =)

Principiul de funcționare

După cum am spus mai sus, sistemul se bazează pe funcționarea directivei auto_prepend_fileîn php.ini. Ea este responsabilă de instalarea scriptului, care va fi executat ÎNAINTE de executat cel principal.

De exemplu, ați deschis index.php și, înainte de executarea acestuia, fișierul specificat în auto_prepend_file. Concluzia este că în acest script vom putea controla activitatea ulterioară a altor scripturi. În linii mari, continuați să lucrați și rulați scriptul solicitat sau ieșiți imediat ( a muri()).

De exemplu, situația - un atacator a încărcat un shell pe site-ul dvs. printr-un fel de vulnerabilitate și încearcă să îl deschidă într-un browser. Și în loc de coaja lui, fără motiv, i se dă, iată o astfel de eroare:

Așa ceva m-ar pune în stupoare...

Pentru ca sistemul meu să funcționeze, am nevoie de o listă de fișiere permise, accesul la fișierele care nu sunt în această listă va fi blocat.

(Nu știu dacă este nevoie de această diagramă, se pare că oricum totul ar trebui să fie clar...)

Desigur, compilarea manuală a unei astfel de liste nu este un lucru nobil, așa că am ajuns la concluzia că are sens să implementez așa-numitul „mod de învățare”. Modul în care toate apelurile către toate scripturile vor fi adăugate automat la lista fișierelor permise.

Ce dă? Puteți rula acest sistem în modul de învățare și puteți continua să utilizați site-ul dvs. Pe măsură ce o utilizați, baza de date va fi completată cu acele pagini pe care le utilizați (scuze pentru jocul de cuvinte). Și să spunem într-o lună - alta, lista ta va conține toate fișierele care au legătură cu site-ul tău (pe care l-ai accesat direct).

Și rețineți că lista va conține doar acele fișiere cu care veți lucra direct. Motorul obișnuit al site-ului are o grămadă de fișiere incluse (cu clase, funcții, biblioteci, module etc.), aceste fișiere nu vor fi incluse în această listă, iar accesul la ele va fi blocat în viitor la nivelul nostru. protecție (desigur, motoarele medii au protecție împotriva pornirii directe, dar dintr-o dată, undeva, această protecție este ratată).

Ce putem face

Deoarece acesta este un concept, nu știm cât de mult.

• Blocarea scripturilor neautorizate (de fapt funcția principală). Dar din nou, acest lucru este configurabil, nu puteți bloca conexiunea, ci doar notificați administratorul prin e-mail
• Notificarea cererilor nelegitime către administrator prin e-mail (raport scurt sau raport complet, acesta din urmă include antetele pachetelor și datele cererii POST, dacă există)
• Puteți specifica IP-ul administratorului, care va avea acces la orice scripturi, de ex. acest sistem nu îl va afecta (aceste IP-uri nu vor participa în modul de învățare). De exemplu, nu este nevoie să se închidă .htaccess software-ul precum PhpMyAdmin, SupexDumper și alte utilitare de sistem.
• Apropo, adresele IP acceptă măști simple =)
• Cod complet comentat și descriere detaliată a fiecărei directive de configurare
• Huh ce altceva...

Setare

Acum despre cum să construiți această protecție în site-ul dvs....

Pentru a face acest lucru, aveți nevoie de acces la fișierul php.ini

1. Mai întâi, descărcați scriptul în sine: PrependSecuritySystem
2. Despachetați conținutul arhivei (data.txt și main.php) într-un folder de pe server, de preferință într-un folder care nu este accesibil de pe web (nu este necesar, deoarece va funcționa în oricare, are sens să eliminați scenariul departe de ochii crackerului)
3. Deschideți fișierul main.php și editați setările. Este necesar să schimbați adresa ip și e-mailul administratorului. Restul setărilor depinde de dvs.
4. Setați permisiunile pentru fișierele despachetate. Sub niks, este de dorit să schimbați proprietarul pentru ambele fișiere, diferit de utilizatorul sub care rulează serverul web. Pentru dosar principal.php este necesar să dezactivați înregistrarea pentru toată lumea. Pentru dosar date.txt trebuie să setați permisiuni de citire și scriere pentru toată lumea (acest lucru este temporar, pentru perioada de antrenament)
5. Deschidem php.iniși introduceți următoarele:
   auto_prepend_file=[calea către fișierul main.php despachetat]
6. Din acest moment începe antrenamentul sistemului. Așteptăm o anumită perioadă de timp, suficientă, după părerea dumneavoastră, pentru pregătirea completă a acestui sistem.
7. La sfârșitul antrenamentului, deschideți fișierul principal.phpși editați constanta PSS_STATUS_BLOCK, setați-i valoarea la Adevărat, Salvați
8. Modificați permisiunile pentru fișierul data.txt. Interzicem editarea acestui fișier pentru toată lumea.
9. Acum sistemul a trecut la modul de blocare a scripturilor neautorizate

Prea mulți pași, desigur, dar mi se pare că până și un copil se descurcă.

Dacă trebuie să reinstruiți sistemul (de la zero sau suplimentare), atunci trebuie să:

1. Permite scrierea în fișierul data.txt
2. Ștergeți conținutul data.txt (NUMAI dacă trebuie să reinstruiți sistemul de la zero)
3. Editați constanta PSS_STATUS_BLOCKîn dosar principal.php setându-i valoarea la fals
4. Ne recalificăm...
5. La sfârșitul recalificării, edităm constanta PSS_STATUS_BLOCK restabilindu-i valoarea la Adevărat
6. Interzicem scrierea fișierului data.txt

Ei bine, acum despre cei tristi

Nu voi disimula, iar acum voi vorbi despre neajunsuri.

• Poate că principalul dezavantaj în comparație cu care se estompează toate celelalte este că acest sistem poate fi ocolit. Te intrebi: cum e? Totul este foarte simplu, directiv auto_prepend_file poate fi specificat și în .htaccess. Și dacă te apropii cu sobru, atunci dacă atacatorul a reușit brusc să umple carcasa, atunci cu siguranță va putea să-și umple .htaccessîn care poate dezactiva directiva inițială.
  Acest lucru funcționează numai sub apache, dar de exemplu sub nginx acest truc nu va funcționa (nginx nu are fișiere .htaccess). DAR! În Nginx, în general, puteți încărca .
• Un atacator poate edita un script „permis” dacă există drepturi valide pentru a face acest lucru, iar sistemul nostru, din păcate, nu poate face nimic în acest sens. Cu excepția cazului în care trebuie să setați permisiunile corecte pentru toate fișierele executabile
• Pe lângă PHP, există tot felul de perl, cgi și așa mai departe... acest sistem nu funcționează cu ele.
• Sarcina suplimentara. Dar vrtyali această sarcină va fi vizibilă.

De aceea, s-ar părea că un astfel de sistem original nu poate fi numit ideal. Dar este destul de potrivit ca o simplă măsură preventivă care nu va opri pe cei mai încăpățânați hoți cu nasul tare. Cel puțin, acest sistem va putea să ia timp unui atacator pentru a efectua un atac. De exemplu, sistemul va anunța administratorul cu privire la o tentativă de hacking, oferindu-i astfel administratorului posibilitatea de a remedia vulnerabilitatea până când atacatorul înțelege motivul eșecurilor sale.

Concluzie

Oricum, acesta este un concept, poate poți veni cu ceva mai bun pe baza lui. Sau poate că sistemul meu ți se potrivește.

În opinia mea, protecția rezonabilă nu se întâmplă prea mult. Depinde de tine să folosești ceva similar sau nu pe site-urile tale.

Uf. Ei bine, am scris, aproape toată ziua a trecut. Iertați-mă dacă am descris-o puțin haotic. În general, adresați-vă întrebările în comentarii, voi încerca să vă răspund.

PS: deși am codificat cât mai adecvat posibil, scriptul poate avea erori. Testat pe win/apache/php 5.2 - totul a fost ok.

PHP este unul dintre cele mai populare limbaje de programare open source pe partea de server. Este folosit nu numai pentru crearea de site-uri web, ci și ca limbaj de programare de uz general, precum și pentru scrierea părții server a diferitelor aplicații web.

Serverele web Apache, Nginx și Lighttpd pot executa scripturi PHP. De asemenea, PHP poate fi executat de către interpret direct din linia de comandă. Dar, deoarece PHP este instalat pe server, poate crea o serie de probleme de securitate, așa că trebuie utilizat cu grijă.

Toate programele conțin vulnerabilități și PHP nu face excepție. În acest articol, am adunat sfaturi pentru a vă ajuta să vă mențineți PHP în siguranță și, prin urmare, serverul dumneavoastră.

Toate sfaturile de mai jos se bazează pe faptul că PHP rulează sub Nginx sau Apache, interpretul PHP în sine nu este accesibil din rețeaua externă. Și acum, să trecem la luarea în considerare a modului în care se realizează protecția codului php, a site-ului și a serverului în ansamblu.

1. Cunoaște inamicul din vedere

Aplicațiile bazate pe PHP pot fi supuse diferitelor tipuri de atacuri, aici sunt principalele:

• XSS este o vulnerabilitate în aplicațiile web, cu ajutorul căreia atacatorii pot executa cod JavaScript arbitrar în browserul utilizatorului și, astfel, pot fura datele acestuia. Apare din cauza lipsei validării datelor în scripturi pentru corectitudine;
• injecție SQL este o vulnerabilitate în codul bazei de date. Dacă intrarea utilizatorului este filtrată incorect de script și utilizată pentru a forma o interogare la baza de date, atacatorii pot executa orice interogări în baza de date. Pentru a preveni această problemă, este recomandat să filtrați datele cu funcția mysql_real_escape_string() înainte de a trimite interogarea;
- permite vizitatorului să încarce fișiere pe serverul dvs. Prin încărcarea unui anumit tip de fișier, utilizatorii pot accesa sistemul sau chiar pot fura informații din baza de date, așa că trebuie avut grijă să încărcați doar poze;
• Execuție de la distanță- un atacator poate executa de la distanță fișiere php care se află pe server, așa că împreună cu capacitatea de a descărca fișiere PHP, acest lucru reprezintă un pericol grav;
• eval()- vă permite să executați cod PHP transmis într-un șir, adesea folosit de atacatori pentru a-și ascunde codul pe serverul dvs.;
• Atacul CSRF- vă permite să forțați utilizatorul să efectueze acțiuni nedorite în aplicațiile web. Dacă utilizatorul este administrator, acest lucru poate compromite întreaga aplicație.

2. Folosiți numai modulele necesare

Pentru a vizualiza toate modulele PHP compilate, rulați comanda:

Se recomandă utilizarea doar a celor mai necesare module pentru a crește securitatea. De exemplu, puteți dezactiva modulul sqlite. Pentru a face acest lucru, puteți șterge fișierul de configurare din /etc/php5/conf.d/. Dar pentru a-l elimina complet, trebuie să reconstruiți PHP fără acest modul.

3. Evitați scurgerile de informații

Există o linie în fișierul de configurare php.ini:

expose_php = Dezactivat

Dacă este setat la Activat, atunci PHP va trimite versiunea PHP ca răspuns la toate solicitările din antetul X-Powered-By. De asemenea, se recomandă ascunderea versiunii Apache și a altor informații. Protejarea php de hacking nu înseamnă doar o programare îngrijită, ci și ascunderea informațiilor despre sistem.

4. Dezactivați extensiile dinamice

PHP acceptă încărcarea dinamică a extensiilor. În mod implicit, sunt încărcate toate extensiile ale căror fișiere de configurare sunt în /etc/php/conf.d/. Sunt încărcate și modulele care sunt specificate de directiva de extensie în configurația principală php.ini. Putem elimina ceea ce nu avem nevoie.

5. Ieșire eroare

Mesajele de eroare conțin o mulțime de informații, nu le permit să fie vizualizate de toți utilizatorii site-ului. Faceți ca directiva display_errors să arate astfel:

display_errors = Dezactivat

Asigurați-vă că înregistrați toate erorile într-un fișier jurnal:

log_errors = Activat
error_log = /var/log/httpd/php_scripts_error.log

6. Preveniți încărcarea fișierelor

file_uploads = Dezactivat

Dar dacă o astfel de funcție este necesară, atunci este mai bine să limitați dimensiunea fișierului:

file_uploads = Activat
upload_max_filesize = 1M

Utilizatorii vor putea încărca fișiere nu mai mari de 1 megaoctet, astfel încât securitatea în php va fi mai mare.

6. Opriți executarea codului de la distanță

Dacă parametrul allow_url_fopen activat, php poate folosi funcții de fișier precum file_get_contents. Cu acesta, scriptul poate descărca fișiere de pe servere la distanță. Programatorii uită adesea să efectueze filtrarea corectă a datelor și astfel expun o vulnerabilitate. Pentru a dezactiva, modificați directiva:

allow_url_include = Dezactivat

7. Activați modul Safe SQL

În modul sigur SQL, interpretul ignoră toate argumentele transmise funcțiilor mysql_connectși mysql_pcconnect. Dar nu toate scripturile vor funcționa în acest mod, de exemplu, WordPress nu va funcționa, așa că folosește-l cu atenție. Pentru a activa, adăugați directiva:

magic_quotes_gpc=Dezactivat

9. Controlați dimensiunea POST

Metoda POST este utilizată atunci când browserul dorește să trimită o anumită cantitate de date către serverul web ca parte a unei solicitări, cum ar fi atunci când descarcă un fișier. Atacatorii pot folosi cereri mari pentru a risipi resursele serverului. Prin urmare, este mai bine să limitați dimensiunea:

post_max_size=1K

10. Controlul resurselor

Puteți specifica timpul maxim de execuție pentru fiecare script, cantitatea maximă de memorie și timpul maxim de citire a datelor, acest lucru va crește securitatea site-ului php în ceea ce privește atacurile DOS:

max_execution_time = 30
max_input_time = 30
limita_memorie = 40M

11. Dezactivați funcțiile periculoase

PHP conține multe funcții care pot fi folosite pentru a pirata un server, cum ar fi cele care permit executarea comenzilor shell. Pentru a dezactiva, este suficient să le enumerați în directiva disable_functions:

disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

12. Configurați Fastcgi pentru o securitate mai bună

PHP poate fi rulat prin FastCGI, acest lucru reduce utilizarea memoriei serverului dvs. web. Trebuie să includeți directiva force_redirect pentru a preveni executarea directă a scripturilor php din șirul de interogări, de exemplu, cgi-bin/php/hackerdir/backdoor.php. Pentru a face acest lucru, adăugați:

cgi.force_redirect=Activat

13. UID și GID al interpretului PHP

Dacă utilizați un server FastCGI extern, atunci trebuie să îl rulați ca utilizator non-root. Rulați php ca utilizator neprivilegiat. După cum știți, PHP are funcții care vă permit să executați comenzi shell. Este foarte nesigur dacă vor fi executate de la superutilizator.

14. Restricționați accesul la sistemul de fișiere

Directivă open_basedir vă permite să setați un director în care php poate accesa fișiere folosind funcții precum fopen, file_get_contents etc. Dacă fișierul se află în afara acestui director, PHP va refuza să-l deschidă. Nici măcar nu veți putea folosi link-uri simbolice.

open_basedir = "/var/www/html/"

15. Calea pentru stocarea sesiunilor

Este necesar nu numai să protejați site-ul php, astfel încât scripturile să nu dăuneze sistemului, ci și pentru ca utilizatorii să nu poată accesa fișierele php. Sesiunile în php vă permit să salvați anumite informații între solicitările utilizatorului. Calea în care vor fi stocate aceste informații este specificată în fișierul /etc/php/php.ini. Asigurați-vă că această cale se află în afara /var/www/ și că nu poate fi citită sau scrisă de alți utilizatori din sistem.

upload_tmp_dir = "/var/lib/php/session"

16. Țineți software-ul actualizat

Toate programele pot conține diverse vulnerabilități, așa că este important să efectuați actualizări regulate de sistem pentru a aplica toate corecțiile de securitate la timp. Nu numai PHP trebuie actualizat, ci întreaga stivă de software, inclusiv Apache.

17. Utilizați SELinux

SELinux este sistemul de securitate implicit în RedHat. Poate fi folosit pentru a preveni accesul neautorizat la fișiere și resurse. De exemplu, puteți seta politici de securitate pentru serverul web Apache sau pentru un server PHP independent. Aceasta este, de asemenea, o protecție excelentă pentru PHP și nu numai.

18. Instalați mod_security

Acesta este un modul Apache pentru detectarea și prevenirea aplicațiilor web. Poate proteja php și aplicația dvs. de atacurile XSS și SQL-Inj. De exemplu, pentru a preveni deschiderea fișierelor din /etc/ după instalarea unui modul, adăugați la fișierul de configurare Apache:

Și pentru a preveni injecția SQL:

SecFilter „șterge[[:spațiu:]]+din”
SecFilter „select.+from”

19. Vizualizați reviste

Examinați în mod regulat fișierele jurnal Apache și PHP, puteți obține o perspectivă asupra modului în care funcționează serverul și puteți verifica nivelul de securitate.

coada -f /var/log/httpd/error_log
$ tail -f /var/log/httpd/php_scripts_error.log

concluzii

În acest articol, am analizat mai multe modalități de a crește securitatea unui site PHP. Ele vă vor ajuta să vă mențineți serverul cât mai sigur posibil. Poate că acestea nu sunt toate opțiunile disponibile, dacă știți și alte modalități, scrieți în comentarii.

La sfârșitul prelegerii despre securitatea scrierii de scripturi în PHP: