Dnes se podíváme na konkrétní záležitosti kolem PHP, které se týkají zabezpečení a které se více či méně dají ovlivnit programátorsky. Protože jsme se některých těchto témat již na různých místech seriálu dotkli, budou zde rovněž odkazy do předchozích článků.

Bezpečnost souborů

Jelikož je PHP většinou provozováno na serveru s kvalitně nastavenými právy k souborům, není toto téma tak palčivé, jak by mohlo být. To však neznamená, že byste mu neměli věnovat pozornost! Čas od času bývá potřeba pomocí PHP přečíst, odstranit nebo změnit soubor operačního systému hostitelského počítače. V takovém případě musíte být opatrní, aby skript pro modifikaci dělal skutečně to, co má, a aby dělal jen to, co má. Mějme například následující skript pro vypsání obsahu souboru do prohlížeče:

Tento skript je potenciálně velmi nebezpečný, protože vůbec neověřuje, co se vlastně pokoušíme vypsat. Takže namísto nevinného volání ve stylu

by útočník mohl napsat něco jako:

Způsobů, jak tomu zabránit je několik. Programátor by nikdy neměl dát případnému útočníkovi do ruky takovouto zbraň, proto můžeme dejme tomu omezit možnost vypsání souborů na soubory ve stejné složce, jakou má obslužný skript:

Můžeme rovněž kontrolovat příponu souboru, který se má zobrazovat, jeho práva, velikost, typ a podobně. Rovněž je žádoucí veškeré případné změny v souborech (jako je tvorba souborů, změna obsahu nebo mazání) protokolovat.

Bezpečnost databází

Jednotlivé databáze mají své bezpečnostní mechanizmy. K tomu patří ověřování uživatelů, práva k tabulkám a procedurám a podobné věci. O bezpečnosti databáze MySQL jsme v tomto seriálu již mluvili. Obecně je téma "PHP, databáze a bezpečnost" velmi široké, takže si nejprve pojďme říci, co všechno tím můžeme mínit. Může se jednat o:

• zabezpečení dat v databázi proti zneužití
• zabezpečování přihlašovacích informací
• zabezpečení komunikace mezi PHP a MySQL
• zabezpečení dotazů proti SQL-injection
• a další...

V současné době, která by se dala označit jako věk databází pochopitelně význam uvedených faktorů vzrůstá. Skutečnost je taková, že 100% zabezpečení internetové databáze není možné, a proto bude třeba zvážit, jaké informace se v databázích na internetu mají uchovávat. Znám skutečně společnosti, které ze svých internetových databází pravidelně "odčerpávají" data do lokálních, lépe ochránitelných systémů.

Tak například pokud internetová stránka obsahuje nějaké připojovací údaje k databázi, prakticky vždy jsou tyto údaje uloženy v PHP skriptech. Pokud by útočník zjistil tyto údaje za skriptu, mohl by se zcela jednoduše připojit k databázi. Proti tomu neexistuje spolehlivá ochrana - snad jen uložit připojovací informace do konfiguračních souborů webového serveru (Apache to umožňuje).

SQL injection je technika, která útočníkovi umožní "vpašovat" do příkazu SQL pro databázi kód, který tam původně nebyl. Řešením je NIKDY nepoužívat uživatelem zadaná data jako přímou součást databázových operací. Namísto toho je velmi žádoucí všechna data ověřit, pospojovat a odeslat do databáze až v momentě, kdy máme jistotu, že nemohou obsahovat něco, co jsme nečekali. Můžeme tedy testovat, zda celé číslo je opravdu celé, zda datum představuje platné datum a zda jsme všechny potenciálně nebezpečné znaky řádně oescapovali.

Hesla ve skriptech

Kromě připojovacích údajů do databáze může obsahovat skript celou řadu dalších citlivých údajů. Můžeme mít například následující fragment kódu:

Tento kód sám o sobě samozřejmě žádný problém nepředstavuje; nepříjemné však je to, že kdokoli si skript přečte, bude naše heslo znát (může se jednat třeba o správce webu). Přitom bychom nemuseli porovnávat samotné heslo, ale jeho hash:

Protože je funkce md5() jednosměrná, neexistuje žádný způsob, jak z ní vyluštit původní heslo a je tedy dobrou ochranou před nenechavými zraky.

Data od uživatelů

Jakákoli data od uživatelů je třeba kontrolovat, kontrolovat a kontrolovat. Byla  tom řeč průběžně, například v díle o formulářích, nebo v díle o zpracování prvků TEXTAREA na cvičném portálu. Uvědomme si, že chybná data mohou přijít z nejrůznějších důvodů - může se jednat o omyl, útok na webové stránky, nebo o kočku domácí líně se rozvalující na klávesnici zapnutého PC.

Pozn.: Ten poslední příklad byl z manuálu o PHP! Ověřoval jsem to experimentálně na svém řádně medializovaném domácím mazlíčku (obrázek z dílu o ukládání binárních dat do databází) a bylo zjištěno toto: Naše Líza se při rozvalování na klávesnici nepokouší rozbít bezpečnostní model PHP, ale klávesnici samotnou. Jde přitom o tzv. brute-force attack (útok hrubou silou), při němž se útočník pokouší přežvýkat přívodní kabel ke klávesnici. Jak ta mrcha rozpozdá datový kabel od napěťového, to skutečně nevím.

Register globals

Jak a proč zakázat registraci globálních proměnných jsme již probírali v díle o nastavení PHP. Ne snad, že by zapnutí či vypnutí této volby udělalo z PHP bezpečnou aplikaci, ale je dobré vědět jak celý mechanismus funguje a jaké je s tím spojeno nebezpečí.

Závěr

Nedotkli jsme se všech aspektů zabezpečení PHP. Jak si můžete přečíst v nabídkách kurzů, které Linuxsoft pořádá, je nastavení PHP na serveru rovněž jedním z témat, která se přednášejí. Psaní bezpečných aplikací v PHP je vždy balancování na ostří nože - mezi použitelností a zabezpečením. Je to hledání kompromisu - stejně jako v mnoha jiných oblastech programování. A to je na tom to hezké, ne?