Webové formuláře 2009 – co vyžadují? Bezpečnost.
Jakkoli nám dnes do webových aplikací pronikají různé AJAXy, jQuery a SilverLighty – poctivým základem aplikace je ještě stále formulář. Z pohledu uživatele mají být naše formuláře spolehlivé, použitelné a konzistentní. Z pohledu provozovatele nesmějí vytvářet bezpečnostní díru do systému a mají předcházet chybám. V článku se proto pokusíme sestavit minimum, které máme od formulářů vždy vyžadovat
Nechejte si na zakázku vytvořit webový formulář – a dost možná nebude bezpečný. Zprovozněte portál a nechejte si připravit různé formulářové aplikace – dost možná se formulář v každé z nich bude chovat jinak a bude též různě přístupný a použitelný. V textu jsou použité výrazy jako má být, měl by být a musí být – vycházel jsem s doporučení pro řešení konkrétního problému a samozřejmě si každý může sílu doporučení upravit podle svých potřeb.
Oblasti požadavků na formulář
- Bezpečnost
- Ochrana a ukládání citlivých údajů
- Použitelnost, přístupnost
- Seskupování položek, průvodce (wizard)
- Ošetření chyb, validace
Některé z požadavků spadají do více oblastí zároveň, proto se některé požadavky budou opakovat ve více oblastech.
Bezpečnost
Volba metody formuláře
- Formulář, který vykonává akce/mění stav, musí používat metodu POST. Stav formuláře (VIEWSTATE) nesmí být vyzrazován v URL.
- Formulář pouze poskytující údaje (vyhledávání, stránkování…) musí volit metodu GET a umožnit tak rekonstrukci stavu z URL.
- Formulář musí být zpracováván pouze tou metodou, která je mu určena – například formulář určený pro metodu POST nesmí být zpracován, je-li odeslán metodou GET, je nutné na straně aplikace zamezit obecnému zpracování bez ohledu na metodu požadavku, aplikace musí též odmítnout pokusy o podvržení obsahu formuláře v hlavičkách požadavku či cookies
Změna IP adresy klienta
Formulář musí být korektně zpracován i když se změní IP adresa klienta – zpracování nesmí být odepřeno.
Prevence vícenásobného zpracování
- Redirekt po zpracování POST formulářů – Formulář po svém odeslání v případě, že je zadání korektní a je zpracováno, provede redirekt se statusem 303 – See Other na stránku, která zobrazí informace o výsledku zpracování. Tak se zamezí možnému vícenásobnému odeslání téhož formuláře reloadem stránky nebo kliknutím na tlačítko Zpět.
- Zakázání odesílacích prvků po odeslání – Prvky pro odeslání (tlačítka, obrázková tlačítka) budou klientským skriptem zakázány při události submit formuláře. Tak se zamezí možnému vícenásobnému odeslání téhož formuláře.
- Unikátní identifikátor POST formuláře – Každý formulář musí obsahovat identifikátor, který zajistí, že tento formulář bude zpracován pouze jednou.
Prevence zneužití, útoků
- Enkódování interpretovatelného kódu před zobrazením – Každý vstup uživatele musí být před opětovným zobrazením ve stránce opracován tak, aby byly všechny interpretovatelné části encodovány a nedošlo k interpretaci vstupu jako kódu. Zamezí se tak problému Cross-Site-Scripting (XSS).
- Ošetření škodlivého obsahu před zpracováním – Každý vstup uživatele musí být před zpracováním opracován tak, aby byly odstraněny všechny nevalidní a nebezpečné vstupy. Zamezí se tak problému SQL Injection či nesprávného zpracování.
- Unikátní identifikátor POST formuláře – Každý formulář musí obsahovat identifikátor, který zajistí, že tento formulář bude zpracován pouze jednou. Zamezí se tak zneužití One-click-atack. Není-li formulář zpracován z důvodu chyby při validaci, platí alespoň jeden z následujících bodů
- musí být zachován původní identifiikátor
- může být vystaven nový dentifikátor, avšak původní musí být zneplatněn
- Datum platnosti POST formuláře – Formulář by měl obsahovat údaj o nejzazší platnosti formuláře – doporučuji 3dny. Částečně se tak zamezí One-Click-Attack.
- Timeout minimální doby zobrazení POST formuláře – Každý formulář musí odepřít zpracování údajů, pokud byl odeslán dříve než je doba requestu na první zobrazení formuláře + timeout 3 sekundy. Tak se zajistí, že ze zpracování budou vyloučeni automatizovaní klienti, roboti.
- Timeout maximálního počtu požadavků z jedné IP adresy (jednoho klienta) – Formulář musí odepřít zpracování údajů, pokud byl ze stejné IP adresy odeslán dříve než je doba requestu na první zobrazení formuláře + timeout 20-30 sec. Tak se zajistí, že ze zpracování budou vyloučeni automatizovaní klienti, roboti. Pro přesnější identifikaci je možno seskupit IP adresu klienta a HTTP hlavičky, které do komunikace mohou přidávat proxy servery, a hlavičky, které zpřesní identifikaci klienta:
REMOTE_HOST
HTTP_CLIENT_IP
HTTP_FORWARDED
HTTP_X_FORWARDED_FOR
X_HTTP_FORWARDED_FOR
X_FORWARDED_FOR
USER_AGENT
REFERER
- Kontrola HTTP referreru – V případě, že klient udává referrer, pak musí být zpracování odepřeno v případě, že referrer udává cizí doménu nebo cizí URL.
- Skrytá kontrolní otázka POST formuláře – Formulář obsahuje kontrolní otázku (např. radiobuttony „Jsem robot? Ano/Ne), tato je klientským skriptem automaticky vyplněna správně a skryta ze zobrazení uživateli. Tak se zajistí, že ze zpracování bude vyloučena většina automatických klientů, avšak většina uživatelů nebude otázkou nijak obtěžována. Některým uživatelům se otázka zobrazí, tito musejí mít možnost ji odpovědět správně -> tj, porozumět otázce. Tento mechanismus nahrazuje nepohodlnou a špatně přístupnou metodu CAPTCHA.
Ochrana a ukládání citlivých údajů
Pokud nejde o speciální registrační a zabezpečený formulář, měl by obsahovat upozornění, aby uživatel nevpisoval žádné citlivé a osobní údaje.
Ochrana osobních údajů
Ochrana osobních údajů probíhá podle zákona č. 101/2000 Sb., kde osobním údajem se rozumí jakýkoliv údaj týkající se určeného nebo určitelného subjektu údajů. Subjekt údajů se považuje za určený nebo určitelný, jestliže lze na základě jednoho či více osobních údajů přímo nebo nepřímo zjistit jeho identitu. O osobní údaj se nejedná, pokud je třeba ke zjištění identity subjektu údajů nepřiměřené množství času, úsilí či materiálních prostředků. Zpracovatel i správce osobních údajů byl měl být registrován u Úřadu na ochranu osobních údajů.
Součástí formuláře zpracovávajícího osobní data musí být nástroj pro jednoznačné projevení souhlasu se zpracováním osobních údajů – typicky checkbox, který nesmí být automaticky zaškrtnutý.
Nezasílání potvrzení na zadaný kontakt
Formulář nesmí umožnit zasílat potvrzení či kopie zadaných údajů na zadaný e-mail nebo jiný kontakt. Zamezí se tak zneužití před rozesíláním spamu, ale též vyzrazení zadaných údajů třetí straně (při překlepu nebo přesměrování na cílové straně).
Zabezpečený formulář
Formulář pro zpracování registračních (osobních) údajů musí být zpracován v zabezpečeném režimu HTTPS (zobrazen může být i v nezabezpečeném režimu). Musí obsahovat upozornění o zpracování citlivých údajů a o tom, jak je s údaji nakládáno v souladu se zákonem č. 101/2000 Sb.
V dalším pokračování článku dokončíme požadavky z oblasti použitelnosti, přístupnosti a ošetřování chyb. Snažil jsem se co nejvíce postihnout problematiku současných formulářových aplikací, která je roztříštěná mezi mnoho oblastí, tak abychom měli alespoň nějaké základní vodítko (checklist) jak udělat naši aplikaci maximálně vyhovující všem požadavkům – a může se tedy stát, že v článku nějaký bod či hledisko chybí. Budu rád, když je připíšete do komentářů :)
Mohlo by vás také zajímat
-
Šokující data od Microsoftu: Kyberútoky rostou o stovky procent!
8. listopadu 2024 -
Lék na phishing a apatii ve světě e-mailového marketingu
18. března 2024
Nejnovější
-
Jak rozšířit úložiště Macu za pětinovou cenu?
16. prosince 2024 -
Nové trendy v doménách pro osobní projekty – DIY, LIVING a LIFESTYLE
9. prosince 2024 -
Jak chránit webové stránky před Web/AI Scrapingem
27. listopadu 2024 -
Jaký monitor je nejlepší k novému Macu Mini?
25. listopadu 2024
patrik
Čvc 14, 2009 v 20:42„Prevenci vícenásobného zpracování“ je možné řešit kontrolou, jestli zadaný obsah ve všech inputech už v db neexistuje. Pokud ano, zápis se neprovede.
ehm
Čvc 15, 2009 v 15:35zbytecne ovsem namahas DB. Pac tam mas dalsi dotaz navic. Takhle k nemu nemusi dojit. Zvlaste pokud mas nejaky projekt z velkou navstevnosti snazis se ty dotazy omezit na minimum.
Pin007
Čvc 19, 2009 v 8:44Nejenom to, u tech hodne velkych projektu muze odeslani formulare pouze vytvorit zaznam v message queue a v DB jeste tedy ani nemusi byt nic provedene ;)
jirka8
Čvc 21, 2009 v 19:54Aneb jak vetsina webovych formularu nevypada :).