Jak začít... co třeba citací slov Honzy Houšťka, který v diskusi pod jedním článkem našeho seriálu  napsal: "Spoléhat se na nějakou vlastnost PHP je cesta do pekel". Bylo to v diskusi kolem zabezpečení uživatelských vstupů. Což se svým podstatným způsobem týká formulářového prvku TEXTAREA, který jsme minule použili pro zadávání písní.

Tento prvek bývá v PHP mnohdy často špatně zabezpečen. Pojďme se tedy podívat na dva možné obecné zdroje problémů s tímto prvkem a na jeden  specifický problém, týkající se způsobu, jak je použit v naší aplikaci.

Velikost prvku TEXTAREA

V předchozím díle jsme nijak neomezili množství dat, která uživatel může zadat do pole TEXTAREA. Respektive kontrolujeme pouze, zda je vůbec v tomto poli po odeslání něco vyplněno. Takže uživatel by mohl do pole nacpat vědomně či nevědomně příliš mnoho dat a naši aplikaci tak zahltit. To je samozřejmě stav, který nemůžeme strpět. V samotném formuláři sice nastavit maximální počet znaků jednoduše nemůžeme, můžeme ale kontrolovat velikost proměnné po odeslání na server.

Pozn.: Napsat, že nemůžeme omezit maximální počet znaků je nepřesné. Ve skutečnosti to můžeme udělat pomocí skriptů běžících na straně prohlížeče, jako je třeba JavaScript. Jednak je to ale mimo rámec našeho seriálu a jednak je to nespolehlivé, protože JavaScript může být v prohlížeči vypnut, nebo jej prohlížeč vůbec nemusí podporovat.

Můžeme ale udělat ještě víc. Nejen, že můžeme kontrolovat celkovou délku zaslaných dat, můžeme kontrolovat rovněž do kolika řádků (tedy, v našem případě písní) se bude pole dělit. Prohlašme například, že album může mít maximálně 30 písní a že celková délka dat z pole textarea bude 1500 znaků. V takovém případě bychom mohli naše testy rozšířit následovně:

Tím bude zajištěno, že při překročení tohoto limitu se vůbec nedostaneme k databázovým dotazům.

Pozn.: Pro zvídavé - maximální velikost dat formuláře, který PHP vůbec odešle není pochopitelně neomezená. Nastavuje se pomocí volby post_max_size v konfiguračním souboru php.ini. Teoreticky by se tato volba dala i nastavovat pomocí funkce ini_set(), v praxi to však povětšinou bývá zakázáno.

TEXTAREA a HTML

Další moc špatná věc je ta, že TEXTAREA je párový prvek a hodnota uvnitř prvku se nezapisuje jako parametr dovnitř tagu, ale normálně do stránky jako text. Porovnejte, prosím, dva následující zápisy prvků s předdefinovaným textem "abc", jednu TEXTAREU a jeden text:

Pravděpodobně si dokážete představit, jak by to dopadlo, kdyby někdo místo abc zadal jiné znaky, třeba </textarea>. To by mohlo naši aplikaci přinejmenším rozhodit, přinejhorším dokonce poškodit. Řešení je několik; víceméně se liší tím, zda nám při nesprávně vyplněném formuláři vrátí opravdu původní nebo již upravené hodnoty. Podle mě nemají HTML tagy v názvech písní co dělat, a mohu proto hned na úvod zpracování příslušného skriptu napsat:

a všechny tagy zkrátka vymazat. Pokud by se uživatel musel k vyplňování vrátit, už je tam neuvidí. Jiný dobrý způsob spočívá v použití funkce htmlspecialchars, která převede zvláštní znaky (jako jsou třeba "<" a ">") na html entity:

Co konkrétního použitete, záleží pochopitelně na vás. Platí tady to, že jakékoli ošetření vstupního pole je zcela určitě lepší než žádné a na potíže při použití prvku textarea by se rozhodně mělo myslet.

Pozn.: Někteří programátoři tvrdí, že přímá modifikace proměnné $_POST["cosi"] ztěžuje čitelnost kódu. Je to však věc pohledu; z hlediska PHP je to jen obyčejná proměnná a v našem případě je její modifikace to nejjednodušší, co můžeme udělat. Pokud by to nevyhovovalo vašim nebo firemním standardům, můžete to objít třebas uložením výsledku do jiné proměnné.

TEXTAREA a náš formulář

V programu máme ještě jedno slabé místo, které sice souvisí s prvkem TEXTAREA, ale nesouvisí přímo se zabezpečením. Jde o to, že chování rozdělování řádků je uživatelsky neintuitivní. Nejdřív na to narazí ten, kdo se pokusí odřádkovat i za poslední písní - obdrží varovnou hlášku. Program to myslí dobře - zdá se mu, že uživatel zadal píseň s nulovým počtem znaků. To ale bude uživatele mást.

Zase je více správných řešení. Mohli bychom například závěrečný konec řádku odmazat. To ale neřeší problém, kdy uživatel odřádkuje vícekrát. Rovněž to neřeší problém dvou či více následujících konců řádku uvnitř textu! To je případ, kdy s výhodou můžeme použít sílu regulárních výrazů. Mě se osvědčilo řešení ve stylu:

Což přeloženo do češtiny znamená: Najdi všechny výskyty minimálně jednou se opakujícího konce řádku a nahraď to právě jedním koncem řádku. Tím nám zmizí všechna vícenásobná odřádkování, ale ne to poslední. K čemuž je tu ten druhý řádek, který by se dal převyprávět jako: Pokud řetězec končí koncem řádku, ten konec řádku umaž.

Jiné dobré řešení může spočívat v použití funkce split namísto explode pro získání pole s písněmi. Zatímco totiž explode dělí řetězec řetězcem, dělí split řetězec regulárním výrazem. Je to ale jen pro silné nátury ovládající "regulární výrazivo".

Závěr

Vidíme tedy, že trochu zabezpečit prvek textarea není sice složité, ale že si to musíme trochu promyslet. Obecně platí, že když použijete "uživatelsky" jednodušší rozhraní, přiděláte tím práci programátorovi při ověřování vstupu. V případech, jako je tento, to ale má své opodstatnění.

Změny na portálu

• Změněný soubor zadejdiskografii.php - zabezpečení prvku textarea

Na současný stav projektu se můžete na našem webu podívat nebo si jej můžete stáhnout.

Pozn.: Aby Vám stažená verze fungovala na lokálním stroji, upravte si hodnotu konstant SQL_HOST, SQL_USERNAME, SQL_PASSWORD a SQL_DBNAME. Případně si je můžete včlenit do konfiguračního souboru podobně, jako jsem to udělal v souboru func.php.