Nejčastější chyby v zabezpečení webů

Přístup ke složkám a souborům

Častou chybou administrátorů, zejména pak juniorů, je zpřístupnění některých složek na serveru s plnými právy pro kohokoli. Důvodem bývá obvykle usnadnění práce, kdy je potřeba do určité složky umísťovat soubor uživatelů. Fyzicky soubor ukládá Apache (v případě PHP), ale kdo by definoval práva tak složitě, když to jde jednoduše. Tím, že administrátor povolí do složky přístup komukoli, může vzniknout mnoho problémů. Stejně jsou na tom pak soubory, kterým jsou tato plná práva přidělena. Riziko útoku je velké. Neméně závažný prohřešek je, pokud je povoleno zobrazení položek složky. To by mělo být zakázáno přinejmenším souborem „.htaccess“.

Databáze a administrační rozhraní

Je zřejmé, že heslo do databáze by mělo být bezpečné. Mělo by být ale také bezpečně uloženo. Ideální je, pokud je i v konfiguračním souboru nějakým způsobem šifrováno. Když už by se někdo dostal k šifře hesla, nemusel by najít způsob, kterak jej dešifrovat. Problémem u některých oblíbených redakčních systémů (např. Joomla) je fakt, že instalátor vytvoří standardizovaný účet nejvyššího admina. Pokud si jej administrátor nezmění, hrozí riziko, že server někdo napadne a změní jeho obsah.

Umístění e-mailové adresy na webu

Ač se to možná nezdá, publikovat e-mailovou adresu na jakémkoli webu je hazard nejvyššího kalibru. Jakmile na stránku narazí spamovací robot, máte o přísun kvalitního spamu postaráno. Mnohem lepší je využít kontaktního formuláře, který směřuje na skript, jenž toto přeposlání vzkazu zařídí přímo na serveru. Za jistých okolností je možné e-mailovou adresu uvést, je k tomu ale zapotřebí drobné finty. Znak zavináče je nutno v kódu stránky nahradit HTML entitou. Blíže se o tomto způsobu ochrany e-mailových adres dočtete v tomto článku.

Přihlašování uživatelů

Mohlo by se zdát, že v případě využití dobrého způsobu hashování uživatelského hesla je vše v pořádku a přístup je tak bezpečný. O samotné bezpečnosti dnešních hashovacích algoritmů jsme psali v tomto článku. Z pohledu serveru a provozovatele je vše v pořádku. Co když ale mezi vrstvou prohlížeče a serveru stojí ještě nějaký prvek, který hesla odchytává? Uživatele může teoreticky někdo sledovat na síťové vrstvě a zjišťovat pak jeho data. K samotnému hashování dochází v drtivé většině případů až na serveru, což může být již pozdě. Administrátoři by tedy měli zajistit, aby byla hesla kódována ještě před jejich odesláním přes síť. K tomu může posloužit prastarý Javascript, kdy je heslo nějakým, byť jednoduchým, způsobem šifrováno a na serveru pak dešifrováno.

Diskuze a návštěvní knihy

Kdo z vás někdy zprovoznil návštěvní knihu nebo diskuzi na svých stránkách bez zabezpečení, ten asi ví, co weboví roboti dokážou udělat během několika dnů. Pokud je v diskusi nebo návštěvní knize využit běžný formulář bez zabezpečení, dočkáte se během několika dnů desítek, stovek nebo i tisíců „hodnotných“ příspěvků propagujících pornografické weby či přípravky na hubnutí nebo potenci. Kolega, který svou diskuzi na osobních stránkách nezabezpečil, po měsíci zjistil, že má v diskuzi na 10 tisíc příspěvků od robotů.

Zvolil tedy nejméně náročnou ochranu, kdy žádal po diskutujících návštěvnících, ať přepíší určité číslo vypsané slovy do speciální kolonky. Bohužel kontrolu tohoto výrazu prováděl pomocí Javascriptu, takže během týdne se historie zopakovala a databáze byla plná generovaných diskuzních příspěvků stejného charakteru, jak to bylo v případě bez jakéhokoli zabezpečení. Následovala tedy kontrola podobného čísla pomocí ověřovacího PHP skriptu. Toto řešení, ač taktéž jednoduché, zatím roboti neobešli. Jak se v minulosti ukázalo, ani často užívaná Captcha není neprůstřelná.

Závěrem

Vývoj webů je vždy souboj vývojářů se strůjci útoků. Udělat v dnešní době dobře zabezpečený web je nadlidský úkol, protože člověk časem zjistí, že na určitou oblast zapomněl. Nezbývá než stále doplňovat funkční projekty o nové druhy ochran a být na pozoru.