ARCHIV

PHP (91) - php.ini potřetí a naposledy

Jak se dají nastavit sessions, zobrazování chyb a upload souborů.

14.1.2005 15:00 | Petr Zajíc | Články autora | přečteno 33087×

Dnes dokončíme zamyšlení nad konfiguračními volbami v PHP. Rovněž si ukážeme, že něco málo lze dělat i v případě, kdy se musíme spokojit s přednastavenou konfigurací.

Sessions

V díle o session proměnných  jsme si vysvětlili, že identifikátor session může být stránce předán buď pomocí cookies, nebo pomocí parametru v URL. Jedno i druhé má své pro a proti a obojí jde vypnout. Abych to trochu upřesnil: použití cookies pro přenos identifikátoru session se zapíná a vypíná konfigurační volbou session.use_cookies. Pokud je to povoleno, ukládají se identifikátory session jako cookies. Nevýhoda tohoto přístupu k problematice spočívá v tom, že browser musí mít povoleno přijímat cookies, jinak zkrátka nebudou session fungovat. Výhoda je ta, že to je mnohem bezpečnější než posílat identifikátory session v URL.

Pozn.: Uvedené chování si můžete vyzkoušet například tady na Linuxsoftu. Pokud zakážete přijímat cookies, nebudete se moci přihlásit do svého profilu.

Pakliže selže uložení identifikátoru session, má server dvě možnosti:

• session prostě nenastaví, nebo
• přiřadí identifikátor session jako parametr do url

O tom, co se ve skutečnosti stane, rozhoduje nastavení konfigurační volby session.use_only_cookies. Pokud používá server pro přenos identifikátoru session pouze cookies, nastavení session selže. Pokud ne, může nastavení jiné konfigurační volby, a sice session.use_trans_sid způsobit, že PHP přiřadí ID session do URL. Přiřazení identifikátoru session jako parametru do URL má jednu podstatnou výhodu - bude to fungovat vždy, i když budou cookies vypnuté. Má to taky jednu podstatnou nevýhodu - není to vůbec bezpečné. Jestliže je totiž ID session posláno v URL, obdržíte URL podobné tomuto: http://www.server.cz/stranka.php?parametr=hodnota&PHPSESSID=[identifikátor session]. Tedy k session se může připojit kdokoli, kdo nějak zachytí její identifikátor - vůbec to nemusí být ten, kdo session spustil (!)

Z tohoto důvodu bývá většinou posílání session v URL na serverech zakázáno. A mimochodem, pokud musí PHP generovat URL s více než jedním parametrem, použije k oddělení parametrů takovou sekvenci znaků, která je nastavena v php.ini jako arg_separator.output. Pokud jste seriál podrobně sledovali, pravděpodobně víte, že výchozí nastavení ("&") může generovat nevalidní dokumenty, a že správné nastavení je "&". Pakliže tedy budete ověřovat validitu stránek používající sessions a přenášející sessions v URL a budete mít v dokumentu chyby "ampersands in URLs", je to pravděpodobně ten důvod.

Error_reporting

Následující dotaz pochází od jednoho čtenáře: Ptal se mě, proč následující skript:

pokud se volá bez předání proměnné "cosi" na jeho domácím počítači skončí hláškou "Notice: Undefined index", zatímco v práci normálně proběhne. Odpověď je prostá, závisí to na nastavení úrovně chybových hlášení, a to se opět děje pomocí php.ini. Existují konstanty, pomocí nichž se dá nastavit, která úroveň chyb se bude hlásit. Takže můžete například hlásit závažné chyby, varování, poznámky, chyby kompilace a podobně. Více se o tom dozvíte v manuálu k PHP na stránce, věnované funkci error_reporting. O typech chyb jsme rovněž mluvili v díle o chybách.

Příjemné je vědět, že pomocí funkce error_reporting lze v každém skriptu zakázat či povolit zobrazování určitých chyb. Nemusíte tedy kvůli tomu používat funkci ini_set. Ukázku by šlo přepsat tak, aby nevracela upozornění na neinicializovanou proměnnou pomocí následujícího kódu:

S používáním chybových hlášení ve skriptech souvisí ještě jeden zajímavý problém, vlastně dva:

1. Uživatele nebude chybová hláška zajímat, tudíž by bylo dobré mu ji neukazovat
2. Některé chybové hlášky bývají dost upovídané. Například prozradí ve kterém skriptu k chybě došlo a na jakém řádku. To může být neocenitelné při ladění; na webu to však může poněkud snižovat bezpečnost (tak třeba jste vůbec nechtěli, aby někdo tušil, že daný skript existuje, a ono se to provalí kvůli chybě).

Převážně z těchto dvou důvodů lze vypnout zobrazování chyb pomocí konfigurační direktivy display_errors, a zapnout naopak protokolování chyb pomocí související direktivy log_errors.

post_max_size

Konečně ještě jeden tip k přenášení dat pomocí formulářů. Konfigurační volba post_max_size určuje, kolik se maximálně smí přenést dat pomocí formulářů zpracovávaných metodou POST. Jelikož jsme si ukázali, že pomocí formulářů lze přenášet na server i soubory, ovlivňuje tato volba i maximální velikost souborů, které je možné uploadovat (společně s volbou upload_max_filesize). Znát něco takového může být užitečné ze dvou důvodů:

• Když chcete zabránit skriptu, aby nešly nahrát velké soubory (někteří uživatelé tvrdí, že za jistých okolností nemusí stačit použít hednotu MAX_FILE_SIZE ve formuláři, sám jsem se s tím nesetkal)
• Když chcete vědět, proč Vám nejde odeslat formulář obsahující kvanta dat.

Možná si říkáte, že kromě odesílání souborů to k ničemu není. Existují však aplikace, které skutečně kvanta dat ve formulářích odesílají. Tak například PHPmyAdmin umožňuje pomocí formuláře uploadovat definici databáze, nebo rovněž databázová data. To skutečně může narůst na několik MB a možná byste marně pátrali po příčině, proč to nejde nahrát na server.

Bezpečnost především

Ve třech posledních dílech jsme se podívali na některé běžnější volby jazyka PHP. Zejména na ty, které budou zajímat programátory, protože přímo ovlivňují běh skriptů nebo mohou způsobit, že skript někde běží a jinde ne. To však neznamená, že nyní budete schopni nastavit php.ini tím nejlepším způsobem. Abyste uměli nastavit php.ini "správně", museli byste se zabývat přinejmenším ještě následujícími věcmi:

• použitým webovým serverem
• tím, zda PHP poběží jako CGI či modul
  
• operačním systémem, na němž PHP běží
• požadavky na výkon, škálovatelnost a zabezpečení
• a konečně, pokud by PHP využívalo více lidí, tak i (ne)možností uspokojit více požadavků na konfiguraci od jednotlivých uživatelů
  

Pozn.:Murphyho zákon přitom stanoví, že u jednoznačných voleb dojde k situaci, kdy každá polovina uživatelů bude chtít přesně opačné nastavení.

Neboli, kvalitní instalace a nastavení php (včetně php.ini) jde nad rámec tohoto seriálu a v praxi by měla být svěřena kvalifikovanému správci. My příště opustíme téma nastavování php a zamyslíme se nad tím, zda a jak se dá PHP použít k něčemu jinému než ke tvorbě internetových stránek.

Verze pro tisk

DISKUZE Nechapu 14.1.2005 17:00 Jan Houštěk Re: Nechapu 14.1.2005 18:40 Petr Zajíc session hijacking 15.1.2005 19:47 Ján Sokoly   Re: session hijacking 17.1.2005 05:03 Petr Zajíc Zobrazit označené Zobrazit vše Příspívat do diskuze mohou pouze registrovaní uživatelé.