Este posibil ca un hacker să descarce un fișier php fără a-l executa mai întâi? (Securitatea informațiilor, Php, Controlul Accesului, Restricții)

Petja Zaichikov a intrebat.

Am un site web php în care totul se află în folderul public_html, inclusiv un fișier includes folder cu config și clase. I-am spus dezvoltatorului meu să-l mute din folderul public, dar el a spus că nu există nici un risc, deoarece fișierele sunt fișiere php și chiar dacă cineva tastează în browser fișierul

www.example.com/includex/config.php

tot ce va obține este o pagină goală.

Este corect acest lucru? Nu există nicio posibilitate ca cineva să poată descărca un fișier php și să vadă ce conține, chiar dacă un hacker se conectează cumva la serverul meu pentru a descărca fișierul sau pentru a-l include într-un fișier php de pe serverul său folosind XSS?

Comentarii

  • Este corect, cu condiția ca setările php să fie corecte, ceea ce este destul de ușor de verificat. Există o mulțime de resurse care explică ce caracteristici de setări trebuie activate și dezactivate atunci când se utilizează PHP și valorile pe care ar trebui să le aibă anumite setări (de exemplu, timeout, încărcarea fișierelor, etc.).  > Por Ramhound.
  • XSS este de partea clientului, nu există nici un mod în care acest lucru ar putea fi folosit vreodată pentru a citi codul sursă de pe server. niciodată. Dacă credeți că acest lucru este posibil, trebuie să vă aplecați mai mult despre XSS, aceasta este o venerabilitate foarte serioasă și neînțelegerea bazelor acestei venerabilități este extrem de periculoasă. –  > Por rook.
  • Este relativ ușor să faci o greșeală de configurare care să dezactiveze temporar execuția PHP, așa că de ce să îți asumi acest risc ? Pentru orice aplicație decentă, singurul lucru care trebuie să locuiască în folderul public este un fișier index.php care bootează aplicația/framework-ul și active precum imagini sau foi de stil. Restul ar trebui să se afle într-un director mai sus, care nu este accesibil din exterior. – user42178
6 răspunsuri
rook

Pentru a citi codul PHP aveți nevoie de un vulnerabilitate de traversare a directoarelor. file_get_contents() sau alte funcții ale sistemului de fișiere care sunt exploatabile.

Injecția SQL sub mysql poate fi utilizată pentru a citi codul sursă. De exemplu:

select load_file("/var/www/index.php")

Pentru a combate acest lucru asigurați-vă că file_privs sunt dezactivate pentru contul de utilizator MySQL utilizat de PHP. În cazul în care display_errors = on în configurația php, atunci un atacator poate obține calea către rădăcina site-ului dvs. web și poate folosi injecția SQL sau traversarea directoarelor pentru a citi codul sursă.

Utilizarea FTP înseamnă că codul sursă este transmis în text simplu. Utilizați SFTP, și asigurați-vă că aveți o parolă puternică – sau, mai bine, configurați o cheie RSA.

Fiți atenți la fișierele de backup, uneori editorii vor crea index.php~ sau index.php.orig fișiere care pot fi descoperite cu ajutorul navigare forțată.

tylerl

În plus față de vulnerabilitățile din partea serverului de toate soiurile, parolele FTP divulgate reprezintă, de asemenea, o preocupare semnificativă. Există o clasă de infecții pe partea clientului care colectează parolele FTP salvate de la programe precum CuteFTP, FileZilla și DreamWeaver, trimițând datele de autentificare unui atacator. Acest lucru este foarte frecvent. Am văzut personal sute, poate mii de cazuri în care s-a întâmplat acest lucru. Și, de obicei, persoana care a divulgat parolele fără să știe este cineva care oricum nu mai are nevoie să le aibă.

Iar dacă vă întrebați dacă un atacator va căuta efectiv în fișierele dvs. de configurare în căutarea parolelor, răspunsul este fără echivoc „da„. De obicei, acesta este unul dintre primele lucruri pe care le va face un atacator, la câteva minute după ce a compromis o mașină nouă.

Comentarii

  • FTP înseamnă că codul sursă este transmis în text simplu… de ce mai există FTP? –  > Por rook.
  • @Rook Gopher încă mai există există. FTP va exista întotdeauna. Întrebarea este de ce îl mai folosesc oamenii. Iar răspunsul are probabil de-a face cu faptul că SFTP necesită un cont shell (sau rssh, etc.) și nu este suportat pe Windows. –  > Por tylerl.
  • Căutarea în fișierele de configurare pentru parolele codate este, în mod serios, cea mai ușoară modalitate de a privatiza și de a face pwn rețelele… –  > Por NULLZ.
  • @tylerl Pentru fișierele pe care intenționați să le distribuiți public nu există niciun dezavantaj major. De asemenea, criptarea necesară pentru SFTP poate deveni un blocaj dacă aveți o conexiune de rețea suficient de rapidă și un CPU suficient de lent/ocupat. –  > Por user3490.
  • @user3490 Costul de criptare este aproximativ zero pe hardware-ul modern. De fapt, SFTP este mult mai rapid decât vechiul FTP în majoritatea volumelor de lucru, deoarece nu există niciun cost suplimentar de conectare pe fișier. –  > Por tylerl.
dshaw

Există două moduri posibile prin care un atacator ar putea citi acest fișier ca text, în loc să îl execute.

  1. Dacă serverul dvs. web este configurat greșit, atunci este posibil ca fișierul php să nu fie executat. Evident, trebuie să aveți php instalat și să ruleze pe server, precum și un server web care să suporte acest lucru. Dacă, din anumite motive, ceva nu merge bine cu instalarea php, atunci este teoretic posibil să descărcați fișierul php „brut”. Acest lucru este, totuși, puțin probabil.

  2. În cazul în care există o vulnerabilitate LFI (local file inclusion) în acest script (sau în orice alte pagini dinamice de pe site), este posibil să se afișeze un fișier care se află pe serverul web. A se vedea pagina Wikipedia cu privire la vulnerabilitățile de includere a fișierelor pentru a vedea cum ar arăta acest lucru.

Ca o paranteză, merită menționat faptul că, pentru ca a utiliza fișiere PHP, acestea trebuie să fie accesibile unui browser. Nu există nicio modalitate de a „ascunde” pagina, cu excepția cazului în care aveți un alt script care o execută în altă parte.

Comentarii

  • O LFI poate niciodată fi folosit pentru a citi codul PHP, deoarece un LFI ar executa acel cod PHP. –  > Por rook.
  • @Rook Vulnerabilitatea LFI s-ar afla de obicei într-un alt fișier (sau într-o bucată de cod PHP). –  > Por Jeff Ferland.
  • @Jeff Ferland un LFI ar putea fi utilizat pentru a citi /etc/passwd sau un alt fișier text sau un fișier de configurare xml, dar dacă utilizați un LFI pentru a include un fișier PHP, acel fișier va fi executat, nu afișat. De aceea, un LFI nu poate fi folosit niciodată pentru a descărca codul sursă PHP. –  > Por rook.
  • Cred că, în loc de LFI, vă referiți la AFD (Arbitrary File Download). –  > Por p____h.
  • @Rook – LFI este foarte posibil. Imaginați-vă, de exemplu, un script care servește imagini ca un flux de fișiere (să zicem pentru a adăuga anteturi de cache din mers, etc.), dar care nu face nicio formă de verificare a parametrilor de intrare sau a conținutului real, ci doar presupune că este vorba de un anumit tip de imagine și adaugă tipul MIME relevant în anteturile de răspuns, dacă este cazul (astfel de scripturi sunt adesea folosite pentru a face imaginile descărcabile, de exemplu, astfel încât tipul MIME ar fi static). –  > Por TildalWave.
Bratislava Bob

Parolele FTP divulgate sunt foarte frecvente și reprezintă una dintre cele mai frecvente modalități prin care sunt eliminate fișierele sursă, programele malware instalate pe site-urile web ale dezvoltatorilor sunt foarte frecvente și, recent, dezvoltatorii au început să asiste la atacuri de tip spear phishing împotriva acestora, în încercarea hackerilor de a obține proprietate intelectuală.

Una dintre modalitățile mai puțin frecvente și din câte știu eu este cunoscută doar de un anumit număr de persoane, dar dacă vă dezvoltați site-ul web pe serverul web Linux pe care este găzduit site-ul web, atunci s-ar putea să aveți o problemă, deoarece unele programe de editare vor stoca copii de rezervă ale fișierelor editate, ascunse de ochii dezvoltatorilor, de ex.

Login.php~

Acest fișier, deoarece nu este rulat de serverul web, poate fi accesat introducând

Acest lucru ar dezvălui sursa fișierului login.php de rezervă pentru a preveni acest lucru, ar trebui fie să vă dezvoltați codul site-ului și să îl încărcați pe server, fie să vă asigurați că nu există fișiere de rezervă stocate într-un director la care publicul are acces.

Sursa: 2600 magazine

Ce se întâmplă dacă un atacator a reușit să acceseze

databaseConnection.php~

Atunci chiar te-ai trezit în s*** Creek

mds

Așa cum au răspuns și alții, acest lucru nu ar trebui să fie posibil. Cu toate acestea, nu puteți spune că nu există absolut nicio modalitate ca un atacator să vă citească codul sursă PHP.

De exemplu, ar putea exista o vulnerabilitate care să permită unui atacator să vizualizeze fișierele din serverul web, inclusiv codul PHP brut. Sau un atacator ar putea fi capabil să vă descopere parola FTP, ceea ce, de asemenea, ar putea fi făcut în mai multe moduri, inclusiv atacuri de tip man-in-the-middle și inginerie socială. Există multe posibilități. Mai jos, am enumerat câteva vulnerabilități care ar putea permite acest lucru, dar concluzia este că simpla existență a fișierelor PHP în folderul public_html nu ar trebui să reprezinte un risc în sine.


A download.php care primește un parametru GET/POST cu numele fișierului de descărcat și care nu filtrează corect datele introduse de utilizator, ar putea face posibilă descărcarea codului brut al unui fișier de pe site, prin accesarea unei adrese ca aceasta: http://www.example.com/files/download.php?file=../index.php. A se vedea această adresă.

Un alt exemplu: dacă există o vulnerabilitate care permite unui atacator să să execute pe serverul dumneavoastră, cum ar fi Includerea de fișiere locale/la distanță, Vulnerabilități de încărcare a fișierelorși altele, ar putea fi posibil ca acesta să ruleze un cod care îi permite să citească codul sursă PHP.

AJ Henderson

Atâta timp cât lucrurile sunt configurate corect pe server, fișierele PHP ar trebui să fie înregistrate ca scripturi, iar serverul web ar trebui să le facă să fie interpretate de PHP atunci când sunt solicitate și să afișeze doar rezultatele acestei interpretări.

Acestea fiind spuse, orice număr de probleme pot duce la expunerea fișierelor. Unele dintre aceste probleme pot, de asemenea, să expună date, indiferent dacă acestea se află într-un dosar public sau nu. Este întotdeauna important să vă asigurați că serverul dumneavoastră este configurat corespunzător pentru a permite doar cererile de care aveți nevoie să fie permise. Acest lucru reduce suprafața disponibilă pentru atac și ajută la evitarea posibilelor probleme legate de erori care ar putea duce la o încălcare.

Este o idee bună să aveți un fișier de configurare într-un folder public? Atâta timp cât serverul este configurat să nu dea fișierul fără să-l proceseze, probabil că nu este cu mult mai puțin sigur decât orice alt loc din sistem. Există o mică șansă ca un bug în serverul web să fie folosit pentru a împiedica execuția de către motorul de scripting, dar cele mai probabile atacuri sunt cele care ar veni din altă direcție, cum ar fi SQL, FTP sau o injecție de cod, în cazul în care, aflându-se într-un dosar privat, ar fi la fel de expus.

Acestea fiind spuse, cealaltă parte a întrebării este de ce nu o punem în altă parte. Opțiunea cea mai sigură ar fi să îl plasați într-un loc pe care doar utilizatorul ca instanță PHP a site-ului web îl poate accesa și să refuze accesul la fișier de la orice alt mecanism (cum ar fi utilizatorul FTP sau orice alt utilizator utilizat în mod public.) Totuși, acest lucru este destul de dificil de configurat și de gestionat, astfel încât trebuie luată o decizie dacă securitatea suplimentară este necesară sau nu.

Este o problemă cu privire la care este cea mai bună soluție. Gestionarea tuturor căilor de acces, a permisiunilor și a utilizatorilor pentru a menține acest nivel de securitate necesită multă muncă suplimentară. Pe de altă parte, atâta timp cât serverul este păstrat peticit și configurat corespunzător, ar trebui să fiți vulnerabil doar la exploit-uri de tip zero day care atacă la un nivel foarte scăzut și puteți fi în siguranță împotriva aproape tuturor atacurilor comune, chiar și cu fișierul de configurare în folderul public.