Este mutarea fișierului wp-config în afara root-ului web cu adevărat benefică?

Question

Este mutarea fișierului wp-config în afara root-ului web cu adevărat benefică?

13 iul. 2012, 18:26:11

Vizualizări: 76.6K

Voturi: 156

Una dintre cele mai comune practici de securitate din zilele noastre pare să fie mutarea fișierului wp-config.php cu un director mai sus față de document root-ul vhost-ului. Nu am găsit niciodată o explicație bună pentru asta, dar presupun că este pentru a minimiza riscul ca un script malițios sau infectat din webroot să poată citi parola bazei de date.

Dar, tot trebuie să permiți WordPress-ului să îl acceseze, deci trebuie să extinzi open_basedir pentru a include directorul de deasupra document root-ului. Oare acest lucru nu anulează întregul scop și, de asemenea, nu expune potențial atacatorilor log-urile serverului, backup-urile etc?

Sau tehnica încearcă doar să prevină o situație în care wp-config.php ar fi afișat ca text simplu oricui solicită http://example.com/wp-config.php, în loc să fie interpretat de motorul PHP? Aceasta pare o situație foarte rară și nu ar depăși dezavantajele expunerii log-urilor/backup-urilor/etc la cereri HTTP.

Poate este posibil să-l muți în afara document root-ului în unele configurații de hosting fără a expune alte fișiere, dar nu în alte configurații?

Concluzie: După multe discuții pe această temă, au ieșit la iveală două răspunsuri pe care le consider autoritare. Aaron Adams prezintă argumente bune în favoarea mutării wp-config, iar chrisguitarguy prezintă argumente bune împotriva acesteia. Acestea sunt cele două răspunsuri pe care ar trebui să le citiți dacă sunteți nou în discuție și nu doriți să citiți întregul conținut. Celelalte răspunsuri sunt fie redundante, fie inexacte.

Ian Dunn

4.86K

securitate personalizare wp config

Comentarii

Nu este cu adevărat necesar să îți promovezi alegerea de răspunsuri și să respingi toate celelalte răspunsuri în întrebarea ta. După cum poți vedea mai jos, asta este scopul sistemului de votare stackexchange - să votezi în sus răspunsurile care au sens pentru oameni, în timp ce cei care pun întrebări ar trebui să folosească mecanismul de "răspuns acceptat" și propriile voturi în sus/jos.

Kzqai

20 ian. 2014 18:53:59

Nu fac asta pentru 99% dintre întrebările pe care le-am pus, dar am considerat că este potrivit în acest caz specific. Există 8 răspunsuri la întrebare, unele dintre ele destul de lungi/complexe, iar unele au multe voturi în sus în ciuda faptului că conțin informații inexacte sau nu adaugă nimic la discuție. Cred că oferirea unei concluzii semi-autoritative este utilă pentru cei care citesc thread-ul pentru prima dată. Ca întotdeauna, cititorii sunt liberi să-și formeze propria opinie; eu doar îmi ofer părerea ca OP.

Ian Dunn

21 ian. 2014 02:15:01

@Kzqai: Sistemul de votare "stackexchange" este un proces democratic, iar participanții sunt adesea 1) neclari în legătură cu ceea ce întreabă de fapt OP sau încearcă să rezolve, și 2) nu înțeleg validitatea unui anumit răspuns. După ce răspunsurile au sosit și voturile au fost exprimate, este mai mult decât util ca OP să clarifice acele răspunsuri care au oferit ajutor. La urma urmei, OP este singurul care știe, și mi-aș dori ca mai mulți OP să facă acest lucru. Da, oamenii "votează în sus răspunsurile care au sens pentru ei", dar hai să lăsăm OP să aibă ultimul cuvânt cu privire la ce are sens pentru el.

Mac

14 iul. 2017 16:55:12

Întrebarea ta este una bună. Totuși, comentariile tale la răspunsuri arată că ai o configurare foarte specifică în minte, cu constrângeri externe foarte reale (adică nu controlate de tine). Ar fi fost mai corect să le menționezi de la bun început. Face diferența dacă am control total asupra serverului web și PHP, precum și systemd, să zicem, sau dacă open_basedir este singura mea modalitate de a afecta securitatea într-un mod tangibil. De asemenea: "argumentul bun împotrivă" ar trebui să arate cum este dăunător, mai degrabă decât să enumere motive pentru care această măsură singulară poate să nu fie suficientă. Și ține cont de publicul țintă.

0xC0000022L

18 aug. 2021 11:32:13

Toate răspunsurile la întrebare

Comentarii

Dacă ai o eroare în Apache, Linux sau în mintea administratorului, ești compromis în orice caz. În scenariul tău nu explici de ce ar fi mai probabil ca o configurăre greșită să apară la rădăcina site-ului web decât în orice alt loc de pe server. Un Apache configurat greșit poate accesa probabil /../config.php la fel de ușor ca pe /config.php

Mark Kaplun

4 dec. 2012 23:14:30

Nu ești "compromis în orice caz." Este foarte probabil, și chiar demonstrabil, că o eroare ar duce la resetarea rădăcinii web la valoarea implicită, caz în care nu ești "compromis" – wp-config.php tău rămâne în siguranță. Și este extrem de improbabil – atât de mult încât este practic imposibil – ca o eroare să reseteze rădăcina web exact în directorul în care ai plasat wp-config.php.

Aaron Adams

4 dec. 2012 23:23:34

Cât de probabilă este o astfel de eroare? Nu sunt expert în securitate, dar nu am auzit niciodată de un astfel de vector de atac folosit în practică. Sunt împotriva recomandării acestei metode pentru că, odată ce trebuie să întreții site-ul, nu vei ști unde este wp-config-ul și probabil va invalida majoritatea tutorialelor care ating acest fișier într-un fel. Tu, eu și restul comentatorilor de aici vom înțelege ce s-a întâmplat, dar pentru persoanele mai puțin experimentate va fi un moment lung și confuz de WTF.

Mark Kaplun

5 dec. 2012 07:46:36

@MarkKaplun Argumentul "Oamenii care nu citesc Stack Exchange ar putea fi confuzi" este un argument destul de slab împotriva unei practici de securitate recomandate pe Stack Exchange. Când mai mulți oameni înțeleg pericolele reale ale lăsării fișierelor de configurare sensibile în rădăcina web, mai mulți oameni vor muta acele fișiere în afara rădăcinii web, și mai multe tutoriale WordPress vor fi scrise pentru a ajuta utilizatorul să localizeze wp-config.php. Dacă crezi că confortul este mai important decât securitatea, aceasta este opinia ta; doar fă clar, atunci, că recomanzi utilizatorilor să prioritizeze confortul în locul securității.

Aaron Adams

5 dec. 2012 20:27:27

Hei Aaron, mulțumesc pentru răspunsul detaliat și gândit. Ai dreptate că doar schimbarea parolei după o intruziune nu este suficientă. Totuși, încă nu sunt convins de anecdota ta despre Plesk. Cu siguranță este o problemă, dar nu cred că mutarea wp-config este soluția potrivită pentru acea problemă. La fel pentru resetarea configurației vhost, etc. Dacă aplicația ta are nevoie de suficientă securitate încât să fii îngrijorat de aceste tipuri de vulnerabilități, atunci chiar trebuie să le abordezi într-un mod mai direct. de ex., nu folosi Plesk, pentru că va fi întotdeauna vulnerabil; asigură-te că configurația vhost este securizată implicit...

Ian Dunn

6 dec. 2012 01:47:29

Arată celelalte 11 comentarii

Cel mai mare lucru este că wp-config.php conține informații sensibile: numele de utilizator/parola bazei de date, etc.

Deci ideea: mutați-l în afara rădăcinii documentului și nu trebuie să vă faceți griji pentru nimic. Un atacator nu va putea accesa niciodată acel fișier dintr-o sursă externă.

Totuși, iată problema: wp-config.php nu afișează niciodată nimic pe ecran. Acesta doar definește diverse constante care sunt utilizate în întreaga instanță WordPress. Astfel, singurul mod în care cineva va vedea conținutul acelui fișier este dacă ocolesc interpretorul PHP al serverului dvs. - fac ca fișierul .php să fie afișat ca text simplu. Dacă se întâmplă acest lucru, sunteți deja în probleme: au acces direct la serverul dvs. (și probabil permisiuni root) și pot face orice doresc.

Voi spune direct nu există niciun beneficiu în mutarea wp-config în afara rădăcinii documentului din perspectiva securității — din motivele de mai sus și acestea:

Puteți restricționa accesul la fișier prin configurația gazdei virtuale sau .htaccess — limitând efectiv accesul extern la fișier în același mod în care l-ar limita mutarea în afara rădăcinii documentului
Puteți asigura că permisiunile fișierului sunt stricte pentru wp-config pentru a preveni ca orice utilizator fără privilegii suficiente să citească fișierul chiar dacă obțin acces (limitat) la serverul dvs. prin SSH.
Informațiile dvs. sensibile, setările bazei de date, sunt utilizate doar pe un singur site. Deci, chiar dacă un atacator ar obține acces la acele informații, singurul site afectat ar fi instalația WordPress căreia îi aparține fișierul wp-config.php. Mai important, acel utilizator al bazei de date are permisiuni doar pentru a citi și scrie în baza de date a acelei instanțe WordPress și nimic altceva — niciun acces pentru a acorda alte permisiuni altor utilizatori. Adică, cu alte cuvinte, dacă un atacator obține acces la baza dvs. de date, este pur și simplu o chestiune de restaurare dintr-o copie de rezervă (vezi punctul 4) și schimbarea utilizatorului bazei de date
Faceți backup frecvent. "Frecvent" fiind un termen relativ: dacă publicați 20 de articole în fiecare zi, ar fi bine să faceți backup în fiecare zi sau la câteva zile. Dacă publicați o dată pe săptămână, un backup săptămânal este probabil suficient.
Aveți site-ul sub control al versiunilor (ca acesta), ceea ce înseamnă că, chiar dacă un atacator obține acces, puteți detecta cu ușurință modificările de cod și le puteți anula. Dacă un atacator are acces la wp-config, probabil a modificat și altceva.
Informațiile despre baza de date sunt singurele lucruri cu adevărat sensibile din wp-config, și pentru că sunteți atenți la asta (vezi punctul 3 și 4), nu este o mare problemă. Sărurile și altele asemenea pot fi schimbate oricând. Singurul lucru care se întâmplă este că invalidează cookie-urile utilizatorilor autentificați.

Pentru mine, mutarea wp-config în afara rădăcinii documentului miroase a securitate prin obscuritate — ceea ce este foarte mult un om de paie.

chrisguitarguy

21.5K

18 iul. 2012 03:17:03

Comentarii

Da, cam asta am crezut și eu. Mă bucur să știu că nu sunt singur :) Aș vrea să las întrebarea deschisă încă o zi sau două, pentru cazul în care cineva are un contraargument convingător, dar până acum acesta pare să fie răspunsul corect.

Ian Dunn

18 iul. 2012 04:56:05

Corecție minoră: Nu există niciun beneficiu de securitate în mutarea fișierului wp-config.php în afara rădăcinii documentului. Există alte beneficii, care nu sunt legate de securitate și care se aplică doar în configurații neobișnuite.

Otto

12 aug. 2012 18:19:02

Bun punct. Am editat.

chrisguitarguy

12 aug. 2012 19:36:42

Doar pentru a demonta un posibil mit - nu este posibil ca ceva să meargă prost pe partea de server - caz în care codul php este afișat pe ecran?

Stephen Harris

12 aug. 2012 21:49:17

Desigur. Dacă mod_php nu funcționează sau fișierele PHP nu sunt transmise interpretorului PHP, este posibil. Dacă rulezi o configurare FCGI, același lucru este posibil dacă fișierele PHP nu sunt transmise procesului fcgi pentru interpretare. Ambele situații indică probleme destul de mari care, totuși, sunt puțin probabile să apară.

chrisguitarguy

12 aug. 2012 22:17:30

Arată celelalte 7 comentarii

Cred că răspunsul lui Max este unul competent și acesta este o parte a poveștii. WordPress Codex oferă mai multe sfaturi:

De asemenea, asigură-te că doar tu (și serverul web) poți citi acest fișier (în general înseamnă permisiunea 400 sau 440).

Dacă folosești un server cu .htaccess, poți adăuga acest cod în acel fișier (la început) pentru a interzice accesul oricui încearcă să-l acceseze:
<files wp-config.php>
order allow,deny
deny from all
</files>

Notă: setarea permisiunii 400 sau 440 pe wp-config.php poate împiedica plugin-urile să scrie sau să modifice fișierul. Un exemplu concret ar fi plugin-urile de caching (W3 Total Cache, WP Super Cache, etc.). În acest caz, aș opta pentru permisiunea 600 (permisiunea implicită pentru fișierele din directorul /home/user).

its_me

4.51K

13 iul. 2012 19:13:49

Comentarii

Max are răspunsul. +1 pentru el. Eu doar încerc să-l extind.

its_me

13 iul. 2012 19:15:39

Aahan Krish, ai nimerit exact în punctul cheie. Mulțumesc pentru completare.

Max Yudin

13 iul. 2012 19:26:34

Deci dacă folosești htaccess pentru a bloca cererile HTTP către wp-config.php, nu se obține același rezultat ca și mutarea fișierului în afara rădăcinii documentului, dar fără a expune jurnalele/backup-urile/etc?

Ian Dunn

13 iul. 2012 20:59:10

@IanDunn Depinde de care este rădăcina documentului — (1) Dacă WordPress este găzduit într-un director din public_html, mutarea fișierului wp-config.php în afara directorului înseamnă că acesta va fi în directorul public_html. În acest caz, va trebui să folosești reguli htaccess pentru a interzice cererile HTTP către wp-config.php. (2) Dacă WordPress este instalat direct în directorul public_html, un nivel mai sus => îl vei muta în directorul /home/user. În acest caz ești destul de sigur, deoarece fișierul este în afara rădăcinii documentului. Poți să setezi permisiunile fișierului la 600 (sau chiar mai stricte, 440 sau 400).

its_me

13 iul. 2012 21:10:23

@IanDunn Cum am spus, aceasta este înțelegerea mea de bază și nu sunt un expert în securitate. :)

its_me

13 iul. 2012 21:10:58

Arată celelalte 2 comentarii

Cineva ne-a cerut să clarificăm acest aspect și voi răspunde aici.

Da, există beneficii de securitate prin izolarea fișierului wp-config.php din directorul rădăcină al site-ului tău.

1- Dacă handler-ul PHP tău este corupt sau modificat într-un fel, informațiile despre baza de date nu vor fi expuse. Și da, am văzut acest lucru întâmplându-se de câteva ori pe host-uri shared în timpul actualizărilor serverului. Da, site-ul va fi stricat în acea perioadă, dar parolele tale vor rămâne intacte.

2- Cele mai bune practici recomandă întotdeauna izolarea fișierelor de configurare de fișierele de date. Da, este greu de realizat acest lucru cu WordPress (sau orice altă aplicație web), dar mutarea lui în sus oferă un pic de izolare.

3- Adu-ți aminte vulnerabilitatea PHP-CGI, unde oricine putea să treacă ?-s către un fișier și să vadă sursa. http://www.kb.cert.org/vuls/id/520827

La final, acestea sunt detalii mici, dar ajută la minimizarea riscului. Mai ales dacă ești într-un mediu shared, unde oricine poate accesa baza ta de date (tot ce au nevoie este un user/parolă).

Dar nu lăsa mici distracții (optimizări premature) să stea în fața ceea ce este cu adevărat necesar pentru a securiza corect un site:

1- Ține-l întotdeauna actualizat

2- Folosește parole puternice

3- Restricționează accesul (prin permisiuni). Avem un post despre asta aici:

http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html

mulțumesc,

Sucuri

289

12 sept. 2012 15:41:08

Comentarii

Băieți, mulțumesc pentru părerile voastre. Cred că am abordat deja majoritatea acestor puncte în celelalte răspunsuri și comentariile aferente. 1) Da, acest lucru este posibil, dar rar; 2) Da, există beneficii, dar sunt minore; 3) Da, acest lucru este posibil, dar acest tip de vulnerabilitate este puțin probabil să se repete, iar protejarea împotriva ei este cam ca și cum ai juca whac-a-mole sau ai obliga oamenii să-și scoată pantofii în aeroporturi pentru că un tip a ascuns o bombă în pantof o dată. Este o reacție exagerată și puțin probabil să aibă beneficii viitoare.

Ian Dunn

12 sept. 2012 18:01:18

În diversele discuții, întrebarea a fost rafinată de la "Există vreun beneficiu?" la "Ok, există câteva beneficii, dar ele depășesc riscurile?" Principalul risc la care mă refer este faptul că trebuie să extinzi domeniul de acțiune al openbase_dir pentru a permite PHP-ului să acceseze scripturi în afara rădăcinii web. Multe configurații de hosting – inclusiv cele care folosesc Plesk, care sunt destul de răspândite – stochează jurnale, backup-uri, zone FTP private care ar trebui să fie izolate de rădăcina web, etc. în directorul de deasupra rădăcinii web. Așadar, a oferi PHP-ului acces la acel director poate reprezenta o vulnerabilitate serioasă.

Ian Dunn

12 sept. 2012 18:04:58

@IanDunn de când raritatea unui eveniment a fost un contraargument valid pentru a nu lua măsuri preventive de securitate care să abordeze un astfel de eveniment improbabil? Apropo, punctul tău despre locurile în care PHP poate deschide fișiere poate fi rezolvat în zilele noastre prin hardening cu systemd. Întregul punct al securității IT este că atacatorii au la dispoziție un număr infinit de căi de incursiune, în timp ce apărătorii pot apăra doar împotriva vectorilor de atac cunoscuți. Prin urmare, este obișnuit să combini cât mai multe măsuri preventive posibile pentru a oferi o rețea de securitate, în loc să te bazezi pe un singur nod.

0xC0000022L

18 aug. 2021 11:21:23

Cu siguranță DA.

Când muți fișierul wp-config.php în afara directorului public, îl protejezi de accesul prin browser în cazul în care handler-ul PHP este modificat din greșeală sau cu intenții malicioase.

Citirea datelor de conectare la baza de date (login/parolă) devine posibilă doar dacă serverul este grav infectat din cauza unei administrări defectuoase. Amendă administratorul și optează pentru un furnizor de hosting mai bine întreținut și mai sigur. Deși acest lucru ar putea fi mai costisitor.

Max Yudin

6.38K

13 iul. 2012 19:07:26

Comentarii

Dacă un atacator are acces suficient pentru a schimba handler-ul PHP, ești deja compromis. Schimbările accidentale sunt foarte rare în experiența mea, iar în acest caz ar fi ușor să schimbi parola. Având în vedere aceste lucruri, crezi că încă merită riscul de a expune jurnalele/backup-urile/etc din cauza extinderii domeniului open_basedir?

Ian Dunn

13 iul. 2012 21:01:21

Niciodată nu am avut acces -rwx la directoarele de deasupra public_html, așa că nu am fost niciodată familiarizat cu open_basedir. Jurnalele mele sunt într-un director separat, la fel și backup-urile. Cred că așa funcționează majoritatea hosturilor partajate.

Max Yudin

13 iul. 2012 21:35:40

Hosturile variază foarte mult; nu există o structură standard de directoare. Plesk (unul dintre cele mai populare panouri de control pentru hosturi partajate) plasează jurnalele în /var/www/vhosts/example.com/statistics/logs iar root-ul documentelor este /var/www/vhosts/example.com/httpdocs. Mutarea wp-config.php în /var/www/vhosts/example.com/wp-config.php ar necesita acordarea accesului scripturilor la întregul director example.com.

Ian Dunn

14 iul. 2012 03:03:12

Doar din curiozitate, unde sunt stocate jurnalele și backup-urile dacă nu sunt în directorul domeniului? Se accesează printr-un panou de control sau ceva de genul?

Ian Dunn

14 iul. 2012 03:04:10

Da, prin intermediul unui panou de control.

Max Yudin

14 iul. 2012 10:37:56

Arată celelalte 2 comentarii

Vreau să clarific, de dragul argumentului, că mutarea fișierului wp_config.php nu înseamnă neapărat că trebuie să-l mutați doar în directorul părinte. Să presupunem că aveți o structură precum /root/html, unde html conține instalarea WordPress și tot conținutul HTML. În loc să mutați wp_config.php în /root, ați putea să-l mutați într-un loc precum /root/secure... care este atât în afara directorului html, cât și în afara directorului rădăcină al serverului. Desigur, trebuie să vă asigurați că PHP poate rula și în acest folder secure.

Deoarece WordPress nu poate fi configurat să caute wp_config.php într-un folder frate precum /root/secure, trebuie să faceți un pas suplimentar. Am lăsat wp_config.php în /root/html și am extras părțile sensibile (datele de conectare la baza de date, salt-ul, prefixul tabelelor) și le-am mutat într-un fișier separat numit config.php. Apoi adăugați comanda PHP include în wp_config.php, astfel: include('/home/content/path/to/root/secure/config.php');

Aceasta este, în esență, ceea ce am făcut în configurația mea. Acum, pe baza discuției de mai sus, încă evaluez dacă este necesar sau chiar o idee bună. Dar am vrut să adaug că configurația de mai sus este posibilă. Nu expune backup-urile și alte fișiere din rădăcină, iar atâta timp cât folderul secure nu este configurat cu propriul său URL public, nu poate fi accesat prin navigare.

Mai mult, puteți restricționa accesul la folderul secure creând un fișier .htaccess acolo cu:

order deny,allow
deny from all
allow from 127.0.0.1

Michael

143

3 oct. 2012 16:44:03

Comentarii

Hei Michael, mulțumesc pentru informații. Ai încercat însă într-un mediu real să verifici dacă funcționează? Cred că directiva open_basedir acceptă un întreg arbore, așa că pentru a accesa /root/secure din /root/html, ar trebui să setezi open_basedir la /root.

Ian Dunn

3 oct. 2012 17:52:20

Pentru ca ideea ta să funcționeze, cred că ar trebui să configurezi structura de directoare astfel: /root/httpdocs/config/accessible, unde httpdocs conține jurnale, backup-uri etc.; config conține wp-config.php, iar accessible conține WordPress și tot conținutul. Ar trebui să modifici configurația vhost etc. pentru a remapa root-ul documentelor către accessible. Totuși, nu văd niciun beneficiu față de simpla interzicere a cererilor HTTP către wp-config în configurația implicită.

Ian Dunn

3 oct. 2012 17:53:41

Conform http://www.php.net/manual/en/ini.core.php#ini.open-basedir: "Pe Windows, separă directoarele cu punct și virgulă. Pe toate celelalte sisteme, separă directoarele cu două puncte. Ca modul Apache, căile open_basedir din directoarele părinte sunt acum moștenite automat." Deci poți seta mai multe directoare, nu este nevoie să fie într-un singur arbore.

Michael

3 oct. 2012 22:34:38

Tocmai am testat asta și se pare că ai dreptate. Totuși, încă nu sunt sigur ce beneficiu de securitate are această abordare în comparație cu simpla interzicere a accesului la fișier prin Apache.

Ian Dunn

4 oct. 2012 01:05:53

@IanDunn a răspuns bine în răspunsul lui Aaron Adams

AndrewC

5 dec. 2012 03:02:10

Arată celelalte 1 comentarii

Există o mulțime de teme și plugin-uri prost scrise care permit atacatorilor să injecteze cod (amintiți-vă de problema de securitate cu Timthumb). Dacă aș fi un atacator, de ce aș căuta wp-config.php? Pur și simplu injectez acest cod:

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

Puteți încerca să ascundeți wp-config.php. Atâta timp cât WordPress face toate informațiile sensibile accesibile global, nu are niciun beneficiu să ascunzi wp-config.php.

Partea rea în wp-config.php nu este că conține date sensibile. Partea rea este să definești datele sensibile ca constante accesibile global.

Actualizare

Vreau să clarific problemele cu define() și de ce este o idee proastă să definești date sensibile ca constante globale.

Există multe modalități de a ataca un site web. Injectarea de scripturi este doar una dintre ele.

Să presupunem că serverul are o vulnerabilitate care permite unui atacator să acceseze un dump de memorie. Atacatorul va găsi în dump-ul de memorie toate valorile tuturor variabilelor. Dacă definești o constantă globală, aceasta trebuie să rămână în memorie până când scriptul se termină. Creând o variabilă în loc de o constantă, există o șansă bună ca colectorul de gunoi să suprascrie (sau să elibereze) memoria după ce variabila nu mai este necesară.

O metodă mai bună de a proteja datele sensibile este să le ștergi imediat după ce le folosești:

$db_con = new stdClass();
$db_con->db_user = 'username';
$db_con->password = 'password';
$db_con->host = 'localhost';

$db_handler = new Database_Handler( $db_con );

$db_con = null;

După utilizarea datelor sensibile, atribuirea la null va suprascrie datele din memorie. Un atacator trebuie să obțină dump-ul de memorie exact în momentul în care $db_con conține datele sensibile. Și acesta este un timp foarte scurt în exemplul de mai sus (dacă clasa Database_Handler nu salvează o copie a acestora).

Ralf912

5.31K

19 nov. 2012 22:57:05

Comentarii

Acest răspuns nu abordează direct întrebarea. Orice autor de plugin poate avea o zi de câmp cu WordPress dacă te convinge să instalezi codul lor și are intenții malefice. Nu este diferit de a instala în mod voluntar un virus pe sistemul tău. Acest argument pentru a nu muta wp-config.php este inutil. Este ca și cum ai spune că a instala în mod voluntar o bombă în mașină face inutilă activarea alarmei de mașină. Din punct de vedere tehnic este adevărat, dar WTF?!?

Lance Cleveland

6 dec. 2012 07:51:56

Nu, nu este inutil. Întrebarea este: Pot proteja contul de bază de date prin ascunderea wp-config.php. Iar răspunsul este clar: Nu. Este la fel ca și cum ai întreba "Pot proteja mașina mea împotriva bombelor cu o alarmă de mașină?" Nu există alt beneficiu în a ascunde wp-config.php în afara protejării accesului la baza de date sau a accesului FTP. Ambele sunt în domeniul global. Sunt sigur că există mai multe modalități pentru atacatori de a obține acces la variabile globale fără a injecta cod.

Ralf912

6 dec. 2012 09:51:28

Nu văd "pot proteja contul de bază de date prin ascunderea wp-config.php" în întrebarea originală. Întrebarea originală a fost "are sens să mutăm wp-config.php". Răspunsul este categoric da, în opinia mea. Este ca și cum ai întreba dacă ar trebui să încuie ușa de la intrare când pleci. A spune "cineva poate sparge cu ușurință o fereastră și să intre oricum, deci de ce să te obosești" nu răspunde la esența întrebării. În opinia mea, întrebarea a fost următoarea: "Merită efortul suplimentar de a muta wp-config.php? Există vreun beneficiu în a face acest lucru?". Da. Cel puțin, ține departe hackerii leneși.

Lance Cleveland

10 dec. 2012 17:28:25

Una dintre cele mai bune practici de securitate comune... Ai omis un punct foarte (foarte, foarte) important: Ce interesează un atacator? Și nu este modul în care ai formatat wp-config.php. Un atacator este interesat de valorile pe care le-ai definit în wp-config. Luând exemplul tău cu ușa din față: Ascunderea wp-config-ului tău este la fel ca și cum ai încuia ușa din față, dar ai pune tot aurul neprotejat în grădină. Toate valorile definite în wp-config sunt definite global. Deci sunt toate accesibile în afara wp-config. Chiar dacă ascunzi wp-config-ul tău, valorile sunt în continuare prezente.

Ralf912

11 dec. 2012 13:21:45

Cred cei care susțin mutarea lui încearcă să se protejeze împotriva scenariilor în care wp-config.php ar putea fi afișat în text simplu printr-o cerere HTTP, mai degrabă decât scenarii în care ar putea fi expus altui cod PHP rulează pe gazdă.

Ian Dunn

12 dec. 2012 00:40:19

Arată celelalte 2 comentarii

Scuze că revin la un subiect vechi, dar nu există o soluție evidentă pentru toate astea? Știm că există câteva beneficii de securitate prin mutarea fișierului wp-config.php în afara directorului rădăcină al WordPress. Unii ar argumenta că beneficiile sunt minime, alții nu ar fi de acord.

Pe de altă parte, pot exista câteva dezavantaje în mutarea fișierului din locația implicită, cum ar fi ruperea unor plugin-uri care nu au funcționalitatea de a căuta fișierul wp-config.php în alte locații.

Cel mai evident lucru pentru mine este să creez un fișier secret-info.php în afara directorului rădăcină al WordPress, care să conțină variabile pentru toate numele de utilizator și parolele, de exemplu:

$userName = "user";

$databasePassword = "12345";

Lasă fișierul wp-config.php în locația implicită din directorul rădăcină al WordPress, elimină valorile numelui de utilizator și parolei din wp-config.php, dar păstrează totul altceva. Apoi pur și simplu referențiază variabilele $userName și $databasePassword prin includerea fișierului secret-info.php în wp-config.php, astfel:

require('CALE-CĂTRE-FIȘIER/secret-info.php');

Pare a fi soluția evidentă, omit eu ceva aici?

User

100

21 iul. 2020 20:49:08

Comentarii

Este de fapt un lucru foarte bun să adaugi un răspuns la o întrebare veche, există chiar și un insignă pentru asta. WPSE este menit să fie o bază de cunoștințe, mai degrabă decât un forum.

Ian Dunn

22 iul. 2020 07:36:24

După atâția ani, WordPress încă plasează implicit fișierul wp-config.php în directorul rădăcină, accesibil prin web, fără măcar să adauge reguli .htaccess pentru a preveni accesul la el. Majoritatea serviciilor de hosting partajat care oferă instalarea WordPress cu un singur click fac la fel. Rezultatul este că majoritatea site-urilor WordPress sunt configurate astfel și nu cred că am auzit vreodată pe cineva spunând "site-ul meu a fost hackuit pentru că wp-config.php era în directorul rădăcină".

Pentru a folosi informațiile din acest fișier, un atacator are nevoie de acces la serverul de baze de date, probabil prin adăugarea de scripturi pe un server de aplicații. Dacă rulezi un VPS, asta înseamnă că dacă un atacator are o astfel de capabilitate, este "game over" pentru tine oricum, iar pe hosting partajat, ei probabil izolează accesul la baza de date pe bază de utilizator, așa că nu este ceva trivial de făcut nici în acest caz.

Rezultatul este că sistemul de verificare a sănătății din WordPress 5.2+ nu va sugera mutarea fișierului și nu am auzit de vreun plugin de securitate care să facă asta.

Așadar, informațiile practice pe termen lung arată că, teoretic, este mai bine să faci acest lucru, dar în mare parte este doar o simulare de securitate.

Problema reală cu mutarea wp-config.php într-un director superior este că practic împiedică instalarea altui WordPress în același director cu primul, lucru pe care mulți oameni îl fac. Soluția este să păstrezi wp-config.php în locația implicită, dar să adaugi în el cod care încarcă configurația reală dintr-un alt fișier situat în afara rădăcinii web și probabil denumit într-un mod specific site-ului, nu generic.

Problema cu această abordare este că multe tutoriale WordPress nici măcar nu menționează posibilitatea de a avea wp-config.php într-un alt loc, iar persoanele care vor veni după tine vor avea un moment de confuzie încercând să urmărească instrucțiunile care le cer să adauge un define în fișierul wp-config.php.

Mark Kaplun

23.7K

10 aug. 2021 09:26:11

Pe lângă beneficiile de securitate, această abordare îți permite să păstrezi instanța WordPress sub controlul versiunilor, menținând în același timp fișierele de bază WordPress ca submodul/extern. Acesta este modul în care Mark Jaquith și-a configurat proiectul WordPress-Skeleton. Pentru detalii, consultă https://github.com/markjaquith/WordPress-Skeleton#assumptions.

Emyr Thomas

361

18 iul. 2012 00:18:38

Comentarii

El a configurat fișierul în rădăcina documentului, nu în afara acesteia, deci nu este relevant pentru această întrebare. Tehnica despre care a întrebat specifică să muți wp-config.php cu un director deasupra rădăcinii documentului vhost-ului, nu doar cu un director deasupra folderului de instalare WordPress. Scopul principal este să-l scoți din folderul care poate fi citit prin cereri HTTP.

Ian Dunn

18 iul. 2012 01:59:08

Aaron Adams 1.72K · Accepted Answer · 2012-12-04T21:29:58Z

Răspuns scurt: da

Răspunsul la această întrebare este da și a spune altceva este probabil iresponsabil.

Răspuns lung: un exemplu din lumea reală

Permiteți-mi să ofer un exemplu foarte real, de pe serverul meu foarte real, unde mutarea fișierului wp-config.php în afara rădăcinii web a prevenit în mod specific capturarea conținutului său.

Bug-ul:

Uită-te la această descriere a unui bug în Plesk (reparat în 11.0.9 MU#27):

Plesk resetează redirecționarea subdomeniilor după sincronizarea abonamentului cu planul de hosting (117199)

Sună inofensiv, nu?

Ei bine, iată ce am făcut pentru a declanșa acest bug:

Am configurat un subdomeniu să redirecționeze către alt URL (de ex. site.staging.server.com către site-staging.ssl.server.com).
Am schimbat planul de servicii al abonamentului (de ex. configurația PHP).

Când am făcut acest lucru, Plesk a resetat subdomeniul la valorile implicite: servind conținutul din ~/httpdocs/, fără interpretoare (de ex. PHP) active.

Și nu am observat. Timp de săptămâni.

Rezultatul:

Cu wp-config.php în rădăcina web, o cerere către /wp-config.php ar fi descărcat fișierul de configurare WordPress.
Cu wp-config.php în afara rădăcinii web, o cerere către /wp-config.php a descărcat un fișier complet inofensiv. Fișierul real wp-config.php nu a putut fi descărcat.

Astfel, este evident că mutarea fișierului wp-config.php în afara rădăcinii web poate avea beneficii reale de securitate în lumea reală.

Cum să muți `wp-config.php` în orice locație pe serverul tău

WordPress va căuta automat un director deasupra instalării WordPress pentru fișierul wp-config.php, așa că dacă l-ai mutat acolo, ai terminat!

Dar dacă l-ai mutat altundeva? Simplu. Creează un nou fișier wp-config.php în directorul WordPress cu următorul cod:

<?php

/** Calea absolută către directorul WordPress. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Locația fișierului tău de configurare WordPress. */
require_once(ABSPATH . '../phpdocs/wp-config.php');

(Asigură-te să modifici calea de mai sus cu calea reală a fișierului tău wp-config.php mutat.)

Dacă întâmpini o problemă cu open_basedir, adaugă pur și simplu noua cale în directiva open_basedir din configurația ta PHP:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

Atât!

Contrazicerea argumentelor opuse

Orice argument împotriva mutării fișierului wp-config.php în afara rădăcinii web pare să se bazeze pe presupuneri false.

Argumentul 1: Dacă PHP este dezactivat, deja sunt înăuntru

Singurul mod în care cineva va vedea conținutul [wp-config.php] este dacă ocolesc interpretorul PHP al serverului tău… Dacă se întâmplă asta, ești deja în probleme: au acces direct la serverul tău.

FALS: Scenariul pe care îl descriu mai sus este rezultatul unei configurații greșite, nu al unei intruziuni.

Argumentul 2: Dezactivarea accidentală a PHP este rară și, prin urmare, nesemnificativă

Dacă un atacator are suficient acces pentru a schimba handler-ul PHP, ești deja compromis. Schimbările accidentale sunt foarte rare în experiența mea, iar în acel caz ar fi ușor să schimbi parola.

FALS: Scenariul pe care îl descriu mai sus este rezultatul unui bug într-o bucată comună de software de server, care afectează o configurație comună de server. Acest lucru nu este deloc "rar" (și în plus, securitatea înseamnă a te preocupa de scenariile rare).

Schimbarea parolei după o intruziune nu ajută prea mult dacă informații sensibile au fost colectate în timpul intruziunii. Serios, încă credem că WordPress este folosit doar pentru blogging casual și că atacatorii sunt interesați doar de defăimare? Hai să ne preocupăm mai mult de protejarea serverului nostru, nu doar de restaurarea lui după ce cineva pătrunde în el.

Argumentul 3: Restricționarea accesului la `wp-config.php` este suficientă

Poți restricționa accesul la fișier prin configurația ta de gazdă virtuală sau .htaccess – limitând efectiv accesul din exterior la fișier în același mod în care l-ai muta în afara rădăcinii documentelor.

FALS: Imaginează-ți că valorile implicite ale serverului pentru o gazdă virtuală sunt: fără PHP, fără .htaccess, allow from all (nu tocmai neobișnuit într-un mediu de producție). Dacă configurația ta este resetată cumva în timpul unei operațiuni de rutină – cum ar fi, de exemplu, o actualizare a panoului – totul va reveni la starea implicită și ești expus.

Dacă modelul tău de securitate eșuează când setările sunt resetate accidental la valorile implicite, ai nevoie de mai multă securitate.

De ce ar recomanda cineva în mod specific mai puține straturi de securitate? Mașinile scumpe nu au doar încuietori; au și alarme, imobilizatoare și trackere GPS. Dacă ceva merită protejat, fă-o corect.

Argumentul 4: Accesul neautorizat la `wp-config.php` nu este o problemă mare

Informațiile despre baza de date sunt singurele lucruri sensibile din [wp-config.php].

FALS: Cheile de autentificare și sărurile pot fi folosite într-o varietate de atacuri potențiale de deturnare.

Chiar dacă credentialele bazei de date ar fi singurul lucru din wp-config.php, ar trebui să fii îngrozit de gândul că un atacator le-ar putea obține.

Argumentul 5: Mutarea `wp-config.php` în afara rădăcinii web face de fapt un server mai puțin sigur

Tot trebuie să permiți WordPress să acceseze [wp-config.php], așa că trebuie să extinzi open_basedir pentru a include directorul de deasupra rădăcinii documentelor.

FALS: Presupunând că wp-config.php este în httpdocs/, mută-l pur și simplu în ../phpdocs/ și setează open_basedir să includă doar httpdocs/ și phpdocs/. De exemplu:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

(Ține minte să incluzi întotdeauna /tmp/, sau directorul tmp/ al utilizatorului, dacă ai unul.)

Concluzie: fișierele de configurare ar trebui să fie întotdeauna întotdeauna situate în afara rădăcinii web

Dacă îți pasă de securitate, ar trebui să muți wp-config.php în afara rădăcinii tale web.

Este mutarea fișierului wp-config în afara root-ului web cu adevărat benefică?

Răspuns scurt: da

Răspuns lung: un exemplu din lumea reală

Bug-ul:

Rezultatul:

Cum să muți wp-config.php în orice locație pe serverul tău

Contrazicerea argumentelor opuse

Argumentul 1: Dacă PHP este dezactivat, deja sunt înăuntru

Argumentul 2: Dezactivarea accidentală a PHP este rară și, prin urmare, nesemnificativă

Argumentul 3: Restricționarea accesului la wp-config.php este suficientă

Argumentul 4: Accesul neautorizat la wp-config.php nu este o problemă mare

Argumentul 5: Mutarea wp-config.php în afara rădăcinii web face de fapt un server mai puțin sigur

Concluzie: fișierele de configurare ar trebui să fie întotdeauna întotdeauna situate în afara rădăcinii web

Cum să muți `wp-config.php` în orice locație pe serverul tău

Argumentul 3: Restricționarea accesului la `wp-config.php` este suficientă

Argumentul 4: Accesul neautorizat la `wp-config.php` nu este o problemă mare

Argumentul 5: Mutarea `wp-config.php` în afara rădăcinii web face de fapt un server mai puțin sigur