Input text bez mezer a symbolů

V základu bych zkusil -

Pak to samozřejmě můžeš řešit ještě přes JS a na straně serveru.

Pro základy je asi dobrý pattern, ale nezapomeň na to, že přes vývojářské nástroje jde smazat a člověk tam může napsat co chce… takže i přes to bych udělal escape na zablokování HTML. Ještě by se to mohlo bloknout na straně serveru…

Hogo:
„Pro základy je asi dobrý pattern, ale nezapomeň na to, že přes vývojářské nástroje jde smazat a člověk tam může napsat co chce…“
Až sem je to v pohodě.

„Ještě by se to mohlo bloknout na straně serveru…“
Pokud výsledná aplikace potřebuje cokoli ověřovat, vždy se to musí provést má straně serveru. Ověřování na straně klienta je vždy jen pro lepší UX. Ověřování na straně serveru je kvůli bezpečnosti.

„takže i přes to bych udělal escape na zablokování HTML.“
Myslím, že obrana proti XSS nebude to, co Vojtíšek tímto chce řešit. Spíš bych to viděl že to pole má být třeba username při nějaké registrací a chce vynutit určitý formát. Za tímto účelem mu escapování moc nepomůže.

Abych to shrnul.
1) Řešení od Ikki je v pohodě. Bude fungovat u většiny uživatelů. Ovšem 100 % ti nezaručí, že všichni ti to odešlou v takovém tvaru. A nemusí jít ani o hackera, stačí běžný uživatel se starým prohlížečem a ten mu tam dovolí napsat cokoli.
2) Pokud ti stačí, že to v 99 % funguje, tak máš hotovo. Pokud ale vyžaduješ, že to bude fungovat ve 100 % případů, musíš k tomu přidat i kontrolu na serveru. Koukni na funkci preg_match a použij téměř stejný pattern.
3) Co se escapování týče tak escapovat by se mělo vždy a vždy je to potřeba dělat podle kontextu. Při ukládání do databáze je jiné než při výpisu do HTML stránky. Pokud máš jistotu, že nějaký vstup má bezpečný formát, je teoreticky možné escapování vynechat. Není to ale dobrá praxe. Požadavky na vstup se mohou v průběhu psaní aplikace změnit a bylo by pak potřeba hledat, kde všude je ten vstup neošetřen. Proto je lepší při použití jakéhokoli uživatelského vstup použít vždy escapování dle aktuálního kontextu.

Keeehi:
„Spíš bych to viděl že to pole má být třeba username při nějaké registrací a chce vynutit určitý formát“
Jop, z této strany jsem to nebral, chápu… Akorát zase je tu věc, že pokud si člověk nastaví přezdívku "<!--", tak by bylo fajn to alespoň escapnout, ať se z toho stane &lt;!--. :)

Hogo:
Ano a ne. Jak jsem psal, escapovat je to potřeba vždy podle kontextu. Při ukládání do databáze přímo tento konkrétní řetězec by escapovaný být nemusel. Jelikož ale obecně nevíš, co od uživatele dostaneš, použiješ mysqli_real_escape_string, prepared statements, nebo nějakou databázovou vrstvu, co to dělá automaticky. Při výpisu do HTML stránky to bude potřeba escapovat tak, jak jsi psal. Použije se k tomu funkce htmlspecialchars. Ovšem HTML kontext není jediné místo kam to může PHP vypisovat. Například pokud se budou informace tahat ajaxem, pak se ty data objeví pravděpodobně v json kontextu. A tam jsou potřeba escapovat zase jinak než v HTML. PHP funkce json_encode pro vytváření jsonů je chytrá a potřebná escapování si vytváří automaticky, takže programátor nemusí nic dělat ručně.

Abych to shrnul, escapování by se mělo provádět až při výpisu a vždy podle kontextu. Tudíž nepoužít htmlspecialchars při ukládání do databáze ale až při výpisu dát z databáze do HTML stránky. A ač je HTML kontext nejběžnější a tudíž htmlspecialchars se používá nejčastěji, je dobré myslet na to, že existují i jiné a tam je potřeba použít jiné escapování.

phpfashion.com/escapovani-definitivni-prirucka

Pokud ošetříš HTML hned ve scriptu, tak ho nemusíš vypisovat jinde. Pokud se teď bavíme o přihlašovacím formuláři, tak si nemyslím, že by někdo potom chtěl přezdívku <!-- neescapovat. Jinak mysqli_real_escape_string je prakticky vlastně na nic, většinou se to blokuje na straně databáze, nebo se to ošetří jinak. Mě třeba moc nefunguje, pokud hodně potřebuji, využiju str_replace, aby se vypsal třeba místo ' spojovník…

Hogo:
„Mě třeba moc nefunguje, pokud hodně potřebuji, využiju str_replace, aby se vypsal třeba místo ' spojovník…“

Hmm. Čiže moja priateľka Jana si kúpi nový krém od L-Oreal Paris a potom spolu pôjdeme na obed do McDonald-s. Spýtam sa jej, či pôjdeme na koncert Guns N- Roses alebo Rag-n-Bone Mana... Web zameraný na výučbu angličtiny asi takisto neprevádzkuješ, teda aspoň dúfam.

„Pokud se teď bavíme o přihlašovacím formuláři, tak si nemyslím, že by někdo potom chtěl přezdívku <!-- neescapovat.“

Pri vkladaní do databázy ošetríme prezývku <!-- funkciou na escapovanie pre databázu (v prípade Mysqli to bude mysqli_real_escape_string). V databáze budeme mať uložené <!--.

Pri výpise do html kódu veľmi jednoducho použijeme v PHP na danú prezývku htmlspecialchars. Z <!-- vznikne čosi ako <!--, na obrazovku sa vypíše presne to, čo potrebuješ, čiže <!--.

Ošetrovanie dát v mojom ponímaní nemá aktívne meniť podobu dát (nie je to predsa hash ani šifra). Má zabezpečiť, aby bolo možné uložiť alebo vypísať znaky, ktoré by inak spôsobovali problém.

Já osobně jsem se zatím nejčastěji setkal s tím, že data pocházející od uživatele nikdy nemodifikujeme před vložením do databáze, abychom zachovali reálně ten vstup, který uživatel zadal. Pro vyhnutí se SQL injection a podobným zvěrstvům, to do té databáze vložíme tak, že jasně vymezíme co je naše "instrukce" a co jsou data. Typicky se takovým věcem říká prepared statements, či parametrized queries.

Tohle nám potom dává precedens, že cokoliv pochází z databáze je potřeba před vypsáním uživateli nejprve enkodovat, způsobem odpovídajícím kontextu (uprostřed JavaScript kódu, v CSS, nebo třeba někde mezi tagy v těle stránky...).

Hogo:
„Pokud ošetříš HTML hned ve scriptu, tak ho nemusíš vypisovat jinde.“
Tohle vymyslí každý začátečník. I já jsem to takto dělal. Praxí ale zjistíš, že je to většinou cesta do pekel. Je to jak píše mckay, data od uživatele chceš ukládat ideálně tak jak ti je poslal.

lionel messi:
Spíše jsem to myslel v přihlašovacím scriptu… ale jinak ano, chápu…
Keeehi a mckay:
Hm, je pravda, že ve světě programování se pohybuji tak nějak 4 měsíce, mám se co učit. Je pravda, že se mi stalo, že jsem ošetřil formulář a pak tam nefungoval žádný HTML tag, takže to nakonec bylo něco jako " Lorem <br> ipsum<p>dolor</p>…", což nebylo moc ideální. Někdy je fajn si to pak popřípadě ještě ošetřit přímo v databázi…