PHP seadistamine

PHP seadistamine

Autor

Elar Lang
AK32

Sissejuhatus

Acunitex nimelise turbega tegeleva firma andmetel (http://www.acunetix.com/blog/web-security-zone/articles/statistics-from-the-top-1000000-websites/) on 2010 aasta alguse seisuga 68% veebiserverites Apache ning 70% veebiserverites PHP.

Serverite hooldamise ja PHP rakenduste kirjutamise vahele jääb oluline osa - PHP seadistamine ja rakendusele õigete õiguste määramine. Kuna arendaja võib pidada seda administraatori tööks ning administraator omakorda arendaja tööks, siis võib selle töö tegemise (st tegemata jätmise) juures tekkida oluline turvarisk.

Antud artikli eesmärk on juhtida tähelepanu olulisematele nüanssidele PHP seadistuse juures.

PHP seadistamine - mida jälgida

.. teise nurga alt vaadatuna - mis on enamlevinud ämbrid PHP veebikeskkonna seadistamisel?

Veateated

Kuvamine

Toodangukeskkonnas ei tohi mitte mingil juhul kuvada välja tarkvara poolt tekkinud vigade veateateid. See annab ründajale olulist infot rakenduse ülesehituse kohta ning lihtsustab rünnaku teostamist. Arenduskeskkonnas (ja ka test keskkonnas) peaks aga veateateid kuvama.

php manual: http://ee.php.net/manual/en/errorfunc.configuration.php#ini.display-errors

php.ini (vaikeväärtus):

display_errors = 1

php.ini (võiks olla):

display_errors = 0

ini_set (seade määramine jooksvalt php koodis):

ini_set('display_errors', 0); // hide errors
//ini_set('display_errors', 1); // show errors

See ei kuulu küll otseselt PHP seadistamise juurde, kuid reegel peaks ka olema, et programmikood ise ei kuva veateateid välja - näiteks, kui tekib viga SQL päringu teostamisel, siis ei tohi seda mitte mingil juhul toodangu keskkonnas välja kuvada (lihtsustab näiteks SQL injection rünnakute teostamist).

Logimine

Kõik tekkinud vead tuleb kindlasti logida, et vajadusel otsida tekkinud vigade põhjuseid (ja põhjustajaid). Veateadete logi tuleks ka jälgida, mitte lihtsalt logida.

php manual: http://ee.php.net/manual/en/errorfunc.configuration.php#ini.log-errors

php.ini (vaikeväärtus):

log_errors = 0

php.ini (võiks olla):

log_errors = 1

Detailsus

Veateateid tuleks tuvastada võimalikult suure detailsusega. Kindlasti mitte ignoreerida E_NOTICE taseme vigu, sest ka need näitavad välja programmi koodi nõrkuseid või vigu (koodis tekib situatsioon, mida arendaja pole ette näinud).

php manual: http://ee.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting Eeldefineeritud detailsuse konstandid: http://ee.php.net/manual/en/errorfunc.constants.php

php.ini (vaikeväärtus):

error_reporting = E_ALL

E_ALL ei sisaldanud E_WARNING teateid kuni PHP versioonini 5.2. Alates PHP versioonist 5.3 E_ALL raporteerib kõiki teateid peale E_STRICT teadete. Alates PHP versioonist 6 on E_ALL teadete hulgas ka E_STRICT teated. Tasub jälgida PHP dokumentatsiooni. "error_reporting" väärtust saab määrata ka numbrina, igal konstandil on oma numbriline väärtus. Kuid kuna see number võib erinevate PHP versioonide puhul tähendada erinevaid asju (nt E_ALL puhul), siis on turvalisem kasutada selleks ikkagi nimelisi konstante. Samas ei ole eeldefineeritud konstandid kasutatavad kui määrata php seade väärtust Apache httpd.conf või .htaccess vahendusel.

php.ini (võiks olla):

error_reporting = E_ALL ~ E_STRICT

ini_set (seade määramine jooksvalt php koodis):

error_reporting(E_ALL ~ E_STRICT);

Failide halduse ja üles laadimise seadistus

open_basedir

open_basedir parameeter määrab, millistest kataloogidest võib rakendus failisid avada. Vaikimisi on väärtus määratama, mis tähendab, et rakendus saab faile avada tervest serverist (kui failide õigustega seda ei ole piiratud). Selle parameetri puudumine annab võimaluste teostada LFI (Local File Include) ründeid kogu failisüsteemi ulatuses.

php manual: http://ee.php.net/manual/en/ini.core.php#ini.open-basedir

php.ini (vaikeväärtus):

open_basedir = 

open_basedir vaikeväärtus PHP's puudub, st PHP poolt mingeid piiranguid ei ole (loevad vaid failiõigustest tulenevad piirangud).

php.ini (võiks olla):

open_basedir = /path/to/application/root/

Väga mugav oleks määrata open_basedir väärtuseks "." (ehk siis see sama kataloog, kus skript käivitatakse). See on aga ohtlik, kuna PHP chdir käsuga saab "aktiivse kataloogi" ja seega ka väärtuse "." tähendust muuta. Jälgida tuleks väärtuse (või väärtuste) määramisel, et vajalikele kataloogidele ligipääs alles jääks (nt kui ei ole muudetud upload_tmp_dir väärtust, siis lisada open_basedir väärtusele ka /tmp kataloog).

Saab määrata ka httpd.conf failis (ja ka .htaccess failis):

<IfModule mod_php5.c>
  php_admin_value open_basedir /path/to/application/root/
</IfModule>

NB! määrates open_basedir piirangu httpd confi kaudu, ei rakendu see siis kui php käivitada käsurealt (ehk siis kui rakendus ise on juba turvaauguga ja saab tekitada käivitatava php koodi rakenduse alla, siis saab sellest piirangust mööda).

allow_url_fopen

Selle parameetriga juhitakse, kas failide avamise funktsioonidel on õigus avada fail üle urli. Kui rakendus sellist võimalust ei vaja, peaks selline võimalus olema keelatud (et välistada RFI (Remote File Include) rünnakuid).

php manual:http://ee.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen

php.ini (vaikeväärtus):

allow_url_fopen = 1

Vaikeväärtusena on üle urli failide avamine lubatud.

php.ini (võiks olla, kui rakendus ei vaja failide avamist üle urli):

allow_url_fopen = 0

file_uploads

Parameetriga juhitakse, kas HTTP failide üles laadimine on toetatud. Kui rakenduse funktsionaalsus seda võimalust ei vaja, peaks see olema keelatud.

php manual: http://ee.php.net/manual/en/ini.core.php#ini.file-uploads

php.ini (vaikeväärtus):

allow_url_fopen = 1

Vaikeväärtusena on üle urli failide avamine lubatud.

php.ini (võiks olla, kui rakendus ei vaja failide üles laadimist):

allow_url_fopen = 0

upload_tmp_dir

Asukoht üles laetavate failide ajutiseks talletamiseks, kuni PHP programm nendega tegeleb. Pärast pöördumist tmp kataloogist failid kustutatakse.

php manual: http://ee.php.net/manual/en/ini.core.php#ini.file-uploads

php.ini (vaikeväärtus):

upload_tmp_dir = 

Vaikeväärtusena on määramata, kasutatakse süsteemi vaikeväärtust (mis linuxi puhul on /tmp kataloog)

php.ini (võiks olla, kui rakendus ei vaja):

upload_tmp_dir = /path/to/application/root/tmp

upload_tmp_dir parameetri väärtus ei tohiks kindlasti olla avalikku veebi paistev kataloog (st ei tohi olla "document_root" alamkataloog). Vaikeväärtus võiks olla muudetud, kuna failide üleslaadimine on ka üks DoS (Denial of Service) ründemeetodeid. Koormatakse veebiserverit lõputute failide üleslaadimistega, veebiserver tekitab iga faili jaoks "upload_tmp_dir" parameetriga kataloogi ajutisi php* nimelisi faile. Kui DoS rünnaku peale veebiserver hangus, siis võib tekkida olukord, kus tmp kataloogi jäävad need üles laetud ajutised failid alles. Samal ajal LFI (Local File Include) ründevõimalust omades saab ründaja niimoodi sokutada endale vajaliku koodi veebiserverisse.

upload_max_filesize

Maksimaalne ühe üles laetava faili suurus.

php manual: http://ee.php.net/manual/en/ini.core.php#ini.upload-max-filesize

php.ini (vaikeväärtus):

upload_max_filesize = 2M

php.ini (võiks olla, vastavalt rakenduse vajadustele):

upload_tmp_dir = 2M

Väärtus peaks olema valitud rakenduse iseloomust (kui suuri faile ei oodata, ei ole seda hea ka seadistuses lubada).

max_file_uploads

Maksimaalne ühe päringuga üles laetavate failide arv.

php manual: http://ee.php.net/manual/en/ini.core.php#ini.max-file-uploads

php.ini (vaikeväärtus):

max_file_uploads = 20

php.ini (võiks olla, vastavalt rakenduse vajadustele):

max_file_uploads = 1

Väärtus peaks olema valitud rakenduse iseloomust (kui mitme faili korraga üles laadimist ei oodata, siis ei ole seda hea ka seadistuses lubada).

Muud limiidid

post_max_size

Maksimaalne postituse suurus. See ei ole nüüd otseselt failide üles laadimise parameeter, kuid üldjuhul rakendub see piirang just failide üles laadimisele. Valitud väärtus ei tohiks olla põhjendamatult suur. Kui file_uploads parameetriga on failide üles laadimine välja lülitatud, siis lihtsalt vormide täitmise kaudu eriti mahukaid postitusi lubama ei peaks.

php manual: http://ee.php.net/manual/en/ini.core.php#ini.post-max-size

php.ini (vaikeväärtus):

post_max_size = 8M

php.ini (võiks olla vastavuses rakenduse reaalsete vajadustega):

post_max_size = ?

Kui kasutatakse failide üles laadimist, siis peaks post_max_size olema suurem kui "upload_max_filesize * max_file_uploads"

memory_limit

Määrab kui palju on võimalik PHP rakendusel maksimaalselt mälu kasutada. Väärtus peaks olema sõltuvuses rakenduse reaalsete vajadustega. Kehvale rakenduse koodile mälu juurde andmine ei ole lahendus (pikas perspektiivis), sel juhul tuleks kood ringi kirjutada.

php manual: http://ee.php.net/manual/en/ini.core.php#ini.memory-limit

php.ini (vaikeväärtus):

memory_limit = 128M

php.ini (võiks olla vastavuses rakenduse reaalsete vajadustega):

memory_limit = ?

Üldjuhul on 128M pisikese PHP rakenduse jaoks väga palju (32MB'st peaks varuga piisama). Kui rakendus juhtub auklik olema ning ründaja suudab oma koodijupi serverisse toimetada, siis on ka temal korralikult ressursse käes mida kasutada.

max_execution_time

Määrab maksimaalse PHP skripti töötamise aja. Kui PHP rakendus ei tegele mahukate väljundandmete genereerimisega, siis võiks väärtus olla üsna väike. Juhul kui kasutatakse ka käsurealt PHP'd, siis seal võiks olla see piirang maas (tavaliselt käsurealt käivitatavad rakendused on cronjobid, mis tegelevad näiteks mahukate andmetöötlusprotsessidega, andmete importimisega jne).

php manual: http://ee.php.net/manual/en/info.configuration.php#ini.max-execution-time

php.ini (vaikeväärtus, sekundites):

max_execution_time = 30

Vaikeväärtus käsurealt käivitades on 0.

php.ini (võiks olla vastavuses rakenduse reaalsete vajadustega):

max_execution_time = 5

Kuna max_execution_time parameetri väärtust saab määrata ka jooksvalt ini_set funktsiooni kasutades, võiks algne väärtus olla võimalikult väike. Lisaks võiks kasutada vigade ilmnemiseks arendus- ja testkeskkondades oluliselt väiksemat väärtust kui toodangukeskkonnast.

runtime (seade määramine jooksvalt php koodis):

set_time_limit(0); // piirangut ei ole
set_time_limit(10); // piirang on 10 sekundit

Jooksvalt võib muuta ajapiirangu suuremaks kui "streamitakse" kasutajale mingeid andmeid PHP'ga (sest sel juhul sõltub see kiirus ka kasutaja interneti ühenduse kiirusest - suutlikusest talle serveeritavat infot vastu võtta).

Aeguvad parameetrid

NB! Selles peatükis käsitletavad parameetrid on kuulutatud aegunuks (kasutamine annab DEPRECATED vea) alates PHP 5.3'st ning need seaded kaovad ära alates PHP 6'st.

safe_mode

"Sade mode" kujutab endast vaikimsi mitte muudetavaid turvalisusele suunatud seadeid. Safe mode parameetri peale panemine (väärtus 1) ei pruugi alati olla "safe", see tuleks ikkagi eelnevalt läbi testida.

php manual: http://ee.php.net/manual/en/ini.sect.safe-mode.php#ini.safe-mode

php.ini (vaikeväärtus):

safe_mode = 0

php.ini (võiks olla):

safe_mode = 0

magic_quotes_gpc

Parameetriga juhitakse, kas automaatselt "escapeda" kasutaja sisendandmeid "backslashidega" (\). Automaatsed tegevused kasutaja andmetega ei ole head. Lisaks tähendab selle parameetri olemasolu, et kogu programmikood peab arvestama serveri seadetega (et vältida topelt escapemist või escapemise puudumist).

Kuna see parameeter on kuulutatud aegunuks ning kaob ära PHP 6'st, on irooniline, et just magic_quotes_gps on ravim vanade katkiste lehtede juures NULL-Byte rünnakute vastu.

php manual: http://ee.php.net/manual/en/info.configuration.php#ini.magic-quotes-gpc

php.ini (vaikeväärtus):

magic_quotes_gpc = 1

php.ini (võiks olla):

magic_quotes_gpc = 0

Rakenduse kood peab ise tegelema sisendandmete valideerimise ja kontrolliga.

register_globals

Julgen väita, et selle parameetri ja võimaluse olemasolu on rikkunud kõige enam PHP mainet (õnneks on sellest ka PHP loojad ise teinud omad järedlused). See laseb olla arendajal laisk ja lohakas ning kirjutada kohutavalt ebaturvalisi rakendusi.

php manual: http://ee.php.net/manual/en/ini.core.php#ini.register-globals

register_globals parameeter annab arendajale võimaluse kasutada Environment, GET, POST, Cookie ja SERVER muutujaid nagu tavalisi muutujaid. Väga lihtne näide (reaalselt eksisteeriv ühes Eesti firma poolt loodud CMS süsteemis) - kui kasutaja logib sisse admin keskkonda, tekitatakse sessioon võtmega "logged_in" (võtme nimi igaks juhuks muudetud). Vastava sessioni olemasolu korrektne kontroll oleks:

if (isset($_SESSION, $_SESSION['logged_in']) && $_SESSION['logged_in'] == 1) {
	// käivitada logimiskontrolli all olev kood siin
}

Oli aga tehtud nii:

if ($logged_in == 1) {
	// käivitada logimiskontrolli all olev kood siin
}

Sellise kontrolli puhul piisab, kui pöörduda administreerimiskeskkonna poole GET päringuga /admin/?logged_in=1 ning ligipääsu kontrollist ollaksegi möödas.

php.ini (vaikeväärtus):

register_globals = 0

Väga vanadel PHP'del (varasemad kui PHP 4.2) oli vaikeväärtuseks 1.

php.ini (võiks olla):

register_globals = 0

Sessioonide haldus

Sessioon on selleks, et hoida kasutaja külastuse kohta andmeid serveril. Sessioonis ei tohiks kindlasti hoida kriitilise tähtsusega andmeid (nagu näiteks lahtise tekstina kasutaja parool).

Antud parameetreid lahates eeldan, et parameetri session.save_handler väärtuseks on vaikimisi väärtus "files" (ehk siis ei ole kirjutatud mõnda oma sessioonide manageerijat).

session.autostart

Määrab, kas kasutaja külastuse kohta käivitada automaatselt sessioon. Kui rakenduse iseloom ei vaja kasutaja identifitseerimist (suvaline koduleht), siis ole mõtet ka serverit koormata selle külastuse kohta sessiooni loomisega. Vaikimisi tehakse iga sessiooni jaoks /tmp/ (vt session.save_path parameetrit) ka fail. Ebaturvalise rakenduse korral võib sessiooni fail olla ka LFI2RFE (Local File Include to Remote Code Execution) rünnaku teostamise koht.

php manual: http://ee.php.net/manual/en/session.configuration.php#ini.session.auto-start

php.ini (vaikeväärtus):

session.auto_start = 0

php.ini (võiks olla):

session.auto_start = 0

Käivitada vajadusel sessioon rakenduse koodis session_start funktsiooniga.

session.cookie_httponly

Selle parameetriga juhitakse, kas HTML's (nt JavaScripti poolt) on sessiooni cookie kättesaadav. Saab raskendada XSS (Cross-Site-Scripting) rünnakute ja cookie'de varastamise rünnakuid. See võimalus tekkis PHP'sse alates versioonist 5.2.

php manual: http://ee.php.net/manual/en/session.configuration.php#ini.session.cookie-httponly

php.ini (vaikeväärtus):

session.cookie_httponly = 0

php.ini (võiks olla):

session.cookie_httponly = 1

session.hash_function

hash_function määrab, millist algoritmi krüpteerimiseks kasutada. Väärtus 0 tähendab MD5 (128 bitti) ja väärtus 1 SHA-1 (160 bitti) algoritmi.

php manual: http://ee.php.net/manual/en/session.configuration.php#ini.session.hash-function

php.ini (vaikeväärtus):

session.hash_function = 0

php.ini (võiks olla):

session.hash_function = 1

Kuna MD5 loetakse tänapäeval juba ebaturvaliseks algoritmiks, siis võiks kasutada väärtust 1 ehk siis algoritmi SHA-1.

session.name

Määrab ära, millist sessiooni identifikaatorit kasutada (cookie nimetus). Et mitte alluda automaatsetele XSS cookie varastamise rünnetele, võiks vaikimi nimetuse siiski ära muuta.

php manual: http://ee.php.net/manual/en/session.configuration.php#ini.session.name

php.ini (vaikeväärtus):

session.name = PHPSESSID

php.ini (võiks olla):

session.name = MyApp-Sid

Väärtuseks lihtsalt midagi muud kui vaikeväärtus.

session.save_path

save_path määrab kataloogi, kus hoitakse sessiooni failisid. Vaikeväärtuseks on süsteemi "temporary" kataloog, kuhu võib ka teistel kasutajatel olla "listingu" ja lugemise õigused, st et on võimalik teostada "session hijacking" rünnakuid.

php manual: http://ee.php.net/manual/en/session.configuration.php#ini.session.save-path

session.save_path = 

Määramata väärtus tähendab, et kasutada süsteemi vaikimisi väärtust (Linuxi puhul /tmp, Windowsi puhul nt C:\WINDOWS\Temp\)

php.ini (võiks olla):

session.name = /path/to/application/root/session/

Väärtus on võimalik määrata ka scriptis:

session_save_path('/path/to/application/root/session/')

php manual: http://ee.php.net/manual/en/function.session-save-path.php

session.use_only_cookies

Määrab, et sessiooni identifikaatori hoidmine on lubatud ainult küpsistes. Kui kasutaja lehitsejal küpsised ei ole lubatud, siis sessiooni tekitada ei saa. Vastasel juhul hakatakse sessiooni id'd kaasa vedama URL parameetrina, nt PHPSESSID=hash. See aga on oluline turvarisk ning võimaldab väga lihtsalt kasutaja sessiooni varastada (session hijacking rünnak). Piisab sellest, kui kasutaja klikib antud lehel mõnd viidet teisele lehele. Teisele lehele minnes kirjutatakse sinna logidesse (nt külastuste) REFERER, ehk siis mis lehelt kasutaja tuli ja kus oli viide. Viites on aga kaasas tema sessiooni id. Kui keegi saab täpse referer aadressi teada ning läheb sellele, saabki ta omale selle kasutaja sessiooni.

php manual: http://ee.php.net/manual/en/session.configuration.php#ini.session.use-only-cookies

php.ini (vaikeväärtus):

session.use_only_cookies = 0

php.ini (vaikeväärtus alates PHP 5.3'st)

session.use_only_cookies = 1

php.ini (võiks olla):

session.use_only_cookies = 1

Muud parameetrid

short_open_tag

short_open_tag parameeter määrab, kas PHP koodi võib alustada süntaksiga "<?" või "<?php". Kui rakenduse koodis on alustatud failisid, mille poole pöördutakse "<?" süntaksiga ning parameeter short_open_tag on väärtusega 0, siis kuvatakse pöördujale antud faili PHP lähtekood. Selle parameetri muutmiseks peab veenduma, et PHP kood on ka vastavalt kirjutatud. Mõistlik on kasutada selleks mingeid automaatkontrolle, nt CodeSniffer PEAR packaget (http://pear.php.net/package/PHP_CodeSniffer/redirected).

php manual: http://ee.php.net/manual/en/ini.core.php#ini.short-open-tag

php.ini (vaikeväärtus)

short_open_tag = 1

php.ini (võiks olla):

short_open_tag = 1

Muud olulised seadistused

Failide õigused

Serveri logid

PHP rakendusel ei tohiks olla serveri logide lugemise õigust. Juhul kui rakenduse koodis on viga/turvauk LFI (Local File Include) teostamiseks, on vaja ründajal saada serverisse oma koodi LFI2RCE (Local File Include to Remote Code Execution) rünnaku teostamiseks. PHP koodi saab sokutada ka serveri logidesse, nt Apache logisse võltsides lehitseja USER_AGENT parameetrit (või saata see parameeter curl'i kasutades).

Üles laetavad failid

Kataloogidele, kuhu salvestatakse kasutajate poolt üles laetud faile, ei peaks andma failide käivitamise ja kataloogide listingu õigust (x). Samuti tuleb välistada, et kasutaja saaks üles laadida .htaccess failisid.

Avalike kataloogide failide nimekirjad

Docroot alamkataloogides olevatele failidele tuleks keelata kataloogide sisu näitamine (kui see just ei ole taotluslik). Tihti asuvad strateegilised rakenduse failid avalikus kataloogis (kuigi ei tohiks!) ning see annab ründajale olulist infot rakenduse ülesehituse kohta. Keelata saab seda nii failiõiguste tasemel kui ka Apache seadetega. Veebikülastajate eest peitmiseks piisab kui lisada igasse kataloogi näiteks tühi index.html või index.php nimeline fail.

Viirusetõrje

Kuna viiruste levitamine kolib ka veebi, siis on igati asjakohane rakendada regulaarset viirusekontrolli veebirakenduse kataloogi sisule.

Serveri info

Tuleks peita kõik serveri versioone reklaamiv info (nt annab vaikimisi Apache errorleht teada, mis versiooniga on tegu). Kui peaks ilmnema mingi oluline turvaauk, siis ei oleks vähemalt selline info automaatselt tuvastatav (mingite infot koguvate bottide poolt, mis teevad päringuid /thisfiledoesnotexists.php ning saavad versioonid teada).

Kokkuvõte

PHP seadistamisel on palju nüansse, mis vajavad, et arendajad ja administraatorid suhtleks omavahel. Rakenduse loomist alustades peaksid olema kõik seaded määratud "nii on kõige turvalisem" seisukoha järgi. Kui rakendus tõesti vajab oma funktsionaalsuse vajaduste tõttu teisiti, siis saab tagasi muuta.

Väga abiks oleks luua skript, mis kontrollib serveri seadete väärtuseid ja serverilt oodatud seadete väärtuseid. Võib muutuda rakenduse iseloom ja vajadused, tehakse serverisse tarkvara uuendusi jne - sellise kontrolliskripti vastu oleks alati kiiresti ja tõhus kontrollida.