on-game | vs-web | vs-online | AAA WEBY
Hlavni panel

Bezpečnost aplikací


Bezpečnost aplikací

   Bylo by jistě zajímavé začít slovy již staří Římané… Bohužel právě oni stejně jako většina starobylých civilizací ani oni neměli ani tušení o internetu, webu a ani aplikacích. Doby se mění a tak dnes již webové aplikace patří k dennímu životu každého internetově gramotného uživatele. Firmy masově představují sebe a své výrobky na internetu, rozšiřuje se množství internetových obchodů, bankovnictví i aplikací určených čistě jen pro zábavu a komunikaci.
   Od dob začátků těchto aplikací se i v jejich vývoji a použití i přes jejich mládí hodně změnilo. Důvodem jsou různí chmatíci, kteří tráví svůj čas tím, že se snaží tyto aplikace zneužít probít a vytěžit. Proto se jedním z nových klíčových parametrů nejen webových aplikací stala úroveň jejich zabezpečení.
   O čem se vlastně budeme bavit? Řeč bude o základech útoků na aplikace a základních principech, jak jim zabránit. Nebudeme se soustředit na konkrétní příklady, protože bychom se museli soustředit na konkrétní kombinaci technologií. Držme se tedy obecných principů, které pak lze použít při konkrétní implementaci vašich aplikací.
   Proč útok podniknout? První věcí, kterou je třeba si uvědomit je motivace k útoku. Čím atraktivnější je obsah vaší aplikace, tím vyšší je motivace k jejímu napadení. Druhým faktorem je faktor užitku. Tento užitek nemusí být jen finanční ale může být i v poskytnutí výhody oproti jiným uživatelům. Vedle bankovních aplikací a obchodních portálů se tak stává cílem i obyčejná neplacená online hra. Dále je třeba si uvědomit, že cílem nemusí být ani vaše aplikace, uživatelské účty ale samotní uživatelé, přesněji jejich počítače a data na nich uložená.
Kudy lze útok provést?
   Při rychlém zamyšlení najdeme tři body, kde lze útok provést.

Server aplikace
   Útoky na servery aplikací jsou těmi z hlediska provozovatele nejčastější. Hned zde rozeznáváme několik tříd útoků. Nejznámějšími jsou

D.O.S.
   Cílem tohoto útoků není dostat se k datům, ale samotné odstavení služeb provozovatele. Útok se zpravidla provádí zahlcením serveru požadavky od uživatelů tak, aby server zkolaboval a pokud možno nebyl schopen nadále poskytovat služby. Nicméně už samotné znepřístupnění služby je pro provozovatele často velkou nepříjemností. Zkolabovat přitom může hned několik prvků. Může dojít k zahlcení připojení k internetu, tedy ke stavu, kdy server sice chce přijmout nebo odeslat data, ale přenosová linka je natolik vytížená, že data musí být zařazena do fronty nebo se je nepodaří odeslat případně přijmout vůbec. Další možností je zahlcení serveru množstvím požadavků, tedy požadavky vyčerpají počet současně možných připojení. V neposlední řadě pak zůstává samotná aplikace, tedy situace, kdy server sice požadavek přijal a zpracovává, ale jeho zpracování je pomalé nebo náročné na zdroje, což působí potíže při zpracování více takových požadavků. Pokud jde o aplikace, jednou z možností je ukládat výsledky takových procesů do cache a odtud je pak vracet po dobu jejich platnosti. Pokud jde o komunikační problémy, je možné je řešit buďto posílením HW sestavy, zavedením loadbalancingu serverů, navýšením přenosové rychlosti, optimalizováním počítačové sítě atd atd… není to můj obor a proto zde nebudu zacházet do větších podrobností.
SQL-Injection
   Oblíbeným druhem útoku proti aplikacím je tzv. SQL injection. Tedy postup, kdy se do parametrů, které jsou zpracovávány nad databází, zadávají takové parametry, které způsobí chybné zpracování. Jedná se o jedny z nejnebezpečnějších útoků. Jako příklad si představme stránku s přihlašováním, kdy uživatel zadává jméno a heslo. Programátor následně zpracovává tato data (v PHP) následovně:
$sql = „SELECT count(*) FROM users WHERE (username=’$username’) and (password=’$password’)”;

   Očekává přitom, že pokud je počet větší než 0, je uživatel autentikován správnými údaji. Co se ale stane, jestliže do hesla zadáme řetězec “’) or (‘’=’” ?
Výsledný SQL příkaz pak vypadá následovně:
SELECT count(*) FROM users WHERE (username=’administrator’) and (password=’’) or (‘’=’’)

   V takovém případě systém, využívající takový kód přihlásí uživatele „administrator“ a útočník se tak dostává do aplikace pod cizím účtem. Úroveň jeho vlivu se tak otvírá na úroveň oprávnění daného uživatele. V lepším případě může přednastavit účty všem uživatelům aplikace. V horším případě rovnou použije DROP DATABASE a ještě v horším případě tuto skulinu použije k ovládnutí serveru. A věřte mi, že to skutečně jde…
   Tomuto útoku se můžeme bránit s použitím různých technik. Jednou z nejobvyklejších a zároveň označovaných jako nejbezpečnějších je metoda escapování nebezpečných znaků. Prakticky to znamená že se některé znaky v řetězci nahradí escapovacími sekvencemi, které mají stejný význam, neporuší se tím ale SQL příkaz jako takový. Zrádné zdání bezpečnosti této techniky spočívá ovšem v tom, že tyto escape sekvence se mohou přeložit na cílové znaky ještě před vstupem do databáze a pak tato ochrana dopadne jako lichá. Další metodou je vyhledávání klíčových slov jako DROP, ALTER a podobných, ovšem zde narážíme na fakt, že některé SQL servery jsou schopné přijmout data v různých podobách, pak takový řetězec projde lexikální kontrolou ovšem napáchá neplechu. Metodou, která se označuje jako nejbezpečnější je používání parametrizovaných SQL dotazů a uložených procedur. Řetězec pak prostupuje do databáze pouze jako hodnota parametru. Pokud se pak vyvarujeme sčítání řetězců, máme téměř vyhráno.

Komunikační kanál
   I samotný kanál, pomocí kterého komunikuje klient se serverem, se často stává cílem útoku. Tyto útoky jsou označovány jako Man in the Middle, v praxi se jedná o to, že se útočník vetře jako prostředník pro komunikaci mezi klientem a serverem. Celou komunikaci pak odposlouchává případně vhodným způsobem modifikuje, kupříkladu množství peněžních prostředků, cílový účet nebo jiné klíčové informace. Do této skupiny útoků spadá několik druhů útoků, které se liší konkrétním postupem. Proti těmto druhům útoků se dá bránit velmi obtížně. Jednou z možností je komunikace pomocí SSL kanálů nebo vkládání ověřovacích informací, které ověřují obsah… taková implementace je ale velmi krkolomná.

Klientský počítač
   Klientský počítač je napadán často útoky řazenými do skupiny Man in the Browser. V globále se jedná o to, že to, co vidí uživatel je jen zdánlivě v jeho moci. Klíčová data jsou modifikována během procesu odesílání a při zobrazování uživateli tak, aby uživatel nic nepoznal. Jiným druhem útoku je monitorování zobrazovaných stránek a odesílání dat a odesílání klíčových dat na domovský server útočníka. Jinou možností zneužití browseru je například možnost nasadit místo browseru vlastní aplikaci, pomocí které bude samotný browser spouštěn ovšem klient si tím zároveň otevře terminál pro ovládání vlastního počítače útočníkem. Útok je často prováděn instalováním doplňků, activeX prvků, ale zde se uplatňuje i zvláštní skupina útoků označovaných jako X-site scripting nebo CrossSite scripting . V praxi se jedná o to, že uživateli je umožněno vložit skriptovaný obsah, který způsobí takovou modifikaci zobrazované stránky takovým způsobem, že dojde alespoň ke znehodnocení obsahu nebo dokonce k převzetí řízení browseru. Ačkoliv tento druh vypadá jako méně škodlivý, může vést k fatálnímu kompromitování nejen probíhající komunikace, ale zároveň k otevření brány pro jiný druh útoku. Ochrana proti tomuto útoku je překvapivě jednoduchá a spočívá v zabránění vložení jakéhokoliv aktivního obsahu do vašich stránek.

   Tímto jsme si představili základy útoků na aplikace. Cílem tohoto článku bylo seznámit se s alespoň základními nebezpečími, která na nás a naše aplikace číhají a vytvořit si tak znalosti nutné pro vybudování jejich obrany a zajištění bezpečnosti jak našich dat a serverů tak i bezpečnosti našich uživatelů.



Známka 1,00 | Přečteno 2186 x | Smaž | 20/01/2008 | Autor: genesis |
Komentařů: 8 | Vstup do diskuse |
Sdílet

Abyste mohl hodnotit tento článek, tak musíte být přihlášen. Nemáte ještě zřízený účet ? Registrujte se zde.
Všechna práva vyhrazena, © 2006 Team on-game

Optimalizováno pro 1024x768 a prohlížeče IE, Mozilla Firefox a Operu

ip:38.107.179.219, čas:0.00199604034424, sql:10