PDF Verze - Kybernetická bezpečnost

WEB_SECURITY
David Sýkora
Webové aplikace tvoří v
dnešní době bránu do
kyber prostoru, který se
stává součastí všedního
života téměř všech lidí a
právě proto je potřeba
se zamýšlet nad
problematikou
bezpečnosti této
k o m u n i k a c e . Te n t o
dokument by měl
pomoci vyvojařům
pochopit základní
aspekty bezpečnosti a
naučit je jak otestovat jejich
kod.
Phishing
(123) 456-7890
Well known exploits
(123) 456-7890
CSRF
(123) 456-7890
Session hijacking
(123) 456-7890
Cryptography issues
(123) 456-7890
Bad configuration
(123) 456-7890
Data leakage
(123) 456-7890
XSS
(123) 456-7890
Broken Auth
(123) 456-7890
Injection
(123) 456-7890
Úvod do penetračního testování .........................4
Co je penetrační testování? ..............................................................................................4
Proč bychom měli aplikace testovat? ...............................................................................4
Etika ..................................................................................................................................4
Report ...............................................................................................................................4
Typy penetračních testů ...................................................................................................5
Metodiky testování ..............................................6
Co to je metodika? ............................................................................................................6
OSSTMM...........................................................................................................................6
OWASP..............................................................................................................................7
ISSAF ................................................................................................................................7
RSA ...................................................................................................................................7
Souhrn metodik ................................................................................................................ 8
Automatické nástroje ..........................................9
Úvod ..................................................................................................................................9
V čem jsou automatické skennery dobré? ........................................................................9
V čem nejsou automatické skennery dobré? ....................................................................9
Hodnocení jednotlivých skennerů..................................................................................10
Injekce ................................................................11
Úvod .................................................................................................................................11
SQL Injection (SQLi) ....................................................................................................... 11
Command Injection ........................................................................................................12
Cross-site scripting (XSS) ..................................13
Úvod ................................................................................................................................13
Persistent XSS (stored) ...................................................................................................13
Non-persistent XSS (reflected / DOM) ..........................................................................13
Obrana .............................................................................................................................14
Autentifikace a šifrování ....................................15
Úvod ................................................................................................................................15
Útoky na autentifikaci .....................................................................................................15
Phishing..............................................................15
Úvod ................................................................................................................................15
Spear Phishing ................................................................................................................15
Detekce ............................................................................................................................16
Prevence ..........................................................................................................................16
Ú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 budem 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 čistě 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 pravěpodobně
předá naší zprávu programatorům, kteří pomoci naší zpravý 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 kodu, nezná funkcionalitu jednotlivých kompenent
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 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, pokuď 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 kodu. Tester prochází aplikaci soubor po souboru a hledá
místa, které by se mohly stát vektorem útoku. Tester zároveň oveř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 zapory. 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í standart penetračního testování. Kategorizuje bezpečnosti
do počitatelných kompenent.
Rozděluje testy do šesti skupin:
*
Metodika se zabývá bezpečností obecně a jijí 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ě snadží
vylepšit bezpečnost na internetu. Dle mého názoru je jednoznačne 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 F figuruje jako vývojář a vyvíjí nástroje, které
približují internet k jijich 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 jí možné vložit do jednotilivých fází SDLC.
http://owasp.org
ISSAF
Information Systems Security Assessment Framework
Metodika strukturovaná do freamworku. Testování rozděluji do 9 kroků. Zaměřuje
se na webové aplikace.
RSA
Metodika založená na urovni 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 testotovat 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é?
• mapováním struktury aplikace
• vyhledávání vstupů
• sběr a analýza dat (emaily, citlivé údaje)
• detekování základních bezpečnostních rizik (XSS, CSRF, RFI,LFI etc.)
• rozpoznaní použitých knihoven, freamworků etc.
V čem nejsou automatické skennery dobré?
• analýza logiky aplikace
• detekce složitějších rizik
• Obcházení Turingových testů
Hodnocení jednotlivých skennerů
Název
skenneru
Přehledno
st
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:
1. každé testování má vlastní název a popis (skenny jsou ukládány do DB)
2. každé testování užívá tzn. Profil, kterému definujeme:
1. název a popis
2. parametry testování (počet vláken, priorita na síti, která určuje rychlost přenosu
dat)
3. oblasti testování (XSS, CSRF etc.)
4. ostatní (jaké údaje sbírat, jaké HTTP hlavičky používat)
2. Když spustíme sken dostáváme průběžně informace (čas, počet HTTP požadavků a
zjištěné problémy)
3. 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 odkazama 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. Inejkce s jasným výstupem, kde jsme schopni vypsat data z DB (Error based)
2. Injekce, která vevypisuje žádné data. Tím ale nebezpečí nezaniká. Utočník je schopen
inejktovat boolean dotaz do SQL dotazu a postupne 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.
3. 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ářu vloží data do tabulky hostů. Útočník
přestože neví výstup příkazu může například poslad 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 a 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á, 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á inejktace klientských scriptů pomocí patametrů 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 stranáku blog.cz/#nadpis1 a po načtění 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ávácí aplikaci s URL: hledej.cz/vyraz=“nove auto”. Hodnota parametru vyraz se automaticky po nactení vlozi
do Inputu pro vyhledání. Pro tento příklad uvedu názornou ukázku:
PHP script na strane serveru:
Útočník pošle oběti odkaz na URL ve tvaru:
http://hledej.cz/vyraz='><script>alert(‘xss’)</script><!—
Když toto obět otevře vypiše se input a dosadi se do něho hodnota z parametru vyraz:
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:
Obrana
Prevence XSS je jednoduchá. Všechny proměné, které by se mohli vypsat do browseru
je nutdno filtrovat a to pomocí funkce filter_var v PHP. Tato funkce převede následující
znaky na neškodné HTML entity:
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, utočník je
schopný využít identitu někoho jiného.
Útoky na autentifikaci
• 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)
• Politika hesel je na první pohled samozřejmností, ale bohužel tak často není. Snaha
uhodnout heslo je nejbeženě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.
• Proti procesu automatického uhádnutí hesla tzn. brute-force je potřeba implementovat
ochranu. Tato ochrana vyhodnocuje unikatnost uživatele na základě spousta faktorů (např.
IP, OS, HTTP-Agent atd.). Existují také cloudové služby, které toto zajištují (např.
CloudFlare).
• 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 teté techniky, která je založená na personizaci útoku. Útočník nesbírá
data o oběti (může být i celá firma) a vytvoří důvěryhodný útok, který nebude oběd
podezírat.
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
Aby vůbec nedošlo k navštívení podvodné stránky je nutné vnímát 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.
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 a autorita dalé podepíše certifikát pravosti a stránka se stane
důvěryhodnou pro rohlíž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á standartní 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 v stránka není potvrzená HTTPS certifikátem (není trusted) a pro
jistotu otevře paypal manuálně přes paypal.com. Utok tedy nebyl uspěš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
Chrome
Firefox