63 - Bezpečnost webových aplikací, typické útoky.
12. června 2017
19:19
Další útoky: [link]
Extra informace 
Zpřístupnění dat 
vykonání libovolného příkazu 
Dělení útoků:
Normal blind jsou zaměřeny na aplikace, které nevypisují chybová hlášení databázového nebo webového serveru. Místo chybového výpisu poskytnou obecní stránku s informací, že nastala chyba. Jelikož aplikace nevrací žádné údaje, je třeba použít jiný způsob kontroly odezvy. Za tímto účelem se používá měření časové odezvy aplikace
Totally blind: jsou útoky na aplikace, které neposkytují žádný výstup. Vyskytují se zřídka, například různé logovací funkce - výstup se neposílá uživateli
Zranitelnosti - útoky na webové aplikace:
Cross site scripting (37%)
SQL Injection (16%)
Path Disclosure (5%)
Denial of Service (5%)
Code Execution (4%)
Memory Corruption (4%)
Cross Site Request Forgery (4%)
Clickjacking
SQL Injection
Téměř všechny webové aplikace používají databázi pro ukládání různých druhů informací včetně pověření uživatele 
Webová aplikaci, která kromě statického HTML kódu obsahuje i dynamické prvky, například skripty v jazyce PHP. Taková dynamická webová aplikace často používá i databázi, pomocí které udržuje perzistenci dat (ukládá je). Nejběžnějším typem databáze, kterou webové aplikace používají, jsou relační databáze, které podporují jazyk SQL. S touto databází komunikuje skriptovací jazyk, v tomto případě PHP, pomocí dotazů. Dotaz je řetězec v jazyce SQL, který obsahuje příkazy a data pro databázi. Pomocí těchto dotazů zadáváme databázi příkazy, které chceme provést. Nejčastěji jsou to příkazy k získání dat nebo jejich uložení. Jedním z druhů dat, které chceme kombinací skriptovacího jazyka a databáze zpracovat, jsou UŽIVATELSKÁ vstupy. Pokud v takové aplikaci neprojdou vstupy uživatele žádnou kontrolou a jednoduše se prodají databázi vložením do dotazu, nastává problém. Uživateli je totiž umožněno zadávat vstupy, které budou zpracovány přímo databází. 
Jde tedy o vložení kódu do vstupu aplikace tak, aby byl zpracován.
Lze použít ke čtení, aktualizaci, přidávání a odstraňování informací v databázi 
Aplikace jsou často odpovědné za vytváření dotazů SQL - což by mohlo vést ke zranitelnosti umožňující útočníkovi číst a upravovat všechna uložená data postižených databází. 
Všechny programovací jazyky a všechny SQL databáze jsou potenciálně zranitelné 
Cross site scripting (XSS)
Uživatele je zmanipulován, aby spustil škodlivý kód na validní stránce
Typy
Reflektovaný XSS
Označuje se jako non-persistent nebo reflected. Je postaven na úpravě části URL která se interpretuje do stránky jako její součást, například jako nadpis. Pokud do URL adresy přidáme svůj kód který není před interpretací upraven, tak se stránka v prohlížeči zachová, jako by námi vložený kód byl její součástí.
Uložený XSS
Data, která pošle na server jeden uživatel jsou bez kontroly uložena do DB a zobrazována dalším uživatelům
Uživatel může uložit škodlivý kód, který pak bude zobrazen dalším uživatelům
Možnosti obrany
Validace vstupů (je potřeba validovat všechny vstupy od uživatele)
Validace výstupů. Sanitizace HTML v odpovědích...). Při vkládání dat od uživatele do HTML stránky odfiltrovat „nebezpečné“ znaky z uživatelského vstupu resp. je převést na příslušné HTML entity ( < za &lt;, > za &gt; atd.).
Eliminace nebezpečných bodů (bodů, kde je teoreteicky možné vložit kód. Lepší je program implementovat bez toho, aby se vstup od uživatele používal ve skriptech
Na straně uživatele je jedinou obranou vypnutí JS
Cross site request forgery (XSFR)
Útok, kde škodlivá stránka manipuluje návštěvníky jiné stránky, aby provedl určitou akci
Obrana:
V administrační části internetových aplikací, pro akce, které mažou určité záznamy nebo je jiným způsobem mění, se doporučuje zásadně používat HTTP metodu POST. (To útok CSRF znesnadňuje, ale ještě zcela nevylučuje.)
Používat autorizační token – tedy náhodně vygenerovaný řetězec pro tuto akci, platící jen pro aktuálního uživatele, ideálně pokaždé jiný (pro každý formulář, který nabízí k vyplnění). 
Clickjacking
Je-li implementována ochrana před XSFR
uživatel sám klikne na prvek nebo vyplní a odešle formulář, bez toho, aby věděl, co skutečně dělá
Útok založen na možnosti načíst web do rámu 
Průhlednost rámu 
Překrytí nechtěných prvků 
Vkládání údajů do aplikace, nebo krádež dat z aplikace
Obrana:
HTTP Response hlavička X-Frame-Options
Content Security Policy (CSP) 
Enumerace & bypass autorizace
Procházení stránek změnou id v požadavku
Možnost získání kompletních databází 
Krádež session 
Nebezpečí
útočník ukradne identitu oprávněného uživatele 
Příčiny
nezabezpečené předávání session ID (předávání přes URL - únik přes referer, předávání přes nezabezpečené cookies - únik přes XSS) 
session nejsou kontrolovány na straně serveru 
Session ID je generována špatným algoritmem
Řešení
hlídání session na straně serveru (timestamp, IP) 
změna session ID při přihlášení 
Obrana před útoky
Cookies
Zabezpečení citlivých cookies přenášených přes internet: 
Je-li bezpečnostní příznak nastaven na cookie, pak prohlížeč nebude předkládat cookie všechny požadavky, které používají nešifrované připojení HTTP, čímž zabraňují přičemž cookie by bylo triviálně zachyceno sítí monitorující útočníky provoz. 
HttpOnly - Tento atribut se používá k zabránění útokům, jako je cross-site scripting, protože neumožňuje, aby byl soubor cookie zpřístupněn přes skript klienta, například JavaScript. Všimněte si, že ne všechny prohlížeče tuto funkci podporují
Zabezpečení přes HTTP
HTTP přes zabezpečený kanál 
HTTP používá základní nešifrovaný transportní mechanismus TCP, který může být zachycen útočníkem. 
HTTPS je stejný protokol aplikační vrstvy jako protokol HTTP, ale tunelován přes bezpečný transportní mechanismus SSL/TLS 
Přidání soukromí a integrity ke komunikaci. 
Transparentní k aplikaci. 
Komunikace je založena na jiném portu (obvykle 443 pro webové aplikace) se liší od obyčejného protokolu HTTP. 
SSL - Secure Sockets Layer 
Šifrovací protokol poskytující komunikační zabezpečení 
Útok nazvaný BEAST (zkratka Browser Exploit Against SSL/TLS) postihuje TLS 1.0, SSL 3.0 a všechny předchozí verze. Novější verze TLS 1.1 a 1.2 jsou proti němu odolné, ale zase nejsou téměř vůbec rozšířené v prohlížečích ani web serverech.
Staví na dlouho známé slabině TLS, kterou ale doposud nikdo nedokázal reálně využít a mnoho odborníků se domnívalo, že to vůbec není možné. Potíž je v tom, že jednotlivé bloky komunikace jsou šifrovány pomocí AES, která mění klíče podle obsahu předchozích bloků. BEAST se snaží tento proces zmanipulovat tak, aby byly jednotlivé bloky šifrovány stejnými klíči. U obsahu o nízké entropii (a přibližně známém obsahu) je pak možné spolehlivě odhadnout původní data.
BEAST se skládá ze dvou kroků a využívá klasického útoku man-in-the-middle, při kterém sleduje komunikaci klienta se servery. Jakmile dojde na spojení se zajímavým serverem, útočník podstrčí klientovi vlastní javascriptový kód například v přidaném iframe nebo přímým vložením do stahované stránky. Tento skript se postará o manipulaci šifrovacího algoritmu, který začne generovat slabě šifrované bloky.
Poté nastoupí klasický síťový sniffer (analyzátor packetů), který komunikaci zachytí a dešifruje. Dešifrování ale neprobíhá v reálném čase, ale prolomení jednoho bajtu ze zachycené cookie trvá přibližně dvě sekundy. Pro získání kompletního identifikátoru sezení je tak potřeba řádově deset minut.
TLS - Zabezpečení přenosové vrstvy 
Šifrovací protokol založený na dřívější specifikaci SSL 
standard IETF (RFC 5246) 
Autentizace HTTP
Jednoduchý mechanismus autentizace, který odešle pověření uživatele přímo do adresáře na server jako řetězec zakódovaný Base64 v hlavičce požadavku s každou zprávou. 
NTLM 
Mechanismus reakce na výzvy, který používá vlastní ochranu NT LAN Manager bezpečnostní protokol. 
NTLMv1 - nepodporuje nedávné kryptografické funkce jako AES nebo SHA-*, používá CRC pro integritu a RC4 pro šifrování. Zastaralé! 
NTLMv2 - používá HMAC-MD5 hash pověření uživatele, silný jako síla hesla uživatele. 
Digest 
 mechanismus reakce výzvy, který používá kontrolní součet MD5 nonce s uživatelským pověřením. 
Opatření proti SQL injection
Všechny uživatelské vstupy by měly být řádně ošetřeny
Whitelist povolených znaků - e-mail:. ^ [A-Z0-9 ._% + -] + @ [A-Z0-9 .-] + \ [AZ] {2,4} $ 
Použití firewallů webových aplikací 
Otevřený modul ModSecurity 
Omezit oprávnění databáze 
Vytvořit více databázových účtů s minimální úrovní oprávnění 
Vyvarujte se vytváření dotazů SQL s uživatelskými vstupy 
Připravené příkazy nebo uložené procedury 
Vyhněte se podrobným chybovým hlášením 
Nepoužívejte jednoduché únikové funkce 
PHP addslashes() nebo funkce jako str_replace ("'", ""). Ty jsou slabé a byly úspěšně zneužity útočníky. 
Použijte objektově-relační mapování 
Přezkoumat kód, zpevnit zásady zabezpečení, reagovat na protokolovaný protokol SQL 
Další útoky
Google hacking
Hledání nezabezpečených administrátorských/řídídích stránek přes google
Chybná interpretace URL 
Nebezpečí
přes speciálně zadanou URL je možné zaútočit na server 
Příčiny
Webový server nesprávně parsuje URL adresu (podstrčení bílých znaků, unicode znaky, ...) 
Chybné mapování zdrojů v konfiguraci 
Řešení
záplaty od výrobce serveru 
kontrola konfiguračních souborů 
Procházení adresářů 
Nebezpečí
útočník získá seznam všech souborů, které jsou na serveru 
Příčiny
chybné nastavení serveru 
chyba serveru 
Řešení
správné nastavení (zakázat DirectoryIndex) 
záplata od výrobce serveru 
Získání „non-web“ souborů 
Nebezpečí
útočník získá soubory, ke kterým by neměl mít přístup 
Příčiny
názvy souborů, které lze uhodnout 
přítomnost souborů, které by neměl být věřejně přístupné 
Řešení
zbavit se souborů 
zakázat zpracování souborů daných typů (resource mapping) 
Únik zdrojových kódů 
Nebezpečí
Získání zdrojových souborů aplikace a následná analýza na bezpečnostní chyby 
Příčiny
chybná konfigurace 
chyby aplikace 
chyby serveru 
Řešení
oprava aplikace 
záplaty od výrobce serveru 
Útoky přes vstupní data 
Nebezpečí
Útok na aplikaci podstrčením neočekávaných dat 
Příčiny
nejčastější typ útoku 
kontrola dat pouze na straně klienta 
předávání dat přes skrytá pole formulářů bez jejich kontroly 
Řešení 
Vstupy musí být kontrolované – rozsah hodnot, datové typy, metaznaky 
nevěřit ničemu co přijde od klienta 
před použitím vstupu jej vždy ošetřit na meta-znaky 
Buffer overflow 
Nebezpečí
útočník ovlivní fungování serveru (DoS, pád aplikace, vzdálené sputění příkazů (shellcode), přepsání hodnot) 
Příčiny
slabá kontrola vstupu 
chyby v aplikaci 
chyby serveru 
Řešení
Statická analýza kódu aplikace 
robustní knihovní funkce 
jiné technologie např. .Net, Java 
Ochranné mechanismy např. StackShield 
Notes
65. Bezpečnost webových aplikací, typické útoky.
Kdo me primarne zkousel: Tady si bohužel nejsem jist.
Co jsem k tomu rekl(a)/na co se ptali/co mne vytkli: Popsal jsem SQL injection, stored XSS a reflected XSS. Ptali se mě, k čemu se dá XSS zneužít, tak jsem zmínil získání cookies. To jim nestačilo, ale dostali ze mě potom, že v cookies může být session ID, a o to asi šlo. Pak se ještě ptali na možnost zabezpečení, tak jsem zmínil escaping, uložené dotazy a parametrické SQL dotazy. Pak vypršel čas.
From <[link]> 