Bezpečnost webové aplikace lze posuzovat a zajišťovat na mnoha různých úrovních a vrstvách. Počínaje fyzickou ochranou síťové infrastruktury a počítače, na kterém běží aplikační či databázový server, a konče zabezpečením operačního systému, souborového systému, databázového stroje, síťové komunikace apod. Pro téma této práce je klíčová bezpečnost samotné aplikační vrstvy. K ní uvádí [20] následující obecná doporučení. Některá z nich jsou podrobněji rozebrána v dalších podkapitolách.
Uživatelské vstupy do systému i výstupy ze systému jsou kritickým místem. Měly by být proto kontrolovány, zda obsahují jen a pouze to, co by obsahovat měly. Nejlepší strategií je povolit pouze co nejúžeji explicitně definovaný obsah a všechna ostatní data zahodit. Například pokud se na vstupu očekává rodné číslo bez lomítka, pak jsou nepřípustné všechny hodnoty jiné než devítimístné či desetimístné číslo. Častou chybou je filtrování jen známých nebezpečných vstupů s tím, že vše ostatní je do aplikace propuštěno.
Po jakémkoliv kritickém selhání je nutné bezpečně ukončit všechny otevřené relace a uvést aplikaci i její data do konzistentního stavu. Selžou-li bezpečnostní mechanizmy, měly by skončit v takovém stavu, kdy budou alespoň vše zamítat, místo aby cokoliv povolovaly. Například při selhání přístupového mechanizmu k modulům by aplikace měla zakazovat přístup k jakémukoliv modulu, místo aby všechny moduly paušálně zpřístupila.
Uživatelsky příliš složitý bezpečnostní mechanizmus povede k tomu, že uživatelé přestanou aplikaci používat nebo se budou pokoušet tento mechanizmus obcházet. Základním pravidlem je proto mít jej v rámci možností co nejjednodušší. Zásada co největší jednoduchosti a přehlednosti platí analogicky i pro administrátorské rozhraní či API knihovny poskytující funkce související s bezpečností aplikace.
Programátoři by se měli snažit používat již hotové knihovny. U jakékoliv úlohy je velmi pravděpodobné, že ji v minulosti někdo řešil a že její implementace je někde k dispozici. Znovupoužití hotových knihoven s sebou nese dva hlavní přínosy. Jednak je efektivní, při vývoji se ušetří drahý čas, který by se musel věnovat vlastní implementaci takové úlohy. Navíc jsou veřejné knihovny odzkoušené, v praxi prověřené a jakékoliv případné chyby jsou již s velkou pravděpodobností opravené.
Nikdy se nelze spoléhat na 100% funkčnost jakékoliv komponenty. Předvídání okamžiků nečekaných selhání je obtížné. Proto je důležité pro takové případy zajistit a předem naplánovat postup jejich řešení.
Každý systém je pouze tak dobrý a bezpečný, jako jeho nejslabší článek. Je proto důležité o těchto ohrožených místech vědět a neutěšovat se ostatními dobře zabezpečenými částmi aplikace.
Dlouhodobě je nebezpečné spoléhat se na to, že případný útočník nezneužije některého slabého místa aplikace jenom proto, že se o něm nedozví. Obecně není vhodné mít bezpečnostní politiku založenou na zatajování rozhodujících skutečností. Nejlépe na tom z tohoto pohledu v dlouhém období bývají open–source aplikace, jejichž případné implementační chyby jsou všem přístupné a tudíž obvykle rychle odhalené a opravené.
Uživatel by měl mít v aplikaci přístup jen a pouze k těm částem, které skutečně potřebuje využívat, nikoliv k těm, které by někdy potenciálně mohl využít. Oprávnění každého uživatele by tak měla být co nejmenší možná. Je žádoucí rozdělit dílčí pravomoci rovnoměrně a zároveň zcela jasně mezi více různých uživatelů.
Obsah stránek vyjadřuje osobní názory, postoje a zkušenosti autora. Copyright © 2004–2010 Jan Tichý.