Penetrační testování

Úvod do penetračního testování

 

Co je penetrační testování?

Penetrační testování je způsob, jak ověřit bezpečnost nějakého systému. Provádíme ho za účelem odhalit nedostatky v systému. Můžeme testovat aplikace, operační systémy i chování zaměstnanců.  V tomto dokumentu se budeme zabývat způsobem testování webových aplikací.

 

Proč bychom měli aplikace testovat?

Aplikaci testujeme za účelem předejít reálným bezpečnostním incidentům. Nahlížíme na aplikaci očima útočníka, který se snaží způsobit vývojářem nezamýšlené chování aplikace. Tímto předcházíme potencionální ztrátě financí, zákazníků nebo úniku citlivých údajů.

 

Etika

Když chceme aktivně testovat, vždy musíme mít nejen písemný souhlas vlastníka aplikace, ale také souhlasy všech lidí, kterých by se mohlo testování nějak dotknout. Tím myslím poskytovatele internetu, poskytovatele hostingových služeb, správce doménových jmen etc. Při testování provádíme úkony, které by pravěpodobně prováděl i útočník a tak je potřeba se nějak odlišit od lidí, kteři provádí trestní činnost. Musímě předpokládat, že by se situace obrátila proti nám a například by někdo podal trestní oznámení. Tester poté musí mít důkazy o legálnosti každého jeho úkonu. Před jakýmkoliv testem se musí stanovit jasné mantinely. Určí se čas, cíle testu (adresy, domény, emaily, osoby) a často i něco, co vás odliší od ostatních při zpětném šetření (user-agent, IP, specifická hlavička HTTP etc.).

 

Report

Po skončení testu podáváme klientovi tzv. report, ve kterém ho seznamujeme s celkovou situací a v jednotlivých sekcích mu podáváme informace o jeho aplikaci. Rozdělení sekcí je ponecháno na testerovi. Tester si může zvolit tzv. metodiku testování (popis metodik si ukážeme později) a ta má své vlastní rozdělení sekcí.

Každá oblast aplikace, která obsahuje tzv. vektor útoku, musí obsahovat stručný popis, jak by případný útočník mohl chybu využít, popsat potencionální následky zdařilého zneužití tohoto vektoru, dokázat přitomnost chyby (tzv. POC - Prove of Concept) a volitelně i nárys toho, jak by klient mohl tomuto zabránit.

Report může mít libovolnou podobu (např. PDF, HTML, PPT, Word etc.). Je důležité klást důraz na přehlednost! Musíme také počítat s tím, že zadavatel testu pravděpodobně předá naši zprávu programátorům, kteří pomocí naší zprávy aplikaci postupně zabezpečí.

 

Typy penetračních testů

Penetrační testy se rozdělují na tři základní skupiny podle toho, kolik informací klient poskytuje testerovi. Tímto můžeme simulovat jednotlivé scénáře.

Black box

Tester neví defakto nic jiného než adresu webového serveru a ke všemu ostatnímu se musí dostat sám. Nemá přístup ke kódu, nezná funkcionalitu jednotlivých komponent a neví nic o prostředí běhu aplikace (webový server, HW, hosting etc.). Tento typ testů provádíme, jestliže klient chce aplikaci otestovat vůči útočníkovi, který nic z výše popsaných věcí nezná a takových útočníků bude pravěpodobně většina. Klient si tento typ testu může vyžádat, aby si ověřil, zda-li je jeho aplikace chráněna proti vnějším útočníkům.

Grey box

Tester je obeznámen s funkcionalitou komponent, ale neví, jaký je zdrojový kod. Tento typ testování se aplikuje, pokud chceme aplikaci otestovat proti útočníkům, kteří jsou obeznámeni s funkcionalitou aplikace. Může jít o řadové zaměstnance firmy nebo také o útočníka, který se k informacím o aplikaci dostal přes chybu zaměstnance.

White box

Tester dostane informace o všem, o co si zažádá (hesla, zdrojové kody etc.). Tento typ testování se aplikuje, pokud klient chce provést vnitřní audit aplikace a chce zamezit i takovým útokům, ke kterým by při black box testingu nemohlo logicky dojít a které vyžadují znalost zdrojového kódu. Tester prochází aplikaci soubor po souboru a hledá místa, která by se mohla stát vektorem útoku. Tester zároveň ověřuje vedlejší faktory, jako je dostatečná síla hesel, možnost přístupu zaměstnanců k údajům, které nepotřebují ke své činnosti etc.

Metodiky testování

 

Co to je metodika?

Metodika testování je způsob přístupu k penetračnímu testování. Rozděluje ho do několika částí a říká nám, co bychom v jednotilvých částech měli dělat. Testování je pak systematičtejší a efektivnější. Metodika také často určuje samotnou filosofii PT, tzn. jak by k němu měl tester přistupovat, co by mělo obsahovat etc. Níže ukážu, jaké metodiky existují a popíšu jejich filosofii, popř. jejich klady a zápory. Nakonec vypracuji tabulku, kde jednotlivé metodiky ohodnotím.

OSSTMM (Open Source Security Testing Methodology Manual)

Metodika, která je určena pro testování firemní a vládní bezpečnosti. Je rozložena do šesti modulů. Určuje mezinárodní standard penetračního testování. Kategorizuje bezpečnosti do počitatelných komponent.

Rozděluje testy do šesti skupin:

 

page13image2992.jpg

Metodika se zabývá bezpečností obecně a její filosofií. Testování webových aplikací tedy nepopisuje tak detailně jako ostatní metodiky.

http://osstmm.com

OWASP (Open Web Application Security Project)

Tato metodika vznikla na základě neziskové činnosti lidí, kteří se dlouhodobě snaží vylepšit bezpečnost na internetu. Dle mého názoru je jednoznačně nejobsáhlejší, co se týče tématu webové bezpečnosti. OWASP Foundation pracuje na dvou typech projektů. Za prvé na vývojářských projektech, kde OWASP figuruje jako vývojář a vyvíjí nástroje, které přibližují internet k jejich představě a za druhé projekty dokumentační, které se snaží dokumentovat bezpečnost (průvodce testováním webů, code snippets etc). Tato metodika má velkou výhodu v tom, že je ji možné vložit do jednotlivých fází SDLC.

http://owasp.org

 

ISSAF (Information Systems Security Assessment Framework)

Metodika strukturovaná do frameworku. Testování rozděluje do 9 kroků. Zaměřuje se na webové aplikace.

RSA

Metodika založená na úrovni nebezpečí jednotlivých vektorů. Rozděluje je do pěti úrovní: Critical, High, Medium, Low a Informational. Úrovně jsou rozděleny podle bodů, které rozděluje metodika. Z mého pohledu je to nejlehčí a nejpřehlednější metodika, problém je, že na bezpečnost nahlíží pouze a jen ze stránky webových aplikací, což například OWASP nedělá.

 

Souhrn metodik

 

Metodika penetračního testování Kroky při testování Výhody
OSSTMM 6 kroků Mnoho různých testů
OWASP 9 kroků Code snippets, Web Goat, DVWA, mnoho různých návodů
ISSFS 9 kroků Jasný a pochopitelný postup při testování
RSA 6 kroků Výhoda v bodování jednotlivých vektorů

Všechny metodiky mají společné rysy, co se týče hlavního rozložení testu:

Získávání informací

V této části se metodiky zabývají získáváním informací o webovém serveru a aplikaci. Tato část zahrnuje průzkum Search enginů, průzkum DNS záznamů, identifikaci serveru a jeho infrastruktury etc.

Průzkum funkcnionality

Tato část zahrnuje bližší prozkoumání fungování aplikace, což zahrnuje průzkum startovacích bodů aplikace, vztahy mezi jednotlivými komponentami, rozdělení rolí, způsob přihlašování etc.

Exploitace

Nyní už tester má všechny potřebné informace a může začít testovat jednotlivé komponenty jak po stránce technické, tak po logické.

Automatické nástroje

 

Úvod

 

Při penetračním testování často provádíme úlohy, které lze provádět automaticky pomocí automatických testerů a tím zvýšit efektivitu celého testu. Je nutné si ale také uvědomit limity těchto nástrojů. Největším omezením je nepřizpusobivost konkretní aplikaci, to znamená, že programy jsou psané obecně pro všechny typy aplikací a nejsou schopny se přizpůsobit testované aplikační logice.

 

V čem jsou automatické skennery dobré?

  1. mapováním struktury aplikace
  2. vyhledávání vstupů
  3. sběr a analýza dat (emaily, citlivé údaje)
  4. detekování základních bezpečnostních rizik (XSS, CSRF, RFI,LFI etc.)
  5. rozpoznaní použitých knihoven, frameworků etc.

 

V čem nejsou automatické skennery dobré?

  1. analýza logiky aplikace
  2. detekce složitějších rizik
  3. Obcházení Turingových testů

 

 

Hodnocení jednotlivých skennerů

 

Název skenneru Přehlednost Licence Úspěšnost Platformy Použitelné reporty
Acunetix 9 Komerční 9 Win Ano
Nikto 5 Open Source 5 Cross platform  
Burp Suite Pro 6 Komerční 7 Cross platform Ano
Arachni 10 Open Source 10 Cross platform Ano
w3af 7 Open Source 8 Cross platform  
Vega 7 Open Source 6 Cross platform  
Wapiti 7 Open Source 6 Cross platform  
OWASP Zap 5 Open Source 7 Cross platform  

 

Podle tabulky výše vychází jednoznačně nejlepé projekt Arachni. Popíši Vám blíže to, jak funguje. Program je napsán v ruby a je možné ho spouštět přes přikazový řádek, webové rozhraní nebo REST API. Proces testování jsem rozdělil do 3 částí.

  1. Nastavování skennu:
  2. každé testování má vlastní název a popis (skenny jsou ukládány do DB)
  3. každé testování užívá tzn. Profil, kterému definujeme:
  4. název a popis
  5. parametry testování (počet vláken, priorita na síti, která určuje rychlost přenosu dat)
  6. oblasti testování (XSS, CSRF etc.)
  7. ostatní (jaké údaje sbírat, jaké HTTP hlavičky používat)
  8. Když spustíme sken dostáváme průběžně informace (čas, počet HTTP požadavků a zjištěné problémy)
  9. Na konci skenner generuje výstup v mnoha podobách (PDF, HTML, CSV, TXT etc)

Injekce

 

Úvod

 

Injektace je jedna z nejzávažnějších bezpečnostních chyb. Základní princip injekcí je možnost provedení operace, která může poškodit aplikaci. Toto je provedeno pomoci vsunutí nebezpečného kodu do příkazu. Takto můžeme například získat nadvládu nad databází nebo spustit nebezpečný kod.

 

SQL Injection (SQLi)

Představme si webový blog, který obsahuje několik různých článků. Každý článek ma unikatní itentifikátor ID. Na hlavní stránce je seznam všech článků s odkazy ve tvaru:

http://blog.cz/clanek.php?id=1'

kde parametr ID určuje článek. Aplikace poté spustí SQL dotaz na databázi ve tvaru:

SELECT nazev , obsah, autor FROM clanky WHERE ID = ‘1’

a místo ID doplní hodnotu parametru z URL. Nyní si představte, že do hodnoty parametru dosadíme apostrof, který ukončíme otevřené uvozovky v SQL příkazu a dosadíme za ním například tento příkaz:

UNION ALL SELECT nick, pass FROM admin

Konečný příkaz bude tedy vypadat takto:

SELECT nazev , obsah, autor FROM clanky WHERE ID = ‘’1’ UNION ALL SELECT nick, pass FROM admin

Úspěšně jsme injektovali SQL dotaz a budou nám neservírovány údaje o adminovi včetně hesla.

Problém tedy spočívá v apostrofu, který vyznačuje meze hodnoty paremetru v dotazu. Náchylnost aplikaci vůči SQLi testujeme tedy dosazením apostrofu do hodnot parametrů a sledujeme výstup.

Rozlišujeme 3 druhy SQLi:

  1. Injekce s jasným výstupem, kde jsme schopni vypsat data z DB (Error based)
  1. Injekce, která nevypisuje žádná data. Tím ale nebezpečí nezaniká. Útočník je schopen injektovat boolean dotaz do SQL dotazu a postupně získat, co potřebuje. Útočník rozeznává dva druhy výstupu: zobrazeno / nezobrazeno. Dotaz se tedy po injektaci apostrofu skládá ze dvou částí. První část vyzvedává data z DB o článku s určitým ID a druhá se ptá například na to jestli první znak adminova hesla je `a`. Pokud se stranka zobrazí a je skutečně první znak adminova hesla. Kdyby se nezobrazilo nic, znamenalo by to, že admin nemá první znak hesla `a` a útočník tedy přechází na písmeno `b`. Takto je schopen vydedukovat obsah celé DB.
  1. Injekce, u kterých uživatel nevidí hodnotu výstupu. Toto se děje například u registračních formulářů, kde se na základě vyplněných formulářů vloží data do tabulky hostů. Útočník přestože neví výstup příkazu, může například poslat příkaz na vložení nového admina stránky do DB nebo smazání celé DB.

Command Injection

Tento vektor útoku můžeme vidět u aplikací, které spuští systémové programy. Např: aplikace, které pingují určitou adresu nebo aplikace, které konvertují DOC do PDF etc. Problematiku si vysvětlíme u následujícího příkladu:

<?php

$output = system("host $_GET[?host']");

print($output);

?>

Do místa, kde vkládáme hodnotu parametru host, dosadíme středník, za něj “cat /etc/passwd” a sledujme, co se stane. Aplikace nejenom že vypíše výsledek příkazu host, ale také vypíše zásadní systémový soubor passwd.

 

Cross-site scripting (XSS)

 

Úvod

Jak už název napovídá, v XSS jde o spouštění scriptů na straně uživatele. Nejčastěji jde o Javascript, ale existují také Flashové vektory. Cílem útočníka, který využívá xss chybu, je spustit nežádaný script na straně prohlížeče. Tuto chybu lze rozdělit na dvě různé podskupiny: Stored a Reflected XSS.

Persistent XSS (stored)

Představme si aplikaci, která nabízí návštěvníkům zanechat komentář pod článkem. Komentář se po odeslání serveru uloží do DB a vypisuje se jeho obsah všem návštěvníkům webu. Útočník může do komentáře, který je špatně filtrován aplikací, vložit javascriptový script, který se později spustí všem návštěvníkům webu. Takto může například přečíst cookies a zjistit jejich SessionId, pomocí kterého je aplikace autentifikuje. Pro tento typ XSS je typické ukládání do DB (proto se také jmenuje Stored = uloženo). Ze všech XSS je toto jednoznačně nejnebezpečnější typ útoku.

Non-persistent XSS (reflected / DOM)

Pro tento vektor útoku je typická injektace klientských scriptů pomocí parametrů v URL a částí za #hashtagem. Tyto parametry se využívají například pro odkazování na určitou část stránky.  Klient přejde na stránku blog.cz/#nadpis1 a po načtení stránky se automaticky spustí skript, který si převezme parametr a najde DIV s id nadpis1 a provede operaci pro scroll na daný DIV. Útočník, ale může do hashtagu vložit takovou hodnotu, že místo scrollu na DIV, se například ukáže alert box. Druhý scénář, který patří určitě mezi ty nejčastější, je načítání hodnot do formulářů. Představme si vyhledávací aplikaci s URL:
hledej.cz/vyraz=“nove auto”.  Hodnota parametru vyraz se automaticky po načtení vloží do Inputu pro vyhledání. Pro tento příklad uvedu názornou ukázku:

PHP script na straně serveru:

Screenshot 2016-01-17 15.18.24.png

Útočník pošle oběti odkaz na URL ve tvaru:

http://hledej.cz/vyraz='><script>alert(‘xss’)</script><!—

 

Když toto oběť otevře, vypíše se input a dosadí se do něho hodnota z parametru vyraz:

Screenshot 2016-01-17 15.24.30.png

Následně se oběti spustí javascriptový kod a vyskočí alert box s nápisem XSS. Nyní si představte scénář, kde by útočník chtěl získat přístup do administrace a nějakým způsobem by admina přinutil kliknout na odkaz, který by ho přesměroval do administrace a do přihlašovacího formuláře by se načetla data z URL a krom toho by obět nic netušícně odeslala své Cookies na server útočníka. Ukázka takového kodu:

Screenshot 2016-01-17 15.35.28.png

 

Obrana

Prevence XSS je jednoduchá. Všechny proměnné, které by se mohly vypsat do browseru, je nutno filtrovat a to pomocí funkce filter_var v PHP. Tato funkce převede následující znaky na neškodné HTML entity:

Screenshot 2016-01-17 15.41.30.png

 

Nebezpečné konfigurace

Úvod

    V této kapitole se budeme zaobírat konfiguracemi webových serverů, které mohou znamenat riziko. Ukážeme si, jak tyto nedostatky vyhledat a řekneme si, jaký by mohly mít dopad.

Identifikace

   Pro úspěšný průnik do serveru bude útočník muset znát jeho verzi a operační systém, na kterém webový server běží. K tomuto použijeme techniku zvanou “banner grabbing” a pomocí jednoduchého HTTP pažadavku si vyžádáme odpověď od serveru, který nám v odpovědi pošle i HTTP hlavičku server. Na toto se skvěle hodí nástroj netcat, který je často přezdíván “švýcarský nožík TCP/UDP”. Pomocí tohoto příkazu otevřeme spojení se serverem na dané adrese a portu:

nc 127.0.0.1 80

Nyní máme spojení se serverem a odešleme HTTP požadavek:

GET / HTTP/1.0

Klávesou enter odešleme a vyčkáme na odpověď:

HTTP/1.1 200 OK

Date: Fri, 01 Apr 2016 10:38:50 GMT

Server: Apache/2.4.16 (Unix)

Content-Location: index.html.en

Vary: negotiate

TCN: choice

Last-Modified: Mon, 11 Jun 2007 18:53:14 GMT

ETag: "2d-432a5e4a73a80"

Accept-Ranges: bytes

Content-Length: 45

Connection: close

Content-Type: text/html

 

Standardně ukončíme (ctrl+c). Z odpovědi vyplývá, že náš server běží na Apachi verze 2.4.16 a operační systém je z Unixové rediny. 

Známé chyby webového serveru

    Jako první zkontrolujeme, jestli na server dané verze jsou známé exploity (zneužitelné chyby). K tomu využíváme online databáze chyb:

http://exploit-db.com

http://cvedetails.com

Případně využijeme i Google. V našem případě bych vyhledával fráze: 

Apache 2.4.16 exploit

Apache 2.4.16 vulnerabilities 

 

    V případě, že najdeme chyby v naší verzi webového serveru, je nutno nahrát nejnovější záplaty.

Vyhledávání souborů s citlivými informacemi

    Musíme se ujistit, že server nezobrazuje citlivé udáje jako jsou hesla, jména, systémove informace atd. K tomuto využíváme scriptů, které automaticky prohledají všechny soubory, na které jsou na webu odkazy a jejich obsah porovnává se seznamem regulárních výrazu pro vyhledávání těchto citlivých dat. Seznamy výrazů je možné dohledat na internetu, ale postupem času si každý penetrační tester tento seznam vytvoří sám. Já pro tento účel používám nástroj Wfuzz napsaný v pythonu. Script umí rekurzivně prohledávát obsah webu a vyhodnocovat odpověď. Zde jsou odkazy na nástroj Wfuzz a databáze listů pro vyhledávání citlivých informací.

 

Vyhledávání souborů a adresářů, na které není přímý odkaz

    Většina stránek také obsahuje soubory, na které neexistuje přímý odkaz. Takové soubory musíme hledát metodou pokus omyl. Pro toto se využívají seznamy souborů, které často bývají součástí obsahu webu. Tyto seznamy můžete stáhnout například z odkazů výše. Testování se provádí pomocí scriptů. Jak už jsem uváděl, já používám nástroj Wfuzz. Princip tohoto procesu je velmi jednoduchý:

  1. Script odešle požadavek na daný soubor na serveru
  2. Vyhodnotí hlavičku odpovědi, pokud server vrátí kód 404, soubor nebyl nalezen, pokud ale vrátí jiný kód, soubor pravděpodobně existuje.

Příklad použití Wfuzz:

wfuzz.py -c -Z -z file,soubory.txt --hc 404 -o html http://www.mysite.com/FUZZ > results.html

 

 

Parametry scriptu:

  • c pro barevný výstup
  • Z pro ignorování chyb připojení - pro větší stabilitu testu
  • z určuje typ a cestu k listu, z kterého, v našem případě, čerpáme seznamy potencionálních souborů
  • hc nechceme zobrazovat odpovědi serveru, které vrací kod Not found - 404
  • o typ výstupu bude ve formátu HTML

> result.html výstup přesměruje do souboru result.html

Ukázka výstupu: 

Definici typu výstupu je také možno vynechat, poté se použije výchozí výstup, což je prostě formátovaný text:

 

Autentifikace a šifrování

 

Úvod

Proces autentifikace je klíčový pro správný chod každé aplikace, která nějakým způsobem ověřuje identitu uživatele. Když je logika ověřování prolomena, útočník je schopný využít identitu někoho jiného.

Útoky na autentifikaci

  1. Přenášení dat přes nezašifrované spojení, může znamenat únik přihlašovacích údajů, proto je nutné využít HTTPS s validním certifikátem a nastavit striktní vyžadování šifrování (HSTS)
  2. Politika hesel je na první pohled samozřejmností, ale bohužel tak často není. Snaha uhodnout heslo je nejběžnější způsob útoku a proto je nutné vybrat takové heslo, které není možné dedukovat a které obstojí proti slovníkovým útokům. Časté je také ponechání výchozích hesel, což je také velký problém.
  3. Proti procesu automatického uhádnutí hesla tzn. brute-force je potřeba implementovat ochranu. Tato ochrana vyhodnocuje unikátnost uživatele na základě spousty faktorů (např. IP, OS, HTTP-Agent atd.). Existují také cloudové služby, které toto zajištují (např. CloudFlare).
  4. Funkce, které umožňují obnovit heslo, jsou často kritickým bodem a je nutné je důkladně promyslet. Toto obsahuje i spravné zvolení bezpečnostních otázek.

 

Phishing

 

Úvod

Phishing je technika, kterou se útočník snaží dostat z oběti citlivé údaje pomocí manipulace. Cílem útoku je přinucení oběti provést akci, která je podvrhnuta útočníkem. Akcí může být odesílání formuláře, ale například i nakoupení položek ne e-shopu. Tato technika bývá často kombinováná s XSS, kdy útočník oběť přesměruje na falešnou stránku.

Spear Phishing

Specifický druh této techniky, která je založená na personizaci útoku. Útočník využívá data o oběti (může být i celá firma) a vytvoří důvěryhodný útok, který nebude pro oběť podezřelý.

Detekce

Pro odhalení tohoto typu útoku se používá hlavně ověřování důvěrzhodnosti pomocí vytvoření databazí serverů, kterým je možné důvěrovat. Tuto funkci přináší antiviry nebo doplňky do prohlížečů (např. Web of Trust).

Prevence

Dalším způsobem, jak ověřit pravost stránky, je kontrola SSL certifikátu. Aby vůbec nedošlo k navštívení podvodné stránky, je nutné vnímat, odkud kam se na internetu pohybujete. Vždy nahlížejte na cílovou adresu odkazu, před tím než na něj kliknete. K návštěvě zvláště citlivých serverů (např. internetové bankovnictví, firemní administrace) zadávejte adresu vždy manuálně do prohlížeče. Predejdete tak návštěvě podvodného webu. Když už je nutné přejít na stránku pomocí odkazu, důsledně si prohlídněte, z jakých domén a subdomén se adresa skládá. Postup popíši na příkladu:

Podvodná adresa je vytvořena často subdoménou, kterou v tomto případě tvoří slovo paypal a hlavní doménou (com-renew.net), která je odlišná od pravé domény sužby. Vždy je nutné zkontrolovat hlavní doménu.

Screenshot 2016-03-02 13.33.15-filtered.png

Dalším způsobem jak ověřit pravost stránky je kontrola SSL certifikátu. Váš prohlížeč je natolik inteligentní, že dokáže rozeznat certifikáty, které byly podepsané veřejně uznávanou autoritou od certifikátů, které nejsou podepsané jednou z věrohodných firem. Když chce vlastník webu bezpečné přihlašování do aplikace, musí si nechat certifikovat svou aplikaci pomocí certifikátu, který mu vydá certifikační autorita. Vlastník je nucen autoritě předat základní info o stránce, autorita dále podepíše certifikát pravosti a stránka se stane důvěryhodnou pro prohlížeče (tzn. trusted). Přítomnost certifikátu zajišťuje nejen šifrovaný přenost dat pomocí HTTPS, ale také zvýší pocit bezpečí zákazníků a navýší ochranu proti phishingu. Celý tento proces popíši v ktrátkém příkladu:

Útočník pošle oběti podvodný email s odkazem (paypal.com-renew.net) na falešnou přihlašovací stránku paypal. Oběť, která je znalá pokročilých principů bezpečného chování na internetu, odkaz ani neotevře, protože vidí, že doména neodpovídá standardní doméně používané paypalem.Předpokládejme, že oběť si toto neuvědomí a odkaz otevře. Nyní ale zpozorní, protože vidí, že stránka není potvrzená HTTPS certifikátem (není trusted) a pro jistotu otevře paypal manuálně přes paypal.com. Útok tedy nebyl úspěšný a útočník jde o emailovou adresu dál.

To, jestli je stránka trusted nebo ne, se pozná na první pohled pomocí zavřeného zámku v poli pro zadávání adresy. Níže najdete fotografie tohoto znaku:

Safari

Screenshot 2016-03-02 13.33.27.png

Chrome

pasted-image.jpg

Firefox

Screenshot 2016-03-02 13.56.10.png

CSRF

Úvod

Tento útok spočívá v tom, že útočník donutí oběť provést akci, kterou by normálně neprováděla. Předpokládejme, že oběť je zaregistrována na nějaké webové aplikaci jako administrátor.Útočník ví, že webová aplikace je náchylná na CSRF a že je tedy možné donutit uživatele změnit heslo na “heslo”. Toto je umožněno špatným řešením odesílaní formuláře pro změnu hesla. Problém je v tom, že útočník je schopen donutit oběť odeslat požadavek na změnu hesla tak, že například vytvoří odkaz na GET požadavek a přiměje oběť, aby na něj klikla. Tento odkaz může vypadat například takto:

Screenshot 2016-03-14 11.55.59.png

Obrana

Proti CSRF existuje jednoduchá obrana. Stačí, když přidáte do každého formuláře, který se odesílá a zpracovává na serveru, speciální skrytý token, který se bude generovat náhodně pro každého uživatele zvlášť. Při zpracování dat server vyhodnotí, zda-li data pochází od uživatele, kterému byl formulář poslán. Technicky se toto řeší přidáním hidden pole do formuláře. Jiné řešení typu cookies hodnot, POST nebo GET parametru jsou neúčinné, díky jejich podvrhnutelnosti. Dále je možné toto řešit Turringovým testem při odesílání formuláře na straně klienta.