Webové aplikace, bezpečnost webových aplikací. Rozdíly oproti webové stránce: interaktivní řádově vyšší počet HTTP požadavků práce s datovým skladem problémy.

Prezentace na téma: "Webové aplikace, bezpečnost webových aplikací. Rozdíly oproti webové stránce: interaktivní řádově vyšší počet HTTP požadavků práce s datovým skladem problémy."— Transkript prezentace:

1 Webové aplikace, bezpečnost webových aplikací

2 Rozdíly oproti webové stránce: interaktivní řádově vyšší počet HTTP požadavků práce s datovým skladem problémy se souběhem více uživatelů Webová aplikace se skládá z webových stránek Webová aplikace je serverová aplikace zahltit server není problém zahltit server znamená odříznutí všech uživatelů

3 Rozdíly oproti lokální (nesíťové) aplikaci vzdálený přístup problémy se souběhem více uživatelů potíže s uchováváním stavu závislost na webových prohlížečích vysoká dostupnost levnější údržba aplikace

4 Nastavení dat v HTTP hlavičkách: nastavení ukládání do cache (mezipaměti) Nastavení informací pro vyhledávače a prohlížeče: klíčová slova (keywords) autor (author) popis (description) Při nastavování těchto metadat je nutné brát v úvahu, že vyhledávače se brání ovlivňování výsledků. pro webové aplikace není příliš významné

5

6

7 rychlost závisí na neovlivnitelných okolnostech fyzikální omezení přenosu compuware.com mendelu.cz

8 Cache = mezipaměť Při prvním požadavku na webovou stránku je nutné načíst všechny externí soubory. obrázky, styly, skripty (klientské) Při dalším požadavku na stránku není nutné stahovat soubory znovu – pravděpodobně se nezměnily. Cache je dočasná paměť pro uložení webových stránek. dramatické zvýšení rychlosti načítání pevný disk nebo RAM Existuje také sdílená cache – velké organizace, někteří poskytovatelé internetu

9 Systém pro definovaní doby uchovávání stránky (lifetime, time-to-live, ttl) v cache prohlížeče. Příklad – první načtení stránky: 55 požadavků (435 954 B z toho 18872 B stránka) Druhý požadavek na stránku: 9 požadavků (2175 B) Obnovení stránky: 54 požadavků http://www.w3.org/Protocols/rfc2616/rfc2616- sec14.html http://www.w3.org/Protocols/rfc2616/rfc2616- sec14.html

10 Hlavička Cache-control – příklady: Cache-control: public, max-age=259200 Cache-control: private, max-age=3600, must- revalidate Cache-control: private, no-cache, no-store, must- revalidate Koncept 1 soukromý vs. veřejný obsah (public × private × no- cache × no-store) rozhoduje zda uložit nebo neuložit

11 Koncept 2 – vypršení (expiration) doba platnosti [s]: max-age=3600 povinné ověření: must-revalidate Koncept 3 – ověření platnosti Pokud klient požaduje zaručeně čerstvou stránku může odeslat hlavičku (CTRL + F5): Pragma: no-cache Server musí buď odpovědět platnou stránkou nebo klienta přesvědčit, že jeho verze je platná (HTTP status 304).

12 Podle data poslední změny Server může odeslat hlavičku udávající poslední změnu souboru: Last-Modified: Wed, 13 Oct 2004 09:43:02 GMT Klient může ověřit zda došlo ke změně posláním hlavičky: If-Modified-Since: Wed, 13 Oct 2004 09:43:02 GMT Podle obsahu Server může odeslat kód, který se změní při změně obsahu: ETag: "3fe48-527f-52237c0" Klient může ověřit zda došlo ke změně posláním hlavičky: If-None-Match: "38cac-1f34-7333bcc0"

13 Minimalizace objemu přenášených dat mezi serverem a klientem Ověření platnosti = přenos přibližně 500B Pro statický obsah je zajištěno automaticky (posílá se Last- modified) Pro dynamický obsah nutno řešit při generování stránky (ETag) zejména pro skripty, které vracejí obrázky a velké soubory U dynamicky generovaných stránek je vhodné zajistit, aby se generovaly jen pokud je to nutné. snížení zátěže serveru http://www.telerik.com/fiddler

14 http://www.xkcd.com/

15 přihlášení, stav formuláře, aktuální stránka… protokol HTTP je nestavový Z pohledu serveru není mezi jednotlivými požadavky klientů žádná spojitost. Jedna akce uživatele odpovídá mnoha HTTP požadavkům. Požadavky jednotlivých klientů se na serveru prolínají. Udržování stavu webové aplikace je možné několika způsoby. všechny jsou špatné a některé ještě horší…

16 POST https://example.com/loginProcess HTTP/1.1 Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x- shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0;.NET CLR 2.0.50727;.NET CLR 3.0.4506.2152;.NET CLR 3.5.30729;.NET CLR 1.1.4322) Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate Host: example.com Content-Length: 131 Connection: Keep-Alive Cache-Control: no-cache Accept-Language: cs loggedURL=http%3A%2F%2Fexample.com%2Fticket&serviceId=email&forceSSL= 0&username=mrkvicka&domain=example.com&password=cibulka&js=1

17 Map of the internet (2006) http://xkcd.com/195/ o většina PC nemá statickou IP adresu o většinu PC používá více jak jeden uživatel o na většině PC je spuštěn více jak jeden program

18 GET je základní HTTP požadavek Udržování stavu metodou GET znamená vkládání parametrů do URL. Není nijak zabezpečeno, adresu je možné podstrčit Pouze malý objem textových dat (2 048B), bez speciálních znaků (funkce urlencode() ) K předávání dochází pouze při kliknutí na odkaz nebo odeslání formuláře. Uživatel může libovolně měnit http://www.google.cz/search?q=test&hl=cs&start=10&sa= N

19 POST je jiný způsob odeslání HTTP požadavku, při kterém klient odesílá (post) serveru data. POST požadavek vzniká pouze při odeslání formuláře (method='post') nebo JavaScriptem. Není nijak zabezpečeno. Data jsou ve zdrojovém kódu HTML stránky. Pouze textová data bez speciálních znaků (urlencode()) Je mírně odolnější proti podstrčení a proti změně ze strany uživatele. Není univerzální, musí se explicitně zopakovat při každém požadavku.

20 Data pro udržení stavu se ukládají v prohlížeči nespolehlivé uživatel může libovolně mazat a měnit nebezpečné není šifrováno přístupné komukoliv Nastavuje se vypršení cookie souboru po zavření prohlížeče (dočasný cookie v RAM) doba platnosti (tj. platné i po zavření prohlížeče, trvalý cookie na HDD) Do cookie se dají ukládat jen textová data (max. 4096B na doménu), přenáší se při každém požadavku automaticky.

21 Internet Explorer %USERPROFILE%\AppData\Local\Microsoft\Windows\INetCookies Firefox %USERPROFILE%\AppData\Roaming\Mozilla\Firefox\ Profiles\2wm3nnty.default\cookies.sqlite Chrome %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Cookies Příklad obsahu (www.google.cz): PREF ID=e0e8437d79da2a4e:LD=en:NR=30:TM=1196797760:LM=1196797793:S=I1OK7fza FXPVH5SQ google.cz/ 1536 3355346560 30045265 3381481456 29898414 *

22

23 Data pro uchování stavu se ukládají na serveru. Vzniká problém důvěryhodné identifikace klienta Automatická správa session: při prvním požadavku server generuje identifikační kód session vytvoří prostor pro data identifikační kód zašle klientovi klient uloží kód do dočasného cookie souboru s každým požadavkem zašle klient serveru kód session

24

25 Umožňuje ukládání větších objemů dat i netextových dat. Data jsou uložena na serveru a přístupná pouze webovému serveru. Přenáší se pouze identifikační kód (SESSION ID). Slabým místem je identifikační kód identifikační kód je možno zcizit nebo podstrčit (session fixation) po zapomenutí kódu (zavření prohlížeče) je session nepřístupná Nejpoužívanější způsob ukládání stavu webových aplikací.

26 viz příloha http://akela.mendelu.cz/~xpopelka/cs/apv/ost/ses sion-soubory.pdf http://akela.mendelu.cz/~xpopelka/cs/apv/ost/ses sion-soubory.pdf http://akela.mendelu.cz/~xpopelka/cs/apv/ost/ses sion-databaze.pdf http://akela.mendelu.cz/~xpopelka/cs/apv/ost/ses sion-databaze.pdf Uchování stavu je nutná podmínka k realizaci zabezpečení

27 Problém 1: uživatel dlouho nic Problém 2: uchování stavu přihlášení, zabránění zcizení stavu Problém 3: kontrola uživatelských vstupů Problém 4: zabezpečení jména a hesla

28 Jméno kočičky není dobré heslo tedy pokud se kočička nejmenuje XdTg42W Jakékoliv heslo složené ze slov je slabé Jakékoliv heslo napsané na nástěnce je slabé Čím častěji je heslo použité tím je slabší Pro každou aplikaci musí být jiné heslo → KeePassKeePass Pro srovnání: slušný jazyk = 250 000 slov 8 míst = 6 553 600 000 000 kombinací 10 míst = 10 485 760 000 000 000 kombinací

29 autentizace – authentication – ověření identity uživatele autorizace - authorization – ověření oprávnění uživatele autentification – zkomolenina authentication 4 způsoby ověření identity uživatele: co víte (heslo) co máte (klíč, certifikát – velmi dobré) kdo jste (otisk prstu, duhovka – nepřesné) co děláte (hlasu, rukopisu – napodobitelné) 2F (two-factor) ověřování

30

31 Heslo je možné zadat do HTML formuláře Odesílá se nešifrované (plaintext) v POST požadavku. Odposlechnutí hesla je jednoduché. Podstrčení formuláře je jednoduché. Pro přihlášení je možné využít přihlášení protokolu HTTP Odposlechnutí hesla je složitější

32 Při přihlášení přes webový formulář se posílá heslo jednorázově (při odeslání formuláře) po ověření hesla musí server uchovávat stav přihlášení problém identifikace klienta různé metody verifikace kontrolní kódy, časově omezené kódy není spolehlivé

33 Při přihlášení pomocí HTTP se heslo odesílá při každém požadavku je možné uchovávat stav přihlášení nebo je možné ověřovat jméno a heslo při každém požadavku heslo je mnohočetným přenosem oslabováno je nutné kombinovat s šifrováním umožňuje ukládání Session do databáze odpadá problém identifikace klienta 2. nejbezpečnější způsob 1F přihlašování (hned po přihlášení osobním certifikátem)

34 Šifrovaný přenos je možný pomocí protokolu HTTPS Funguje jako obálka protokolu HTTP. Při šifrovaném přenosu zbývá zabránit podstrčení stránky K ověření pravosti stránky slouží certifikáty certifikát musí být platný certifikát musí být vydán pro aktuální server certifikát musí být ověřen certifikační autoritou certifikační autorita musí být pravá

35 Cílem certifikátu je ověřit pravost subjektu Každý certifikát musí ověřit certifikační autorita. Existují i self-signed certifikáty pro testovací účely

36 Pokud se přidá salt, pak prakticky stačí použít jednosměrný kódovací algoritmus (např. SHA256) dekódování je natolik náročné, že se útočník raději zaměří na jinou část aplikace Bezpečnější je použít (jednosměrný) šifrovací algoritmus (PHP crypt, generate_password()). Pokud je to možné, je třeba vyhnout se uchování/generování klíče (obousměrné šifrování). Hesla by měla být uložena v DB s vhodně nastavenými oprávněními.

37 http://www.xkcd.com/

38 Ošetření speciálních znaků při vkládání dat do databáze (PS, pg_escape_string()) SQL injection uvozovky, znak #0 a další podle DB serveru případně i další Ošetření speciálních znaků při zobrazování stránky na webu (html_special_chars()) Cross site scripting (XSS) HTML značky Skripty na straně klienta

39 alert(‘no nazdar'); Vzhledem k tomu, že escapování je nutné u každého řetězce – mají PHP funkce k tomu určené velmi krátké názvy: mysql_real_escape_string(htmlspecialchars($strin g, ENT_QUOTES, 'UTF-8')); nejjednodušší je ukládat data escapovaná, ale způsobuje to problémy při dalším vývoji aplikace nejsprávnější je escapovat data při zobrazení – použít šablonový systém

40 je závislé na kontextu ve kterém se data zobrazují buď se musí escapovat při zobrazení nebo při uložení a pak dost složitě konvertovat

41 Aby byl šifrovaný přenos bezpečný, musí být platné důvěryhodné certifikáty. Heslo musí být silné, jinak se dá uhádnout a žádné zabezpečení nepomůže. Uživatel musí být ostražitý. 2F zabezpečení je úplně někde jinde než 1F zabezpečení. 2F zabezpečení není zadaní dvou hesel! Escapovat (chránit se proti SQL injection a XSS) použít šablony a připravené dotazy https://www.owasp.org/index.php/Top_10_2013- Top_10 https://www.owasp.org/index.php/Top_10_2013- Top_10

42 Lze SQL injection útoku zabránit tak, že se z textu odstraní klíčová slova jazyka SQL? Vyžaduje uchování stavu pomocí session cookie soubory? Lze odeslat HTML formulář metodou GET? Kdo musí ověřit certifikát, aby byl důvěryhodný? Lze uchovávat session data v databázi? Kolik HTTP požadavků mezi jedním klientem a jedním serverem může být zpracováváno současně/paralelně? Lze z prohlížeče odeslat POST požadavek i bez použití formuláře? Hrozí XSS útok i pokud aplikace negeneruje žádné HTML stránky? Je možné aplikovat man-in-the-middle útok i pokud oběť používá HTTPS?