PHP auditing

Temu rezervirala: Valentina Krhlanko

Sadržaj 1 Općenito o auditingu 2 Načini auditinga 2.1 Statička analiza 2.2 Dinamička analiza 3 PHP auditing - smjernice 4 Primjer analize programskog koda pomoću smjernica 5 Alati 5.1 RIPS 5.1.1 Analiza dobivenih rezultata 5.2 DevBug 5.2.1 Analiza dobivenih rezultata 5.3 OWASP WAP - Web Application Protection Project 5.3.1 Analiza dobivenih rezultata 6 Literatura

Općenito o auditingu

Auditing programskog koda označava sveobuhvatnu analizu izvornog koda s ciljem otkrivanja buggova, sigurnosnih propusta ili kršenja programskih konvencija(pravila). Predstavlja sastavni dio paradigme obrambenog programiranja te služi za smanjenje pogrešaka i potencijalnih propusta prije izdavanja softvera. Postoji mnoštvo smjernica za reviziju programskog koda, no općenito je pravilo da bi se svaki ključni dio treba analizirati zasebno, ali i u sklopu cijele aplikacije. Dobra praksa je započeti od ranjivosti koje su višeg stupnja rizika te se postupno spuštati prema manje rizičnim prijetnjama. Prijetnje se mogu tražiti pomoću penetracijskih testova, te različitim statičkim i dinamičkim analizama. [3]

Načini auditinga

Najčešći načini sigurnosne provjere su statička i dinamička analiza. Kombinacija statičke analize provedene od stane iskusnog stručnjaka i pripadna dinamička analiza mogu otkriti i do 95% pogrešaka i ranjivosti. (Brain)

Statička analiza

Najčešće se odnosi na analizu koda pomoću alat za statičku analizu (eng. Static Application Security Testing (SAST) Tools). Cilj je pronaći ranjivosti u "statičkom" izvornom kodu,tj. pronalaze se ranjivosti koje su vidljive iz izvornog programskog koda i ne zahtjevaju izvršavanje.

Prednosti statičke analize su:

1. Pronalazi točnu lokaciju ranjivosti u kodu
2. Može se analizirati sav izvorni kod
3. Ranjivosti se otkrivaju u ranim fazama razvoja

Nedostatci statičke analize:

1. Rijetko se pronalaze ranjivosti proizašle izvođenjem
2. Ponekad prikaže lažno pozitivne ili negativne rezultate

(Codementor)

Dinamička analiza

Dinamička analiza koda za razliku od statičke ima mogućnost pronalaska ranjivosti prouzročenih interakcijom koda sa drugim komponentama, poput SQL baze podataka, servera ili web servisa. Često se parametri šalju back-end serverima na procesuiranje što omogućava modifikaciju podataka prilikom njihova vraćanja. Dinamička analiza pretpostavlja širok spektar ulaznih vrijednosti i sigurnosnih testova i najčešće otkriva oko 85% nedostataka u programskom kodu. No kod ovakve analize važno je napomenuti da alati moraju biti u stanju razumijeti programski kod kako bi se kreirati adekvatni parametri. Prednosti:

1. Za razliku od statičke analize otkriva i ranjivosti pri izvođenju programa
2. Može prepoznati lažne rezultate iz statičke analize
3. Omogućuje provjeru ispravnosti rezultata statičke analize

Nedostatci:

1. Potrebno je pronači područje tj. liniju/e koda koja je prouzročila ranjivost. Često je pronalazak monoton i dugotrajan posao.
2. Automatizirani alati također mogu generirati lažne pozitivne ili lažne negativne rezultate
3. Automatizirani alati za dinamičku analizu češće pružaju lažni osjećaj sigurnosti i zaštićenosti aplikacije

(Codementor)

PHP auditing - smjernice

Prilikom vlastoručnog auditiniga najbolje je pratiti određene smjernice. Iako postoji mnoštvo smjernica koje variraju od univerzalnih do specifičnih za pojedini programski jezik, odabran je popis naveden na stranici php-developer.org koji je posebno prilagđen php programskom jeziku. Popis stvari koje treba provjeriti sastoji se od 14 stavki koje će biti navedene i opisane u nastavku teksta.

1. Jesu li provjerene SVE vrijednosti koje unosi korisnik?
   Npr. ako očekujemo da je unesena vrijednost integer u PHP aplikaciji treba dodatno provjeriti da li je korisnik stvarno unio vrijednost tipa interger ili ne. Potrebno je i dodatno provjeriti sve vrijednosti dobivene preko POST i GET metode.
2. Da li su provjerene i sanirane sve varijable koje se koriste u MySQL upitima?
   Negativan odgovor na ovo pitanje znači da je aplikacije ranjiva na XSS napade i SQL injection. [1] i POST parametara za prevenciju MySQL i XSS napada
3. Da li se koristi čisti PHP kod ili se aplikacija razvija u nekom CMS-u npr. WordPress,Joomla,Drupal i sl.)?
   Važno je napomenuti da se preporuča korištenje minimalno PHP5 zbog sigurnosnih ažuriranja koja su bolja u odnosu na prijašnje verzije, a primarno zbog toga što je uklonjen register_globals koji je predstavlja visok sigurnosni rizik.
4. Da li su osigurane administratorske datoteke u PHP aplikaciji?
   Ako je dozvoljen javni pristup administratorkim login datotekama potiču se brute force napadi na prijavu. Dobra praksa je koristit .htaccess za postavljanje IP adresa koje imaju pravo pristupa na te datoteke.
5. Provjerite da se ne koriste korisnička imena i lozinke čije vrijednsti su "admin" ili je korisničko ime "admin",a lozinka "admin123"
   Prilikom razvoja aplikacije programeri često koriste jednostavna korisnička imena i lozinke u svrhu testiranja. Problem se javlja kad se testni podatci zaborave obrisati ili izmijenti.
6. Da li je isključeno izvješće o pogreškama tijekom deploymenta?
   MySQL i PHP pogreške pružaju korisne informacije za napadača i često mu olakšavaju napad.
7. Da li se koristi SSH za upload ili download povjerljivih PHP datoteka
   Ako se šalje povjerljiva datoteka koja sadržava korisničko ime i lozinku za MySQL ili neke druge osjetljive podatke za prijavu preko FTP-a sadržaj će biti prikazan u plain tekstu. Takve podatke napadač može lako presresti, te se preporuča sve podatke koje uploadamo ili downloadom slati preko SSH.
8. Treba provijeriti da ne dolazi do izlaganja prijava kroz njihovu pohranu u tekstualni ili neki drugi dokument na serveru koji sami hostamo!
   
9. Da li je provjereno da PHP skripte nisu ranjive na Remote File Inclusion?
   Problem se najednostavnije rješava postavljanjem pravila i uvjeta preusmjeravanja. Uvijet bi trebao provjeravat da li se u parametrima nalazi tekst koji sadrži http,https ili ftp. U slučaju da sadrži potrebno je odbaciti zahtjev.
10. Da li je PHP izložen javnosti?
    Napadači mogu pomoću phpinfo() funkcije saznati dodatne informacije o postavkama PHP-a i servera. Poznavanjem postavki napadač može jednostavnije i brže pronaći ranjivosti.
11. Da li su zaštićene datoteke koje uključujemo u PHP-u? Napadač može preko web preglednika uključiti neku vlastititu bilioteku ili php skriptu ako nije zaštićen direktan pristup dokumentima ili ako nije zaštićen direktorij u kojem se nalaze sve datoteke koje se ukljućuju u php skripti
12. Da li je sakriven PHP? Ako je sakrivena činjenica da se PHP koristin na serverskoj strani otežat će se otkrivanje pomoću automatiziranih metoda.
13. Ako je konfiguriran Apache server i kao Apache modul je instaliran PHP, da li su nekome dodijeljena korjenska prava( root permissions) od Apachea?
14. Da li ste pročitali službenu PHP dokumentaciju?
    Dobar primjer ranjivosti koji možemo saznati iz dokumentacije je PHP automatski ispravlja neodgovarajuć tip podataka u onaj koji se očekuje .Preporuča se koištenje funkcija i operatora koji ne rade implicitne konverzije tipova (npr. korist === umjesto ==) (Owasp)

Primjer analize programskog koda pomoću smjernica

Na temelju smjernica, proučen je programski kod skripte registracija.php. Progamski kod cijelog projekta nalazi se na git repozitoriju. Prilikom analize pomoću alata analizirat će se i skripta baza_class.php smiještena u podirektoriju klase. Na temelju smjernica proći će se dijelovi programksog koda i navesti mjesto pronalaska moguće ranjivosti. Kako je nemoguće obuhvatit sve smjernice, ovje će se prikazati samo one u kojima je otkrivena potencijalna ranjivost. Prva smjernica odnosi se ne provjeru svih vrijednosti koje korisnik nosi. U kodu unutar registracija.php obavlja se djelomična provjera unosa, tj. provjerava se da li je korisnik unio neku vrijednost i njen raspon, ali se nigdje striktno ne provjerava kojeg je tipa. Također direktno se pristupa globalnoj varijabli bez escapanja specijalnih zankova.

Druga smjernica odnosi se na provjeru i saniranje varijabli koje se koriste u MySQL upitima. Kako je to prvi PHP projekt autorice, naravno da se na to nije obračala pažnja. Aplikacija je ranjiva na SQL injection jer se upiti nisu parametrizirani, a korisnički unos se ni ne provjerava.

Smjernica tri odnosi se na to da li se koristi čisti PHP kod ili razvijamo aplikaciju u CMS-u. Projekt koji koristimo u primjeru rađen bez uporabe CMS-a i to u PHP verziji 5.6 koja ima manje sigurnosnih propusta u odnosu na starije verzije. U petoj smjernici potrebno je obaviti provjeru korisničkih imena i lozinki koje se koriste prilikom prijave. Prilikom registracije u aplikaciju,tj. prilikom popunavanja registracijskih podataka potrebno je ispuniti određene uvjete. Npr. zahtjev da korisničko ime i lozinka moraju sadržavati brojke,određene specijalne znakove i slova dodaje dodatnu razinu kompleksnosti. Šesta smjernica odnosi se na provjeru isključenosti izvješća o pogreškama tijekom deploymenta. Pomoću php ini možemo pogledati da li je to omogućeno ili nije. U našem slučaju je omogućeno,a iskljućiti se može pomoću jedne od slijedećih naredbi:

error_reporting(0); @ini_set('display_errors', 0);

Dodatno ugrožavanje sigurnosti vezano za ovu smjernicu možemo vijdeti i u skripti baza_class.php gdje se prilikom pogreške pri spajanj na bazu ista ispiše na ekran.

Osma smjernica se odnosi na provjeru mogućnosti izlaganja podataka za prijavu. Napadač može iskoristiti činjenicu da su korisnički podatci izloženi u direktoriju zaštićenom sa lozinkom pomoću .htaccess-a (jedan od zahtjeva projekta bia je pohrana svih korisnička imena i lozinki na jednom mjestu unutar projekta). Pošto se podatci nalaze u podirektoriju i zaštićeni su jednom lozinkom napadač lako može doći do njih. U desetoj smjernici se postavlja pitanje da li je PHP izložen javnosti. Ako prije nije bio,nakon postavljanaj koda na git javni repozitorij postao je izložen. Još jedna mana je to da je ne postoji zaštita za pozivanje phpinfo() metode te napadač tako može saznati dodatne informacije koje mu olakšavaju napad. Zadnja mana se odnosi i na smjernicu pod brojem dvanaest (Da li je prikriveno korištenje PHP-a). Uz to da se lagano može pozvati phpinfo, nisu sakrivene ni .php ekstenzije pa napadač odmah prepoznaj o kojem programskom jeziku se radi.

Alati

RIPS

RIPS je alat za statičku analizu PHP aplikacija. Tokenizacijom i parsiranjem svih datoteka sa izvornim kodom pretvara izvorni kod u model programa i pronalazi ranjivosti koje može iskoristiti napadač tijeko izvršenja programskog toka. Korištena je starija 0.5 verzija koja ne pruža potporu za objektno orijentirano programiranje te se ne izvršava analiza klasa. Nova verzija je komercijaizirana i može se kupiti na stranici https://www.ripstech.com/ .

Prije korištenj RIPS alata potrebno je instalirati xamp ili wamp server.Za potrebe ovog rada korišten je već ranije instaliran wampserver (link za download i upute se nalaze na http://www.wampserver.com/en/).Nakon što je instalian server za lokalno pokretanj programskog koda potrebno je skinuti kod RIPS alata. Starija i besplatna 0.55 verzija koja se koristi u ovom radu preuzeta je sa sourceforge.net. Pohranjeni zip potrebno je raspakirati u www datoteku i pokrenuti na lokalom webserveru. Početni zaslon možete vidjeti na slici ispod teksta ovo paragrafa.

Dobra strana Rips alata je to da omogućuje skeniranje samo jedne php skripte te se uključivanjem ostalih skripata provjerava i njihova ranjivost, a s druge strane može se napraviti analiza cjeloukupnog direktorija sa svim programskim kodom aplikacije. Omogućuje analizu svi podržanih ranjivosti,ali i filtriranje prema određenoj kategoriji sa klijentske ili poslužiteljske strane. Ranjivosti na poslužiteljskoj strani prema kojima se može filtrirati su: Code execution,Command Execution,File Disclosure, File Inclusion, File Manipulation, DAP Injection, PH Object Injection,Protocol Injection, Reflection Injection, SQL Injection i other. Za razliku od poslužiteljskih mogućnosti,klijentska strana ima samo tri moguće opcije filtriranja za traženje ranjivosti: Cross-Site Scripting, HTTP Response Splitting i Session Fixation. Rips omogućuje i analizu prema pet razina opširnosti:

1. user tainted only
2. file/DB tainted +1
3. show secured +1,2
4. untainted +1,2,3
5. debug mode

Kako bi napravili što detaljniju analizu koristit ćemo untainted +1,2 ,3 razinu opširnosti jer daje najbolji prikaz.Na primjer ak analiziramo sa user tainted only otkriveno je 9 potencijalnih ranjivosti u danom kodu, sa show secured +1,2 11 ranjivosti, a sa untainted +1,2,3 99 ranjivosti. Statistički regled rezultata vidljiv je na slici ispod teksta.

Analiza dobivenih rezultata

Ako krenemo top-down pristupom prvih nekoliko ranjivosti koje su uočene odnosi na File Inclusion. Većina tih ranjivosti je false positive jer se u include funkciji ne nalazi vrijednost neke varijable već predefinirana vrijednost. Ako pogledamo detalje ranjivosti (za svaku ranjivost u Ripsu se klikom na help ikonu prikaže definicija te ranjivosti te moguće rješenje problema). Da bi postojalo file inclusion ranjivost programski kod bi trebao biti definiran kao na slici,a u našem slučaju je include("header.php").

Nakon detaljng pregleda dobivenih rezultata, prebacit ćemo se na manju opširnost analize (secured +1,2) jer je većina sigurnosnih propusta uzrokovana korištenjem Smarty sustava predložaka. Važno je napomenuti da su oni bili dodatna mogućnost prilikom izrade projekta u sklopu kolegija Web dizajn te ćemo njihovu analizu zanemariti u ovome radu. Jedna primjer Cross-Site Scripting-a je prikazan na prvoj slici ispod teksta ovog paragrafa. Zanimljivo je da uz ovu ranjivost nije omogućen prikaz "pomoći" koja prikazuju strukturu i moguće rješenje ranjivosti već se se omogućio prikaz načina iskorištavanja te ranjivosti.

Još jedan primjer stvarne ranjivosti, njenih detalja i mogućeg rješenja:

DevBug

DevBug je jednostavan i poprilično primaran online alat za statičku analizu koda napisan u JavaScriptu. Nastao je s ciljem povećanja osvještenosti o sigurnosti i integraciji alata za statičku analizu u proces razvoja programskog koda. Služi za osnovnu i brzu analizu ranjivosti. Nastao je velikim dijelo na temelj RIPS alata i projekta CodeMirror. Pristupa mu se preko web adrese http://www.devbug.co.uk . Programski kod koji želimo testirati potrebno je zalijepiti/napisati unutar za to predloženo mijesto. DevBug provjerava ranjivosti korisničkog unosa. Popis mogućih ranjivosti koje može prepoznati:

1. XSS
2. Header Manipulation
3. Code Evaluation
4. File Inclusion
5. File Reads
6. Command Injection
7. SQL Injection
8. XPath Injection
9. LDAP Injection
10. Header injection

Analiza dobivenih rezultata

Za razliku od RIPS-a ne može provjeravati cijeli folder, pa ćemo radi jednostavnosti provijeriti greške u programskom kodu skripti registracija.php i baza.php U kodu skripte registracija.php pronađene su četiri ranjivosti, jedan command injection, jedan header injection i dvije XSS ranjivosti. Ako usporedimo ovu analizu sa rezultatom RIPS analize(četvrta razina opširnosti) možemo vidjeti da RIPS nije prepoznao ni jedan command injection.

Prilikom analize skripte baza.php nije pronađena ni jedna ranjivost. No alat nas upozorava da ipak možda postoje ranjivosti i sigurnosni propusti iako nisu pronađeni.

OWASP WAP - Web Application Protection Project

WAP je alat za pronalazak i prepravak ranjivosti ulaznih vrijenosti. Specijaliziran je posebno za PHP programski jezik i predviđa lažne pozitivne rezultate. Alat objedinjuje statičku analizu sa rudarenjem podataka.Alat je preuzet sa awap.sourceforege.net Može pronaći 8 različitih tipova ranjivosti: [6]

1. SQL injection
2. XSS
3. Remote File Inclusion (RFI)
4. Local File Inclusion (LFI)
5. Directory Traversal or Path Traversal (DT/PT)
6. OS Command Injection (OSCI)
7. PHP Code Injection

Postoji mnoštvo različitih opcija analize ranjivosti aplikacije. U svrhu ovog rada korištena je opcija -all koja pretražuje programski kod za svih osam mogućih ranjivosti. U svim primjerima korištena je -a opcija koja sprječava automatsku korekciju ranjivosti.

Analiza dobivenih rezultata

Kao i RIPS, i WAP uz kratki statistički prikaz omogućuje i detaljan prikaz ranjivosti i mogućnosti za ispravak pronađene ranjivosti. Prilikom analize skripte registracija.php pronađene su dvije XSS ranjivosti. Iste ranjivosti su zamijećene i u prethodna dva alata. Analiza je obavljena u Linux-u zbog loše dokumentacije vezane za korištenje na Windows operacijskom sustavu.

Primjer prepoznavanja mogućih lažnih ranjivosti i danog rješenja vidljiv je na slikama ispod ovog teksta. Radi većeg skupa podataka kako bi se lakše našao potencijalni lažni rezultat skeniran je cijeli projekt.

Literatura

[1] Brain R., Dynamic code analysis vs static analysis source code testing, dostupno 6.1.2017 na http://www.computerweekly.com/answer/Dynamic-code-analysis-vs-static-analysis-source-code-testing

[2] PHP developer, PHP website application security audit and check list dostupno 6.1.2017 na http://www.php-developer.org/php-website-application-security-audit-and-check-list/

[3] Wikipedija, Code audit, dostupno 6.1.2017 na https://en.wikipedia.org/wiki/Code_audit

[4] Owasp, PHP Security Cheat Sheet, dostupno 7.1.2017 na https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet

[5] Codementor,Performing a security audit for your code:The basic,dostupno 8.1. na https://www.codementor.io/learn-programming/performing-security-audit-for-your-code-the-basics

[6] Owasp,OWASP WAP-Web Application Protection, dostupno 8.1. na https://www.owasp.org/index.php/OWASP_WAP-Web_Application_Protection