Zabezpečení – CSRF, XSS Tomáš Hulák, Miroslav Kořínek

Osnova Co je CSRF? Typy útoků Shrnutí Obrana proti CSRF Co je XSS? Typy útoků Obrana proti XSS

Co je metoda CSFR? Cross-Site Request Forgery „podvržení požadavku mezi různými stránkami“ Další pojmenování: Cross-Site Reference Forgery, Session Riding nebo Confused Deputy attacks

Útok na mail1/2 Jedním z předpokladů pro úspěšný útok je, znát napadanou aplikaci/web příklad – aplikace webmailu - odesílání ů bez vědomí uživatele Jednoduchý formulář posílaný na adresu serveru ◦ složenou ze jména serveru a hodnoty „action“ ve značce „form“ – tedy „ útok – zaslání u automaticky bez vědomí uživatele

Útok na mail 2/2 Odesílání položek metodou GET jakýkoliv obrázek na webové stránce generuje GET požadavek ◦ jména formulářových prvků i jejich hodnoty jsou v takovém případě součástí URL Útočník na své stránce vloží kód pro „zobrazení“ obrázku : URL obrázku nahradí GET požadavkem, ◦ je totožný s vyplněným a odeslaným formulářem webmailu, na který probíhá útok. Když oběť přejde na útočníkovu stránku se „zákeřným obrázkem“, ◦ Dojde k odeslání u na adresu

Útok rozšířením na metodu POST Server zpracovává pouze požadavky poslané metodou post ◦ útočníkovi stačí, když je zapnutý JavaScript v prohlížeči oběti Základním zabezpečením může být přihlášení uživatele a uchovávání informace o přihlášení v cookies prohlížeče (požadavky od nepřihlášených uživatelů bude aplikace ignorovat)

Další možné hrozby CSRF 1/3 Příklad vytvoření trvalého platebního příkazu na útočníkův bankovní účet z bankovního účtu oběti:

Další možné hrozby CSRF 2/3 Sledování elektronické pošty oběti. Útočník ◦ musí vědět, jakou webovou aplikaci pro přístup k elektronické poště oběť používá a jak se v ní mění nastavení účtu. ◦ Připravit si formulář pro přidání pravidla „automatického přeposílání všech ů oběti na adresu útočníka“:

Další možné hrozby CSRF 3/3 Útok na redakční systém. Jednoduchým požadavkem lze smazat veškeré články.

Shrnutí faktů o CSRF Automatický útok je možný pouze, pokud oběť navštíví útočníkovu stránku, která odešle předem připravený formulář Ve výsledku je jedno, zda se použije metoda POST či GET pro odesílání formulářů – rozdíl pouze v tom, že při metodě GET není vyžadován zapnutý JavaScript – je zranitelnější. Zabezpečovací mechanizmus pomocí uložené relace v cookies nás nemusí ochránit - Pokud je uživatel přihlášen a zároveň navštíví útočníkovu stránku, cookies se webové aplikaci stejně odešlou. Útok proběhne z prohlížeče oběti (která je přihlášena do aplikace) a odeslání formuláře směřuje do aplikace oběti (do které je oběť přihlášena). Útočník musí znát webovou aplikaci – musí mít připravený formulář. Útočník musí oběť přesvědčit k návštěvě jeho stránek.

Jak se bránit proti CSRF (ze strany serveru) Základní obranou jsou „podepsané“ formuláře tzn. formulář s „tajnou“ hodnotou generovanou serverem. Serverová část aplikace při generování formuláře vygeneruje i pole s tajnou hodnotou a tu si zapamatuje. Uživatel při odeslání formuláře odesílá i tajnou hodnotu. Serverová část aplikace přijme jen takový formulář, pokud přijatá tajná hodnota odpovídá zapamatované, nedávno vygenerované hodnotě. Tajná hodnota buď pro každý formulář, nebo po celou dobu platnosti uživatelské relace.

Jak se bránit proti CSRF (ze strany klienta) Pokud si nechceme na straně serveru žádnou tajnou hodnotu pamatovat, můžeme ji také vygenerovat na klientské straně a uložit ji do cookies, jenž se automaticky odesílají s každým dotazem na server a klientská část aplikace pak musí připojit ke každému odesílanému dotazu na server tajnou hodnotu. Na serverové části aplikace pak stačí zkontrolovat, zda se obě hodnoty shodují.

CSRF Zajímavost: Trvalou tajnou hodnotu používá například webmail na Seznamu. Používá k tomu proměnnou „hashId“ odesílanou s každým formulářem. Dříve byla tato hodnota stejná i po novém přihlášení uživatele, nyní se při každém přihlášení generuje hodnota nová. I taková společnost jako Google trpěla CSRF zranitelností. Bylo možno změnit bez vědomí uživatele používaný jazyk na stránkách vyhledávače. Třeba taková automatická změna jazyka do arabštiny.. ◦ Příklad automatické změny preferovaného jazyka vyhledávače na němčinu (již nefunguje):

Co je to XSS? Cross Site Scripting Metoda narušení webových stránek zkrz skripty Podstrčení javascriptového kódu do cizí stránky Tři typy útoků

Typ 1(lokální/DOM based) neošetřené přenesení proměnné z URL adresy do javascriptu Normální odkaz Upravený odkaz

Typ 2 ( non-persistent/reflected) Nejběžnější typ útoku Pro dynamické WWW Zjištění proměnné, která se vypisuje ve stránce PHP příklad

Typ 3 (persistent/stored) nejnebezpečnější možnost Jen pokud je obsah stránky generován z databáze Vložení napříkal jako část komentáře Script se vykoná u každého klienta

Typy nebezpečí HTML tagy ◦ Hello world Javascript ◦ Phishing ◦ Cíl formuláře ◦ Cookies – session id

Session-hijacking Předávání session-id ◦ Parametr v URL ◦ Skryté formulářové pole ◦ Cookies Nikdy nevkládat SID do URL! ◦ Logy ◦ Historie prohlížeče ◦ Referer ◦ SEO

Cookies httponly = 1 (SID není dostupné pro JS) ◦ IE 6, Firefox , Opera 9.5 Ajax – XmlHttpRequest ◦ Firefox 3.1, IE 8

Obrana proti XSS odfiltrovat „nebezpečné“ znaky z uživatelského vstupu Jako parametry URL přenášet jen číselné hodnoty Vypnutí JavaScriptu Nebezpečné tagy: ◦ přímo ve skriptu ◦ v HTML komentáři ◦ přímo v CSS

Zdroje site-request-forgery-a-jak-se-branit/ site-request-forgery-a-jak-se-branit/ protection protection zabezpeceni-stranek.html