Typy útoků

Aby bylo možné zabezpečení webu plánovat, potřebujeme vědět, z jakých směrů je vlastně možné potenciální pokusy o narušení bezpečnosti očekávat. Podívejme se nyní zhruba na druhy útoků, jejich nebezpečnost a základní možnosti obrany. Důležitá je i náročnost útoku- čím je provedení útoku složitější, tím větší motivaci musí útočník mít, aby to vůbec zkoušel, respektive je méně pravděpodobné, že to vůbec někdo bude zkoušet.

Útok hrubou silou

Popis:

V nejprimitivnější variantě útočník prostě zadá cizí jméno a heslo si tipne. Pokročilejší varianta využívá robota, který prostě zkouší různá hesla (buď prostě všechny kombinace znaků, nebo má nějaký slovník, ze kterého hesla bere) a doufá, že se "trefí". 

Náročnost:

Minimální. Může to udělat prakticky každý

Nebezpečnost:

Závisí na tom, jaké si uživatel zvolil heslo. Tady přichází ke slovu minulý článek o bezpečnosti hesel z pohledu uživatele. V případě, kdy uživatel má silné heslo a útočník nemá indicie, jaké to heslo je, jsou útočníkovy naděje minimální. Při použití robota ale může nastat jiný problém, a sice že robot se bude zkoušet přihlašovat tak často, že zahltí server požadavky a ten pak nebude schopný reagovat na požadavky "lidských" uživatelů, tj. z pohledu uživatele to způsobí výpadek webu (takzvaný DoS útok)

Možnosti ochrany:

Tady je to z velké části na samotném uživateli. Programátor může udělat to, že bude nutit uživatele k volbě dostatečně silného hesla (na druhou stranu je třeba to vyvážit tak, aby to uživatele zbytečně neotravovalo). Dále je možné omezit maximální počet neúspěšných přihlášení za nějaký časový interval. Příklad: po deseti neúspěšných pokusech o přihlášení ke stejnému účtu se třeba na 15 minut zablokují další pokusy o přihlášení k danému účtu.

Prolomení hesla

Popis:

Útočník se pokusí získat záznam oběti z datového úložiště na serveru a potom z toho záznamu získat heslo.

Náročnost:

Závisí na návrhu aplikace. První problém útočníka je získat data o oběti ze serveru. To není snadné, ale často lze využít nějaké přehlédnuté chyby v aplikaci, případně jako v případě libimseti.cz získat kopii zálohy databáze. Druhý problém je ze získaných dat vytěžit informace, které by byly pro útok použitelné. S adekvátním zabezpečením aplikace to je velice obtížné.

Nebezpečnost:

Opět závisí na návrhu aplikace. Hodně aplikací vpodstatě spoléhá na to, že se k záznamům v databázi nikdo nepovolaný nedostane. V takovém případě už samotné přečtení databáze představuje vysoké bezpečnostní riziko. Při dobrém zabezpečení je ale nebezpečí nízké.

Možnosti ochrany:

Na možnosti ochrany proti tomuto útoku se podíváme dále v článku.

Odposlouchávání

Popis:

Útočník s pomocí speciálního software (tzv. sniffer) odposlouchává komunikaci na síti. Odchytí formulář odesílaný uživatelem na server a pokusí se z něj vydolovat heslo. 

Náročnost:

Hlavní náročnost tohoto útoku spočívá v tom, že odposlouchávat data lze jen v místech, přes která ta data proudí. Útočník musí proto získat k nějakému síťovému prvku mezi obětí a serverem takový přístup, aby mohl sledovat komunikaci protékající tím síťovým prvkem. Pokud oběť je v lokální síti postavené z hubů (které všechna data přeposílají všem připojeným počítačům), stačí útočníkovi být jen ve stejném segmentu lokální sítě jako oběť. Dále útočník potřebuje ještě zmíněný program- sniffer, ale ten se dá celkem snadno stáhnout z webu.

Nebezpečnost:

Vysoká, pokud aplikace není proti tomuto útoku chráněna.

Možnosti ochrany:

Použití šifrované komunikace (protokol https://) znemožní (respektive o mnoho řádů zesložití) odposlouchávání. Odposlechnutí hesla lze ale zabránit i bez šifrované komunikace, což rozebereme dále v článku.

Man in the middle

Popis:

Útočník se "postaví do cesty" mezi oběť a server tak, aby komunikace mezi obětí a serverem proudila přes něj. Následně pak může nejen číst, ale i modifikovat data, která posílá uživatel serveru nebo server uživateli. 

Náročnost:

Vysoká. Útočník musí získat přístup k síťovému prvku nebo počítači na cestě mezi obětí a serverem. Dále útok vyžaduje speciální software a určité znalosti. Při použití šifrované komunikace tento typ útoku prakticky není možný.

Nebezpečnost:

Vysoká. Pokud se útočníkovi už podaří dostat do pozice "man in the middle", je úspěch útoku téměř zaručen.

Možnosti ochrany:

Vpodstatě jediná účinná obrana proti man in the middle útoku je použití šifrované komunikace (protokolu https://)

Převzetí relace (session stealing)

Popis:

Útočník nějakým způsobem od oběti získá její ID relace, ve které má platné přihlášení na serveru. Následně tuto relaci začne vydávat za svou a tím převezme regulérní přihlášení oběti. 

Náročnost:

Střední až vyšší v případě, že aplikace není proti tomuto útoku chráněna. Útočník musí hlavně vylákat z oběti její ID relace (session ID). Pokud aplikace předává ID relace jako parametr v adrese stránky, nemusí to být tak velký problém- stačí přesvědčit oběť, aby třeba e-mailem poslala odkaz na nějakou stránku na příslušném webu... a součástí adresy bude i ID relace. Při dobrém návrhu aplikace je však tento útok téměř nemožný.

Nebezpečnost:

Při dobrém návrhu aplikace je nebezpečnost minimální.

Možnosti ochrany:

Nepředávat ID relace v adrese stránky. Spárování relace s údaji o uživateli (například IP adresa, použitý prohlížeč apod.) a odhlášení uživatele v případě, že se tyto údaje změní, také pomáhá výrazně omezit riziko tohoto útoku.

Získání kontroly nad aplikací

Popis:

Útočník nějakým způsobem získá možnost provést na serveru svůj vlastní kód (buď získá přímo přístup na FTP, nebo třeba přes script injection a podobně)

Náročnost:

Závisí na aplikaci, při dobrém návrhu aplikace by toto nemělo být možné. I u špatně navržené aplikace bývá ale často realizace tohoto útoku složitá (naštěstí).

Nebezpečnost:

Kritická. Samotné provedení tohoto útoku je mnohem horší bezpečnostní riziko, než případné získání cizího hesla.

Možnosti ochrany:

Tento bod tu je hlavně z důvodu, že podobný druh útoku často padne v diskusi ve chvíli, kdy už někdo navrhne dostatečně "neprůstřelné" zabezpečení hesla. Je potřeba si uvědomit, že samozřejmě každé zabezpečení je v nějakém kontextu. Ve chvíli, kdy někdo získá možnost ovlivňovat samotný kód aplikace, už čelíte mnohem vážnějšímu narušení bezpečnosti, než je prozrazení nějakého hesla. V tu chvíli už nemá smysl se bavit o zabezpečení hesel- hlavní úkol je zabezpečit aplikaci, aby k něčemu takovému nemohlo dojít. Ale to je na jiný článek. 

Tolik k tomu,z jakých směrů lze zhruba očekávat pokusy o neautorizovaný přístup k aplikaci. Na další stránce se podíváme na možné metody zabezpečení.