Webové aplikace z pohledu serveru Jan Šembera 2007.

Prezentace na téma: "Webové aplikace z pohledu serveru Jan Šembera 2007."— Transkript prezentace:

1 Webové aplikace z pohledu serveru Jan Šembera 2007

2 Webové aplikace z pohledu serveru ● Jak pracuje webový server – statický obsah – dynamický obsah ● Pasti a propasti server-side skriptování – provozní a bezpečnostní aspekty

3 Vymezení hřiště ● Běžné UNIXové systémy ● Apache (až na zmíněné výjimky) ● PHP (zejména v 2. části) ●... ale i další server-side jazyky ● Ne Windows - IIS neumím.

4 Webserver ● HTTP (HTTPS) server ● Vyřizuje požadavky HTTP klientů ● Statický obsah ● Rozhraní pro dynamický obsah ● Nejčastěji daemon ● Kernelové webservery

5 Statický webserver ● Naparsuje příchozí HTTP požadavek ● Dohledá soubor v persistentním úložišti ● mmap() / read() ● write() ● Tedy vlastně triviální...

6 Webservery - Apache ● Apache (1.3, 2.0, 2.2) – majoritní UNIX webserver – "zdroj úspěchu Linuxu" – zcela modulární framework, HTTP, MPM (2.0+), mnoho zabudovaných i 3rd-party modulů – ohromné možnosti konfigurace – SSL, WebDAV, name-based virtualhosting, HTTP auth, rewriting, proxy, CGI,... – běží prakticky na všem

7 Webservery - IIS, Tux ● Microsoft IIS ● Tux (in-kernel webserver - Ingo Molnar) – idea: "statický webserver je kopírování souborů na síť, a to umíme v jádře" – pouze statický content – požadavky na dynamický content jsou proxovány do uživatelského prostoru – na reálných nasazeních je většina obsahu statická!

8 Webservery - Tux Nejmenovaný diskusní server - 5 / 2007

9 Webservery Market Share for Top Servers Across All Domains August 1995 - April 2007

10 Dynamický webserver ● Naparsuje příchozí HTTP požadavek ● Předá vstup handleru ● Načte výstup handleru ● Předá výsledný obsah klientovi ● Webserver je prostředníkem a pouze předává požadavky, reálnou práci provádí handler.

11 Bezpečnostní odbočka ● Webserver potřebuje práva na čtení souborů, které má poskytovat. ● U statického obsahu příliš nevadí. ● Pokud je nějaký generátor dynamického obsahu spuštěn webserverem, pak má stejná práva. ● Ve skriptech často bývají hesla, může vést až ke kompromitaci stroje. ● Zejména ve sdíleném prostředí nastává špatně řešitelný problém.

12 SSI ● Server Side Includes ● Provádí přímo Apache ● Includování souborů ● Dosazování proměnných ● Spouštění příkazů a dosazování výstupu

13 SSI ● Výhody: – Není třeba nějaký 3rd party modul a jazyk – Občas prostě stačí – Bezpečnost, pokud není povoleno spouštění ● Nevýhody: – Většinou prostě nestačí – Bezpečnost, pokud je povoleno spouštění

14 CGI ● Common Gateway Interface ● Standardizovaný způsob ● Průběh: – nastavení proměnných prostředí – fork() + exec() – načtení POST proměnných ze stdin – samotná práce skriptu – výstup na stdout – skript umírá – webserver zpracuje výstup skriptu a předá ho klientovi

15 CGI ● Výhody: – spustí prakticky cokoliv, co spustí OS (často používané jsou shellové a perlové skripty) – poměrně snadno se programují – stačí execute právo, netřeba read ● Nevýhody: – Bezpečnost - cizí kód s právy webserveru – Rychlost - fork je obecně pomalý

16 Modul ve webserveru ● mod_php, mod_perl, mod_python,... ● Dnes nejčastější varianta ● Handler je přímo modulem webserveru - bohužel do všech důsledků. ● mod_php poskytuje prostředky pro separaci (špatné).

17 Modul ve webserveru ● Výhody: – Velice rychlé, není třeba forkovat ani dělat context switche, lze dobře cachovat. – U PHP přímočará konfigurace. ● Nevýhody: – Bezpečnost - vše běží v kontextu httpd, naprosto cizí skripty jsou po sobě spouštěny ve stejném procesu, webserver musí umět skripty přečíst. – Silně vázané na API serveru (MPM, verze)

18 Aplikační frameworky ● Obvykle funguje jako samostatný webserver, statický webserver funguje pouze jako proxy. ● Plone, Django, Rails, Tomcat,... ● Velké množství různých frameworků, často navíc nevhodné pro sdílené hostingy. ● Výhradně běží pod "svým" uživatelem, některé ale poskytují vlastní prostředky pro zajištění separace...

19 Už se to blíží... ● suexec je součást Apache, která umožňuje spouštění CGI skriptů s právy jejich vlastníků (tedy nikoli webserveru). ● Wow! Máme separaci. ● Ale je to pořád pomalé...

20 FastCGI (+ suexec) ● To "pravé" řešení pro PHP i spoustu dalších podporovaných jazyků. ● Při prvním požadavku se chová podobně jako u CGI, ale když skript doběhne, proces po něm čeká na další požadavky. ● suexec: Každý uživatel má svou sadu čekajících procesů. Pokud je nějaký dlouho nevyužívaný, je ukončen.

21 FastCGI (+ suexec) ● Výhody: – Často překonává výkonem i moduly – Množství podporovaných jazyků – suexec: Kvalitní separace – Povětšinou nejsou problémy s API – Možnost provozovat "snadno" více verzí PHP na jednom stroji ● Nevýhody: – Složitější konfigurace - je bohužel příčinou naprostého nedocenění tohoto prostředku.

22 PHP na serveru ● Odteď předpokládám alespoň lehkou znalost PHP... ● Na vlastním hostingu si nastavíme co chceme jak chceme... ● Jenže mnohem častěji máme k dispozici pouze hosting sdílený a nemáme nad konfigurací kontrolu. Navíc je použit mod_php.. zde začíná peklo.

23 Webhoster vs. uživatel ● Webhoster chce... – udržet stroj v chodu – udržet klienty ve spokojeném stavu – mít rozumnou úroveň zabezpečení ● Uživatel chce... – služby bez kompromisů (ale za 5 Kč za rok) – útočit na webové stránky konkurence – testovat bezpečnost serveru – mít maximální úroveň zabezpečení

24 Webhoster vs. uživatel ● Tedy: klient chce všechno, ale zároveň požaduje bezpečnost a přitom je rizikem pro ostatní. ● Máme mod_php, který běží s právy webserveru. To pro počítání nebo hrátky s databází nevadí. Začne to vadit při přístupu k souborům a při spouštění.

25 Řešení? ● Spouštění cizích programů => zakázat. ● Čtení cizích souborů => nedovolit uživateli přečíst soubory, které mu nepatří. ● To ale umíme, zapneme PHP safe mode! –... noční můra všech PHP programátorů

26 PHP safe mode ● Mechanismus uvnitř PHP, který provádí různé "bezpečnostní" kontroly. ● Nejpodstatnější: Je UID otvíraného souboru rovno UID skriptu? – ANO: OK, soubor se otevře – NE: ERROR ● Tak dáme každému webu jeden UID a pojede to, ne...?

27 PHP safe mode NE! ● Pokud založíme nový soubor/adresář z PHP, práva k němu nedostaneme... ● Pokud nám někdo uploaduje soubor, práva k němu má opět webserver. ● Můžeme vytvořit snadno skript, který bude vlastnit webserver. Pak přečteme vše, co vlastní webserver... kdekoli.

28 PHP safe mode ● Výsledek: – Klient je nespokojen, že mu to nefunguje. – O málo lepší bezpečnost (skutečně si asi nepřečteme cizí hesla k databázi). – Nefungují už ani pořádně věci jako chmod (webserver nemůže měnit práva adresářů, které mu nepatří). – Klient jde ke konkurenci, kde dopadne stejně...

29 PHP safe mode ● Navíc: – PHP safe mode není vynucován operačním systémem. Pokud je v PHP díra, pak pravděpodobně safe mode prostřelíme. ● "Řešení" – Jde tomu pomoci pomocí SGID bitu - SGID bit na adresáři vyvolá dědičnost skupiny a safe mode jde přepnout na kontrolu GID. – Bohužel, spousta aplikací volá chmod(777), který SGID bit spolehlivě zabije... – Stále neřeší vše, něco fungovat nebude...

30 PHP safe mode ● "Řešení" – Uploadovací skript může uploadovaný soubor vzít a místo kopírování ho nahraje do svého prostoru pomocí FTP. – Taktéž může vytvářet adresáře pomocí FTP – To funguje, ale málokterá aplikace to implementuje...

31 PHP safe mode ● Opravdové řešení - lze dosáhnout pomocí patche do kernelu a změny chování filesystému (aby SUID na adresáři vyvolal také dědičnost). ● Dále patch do PHP, aby chmod() nedělal nic a vracel vždy úspěch - pouze pro uklidnění klientů. ● Bude fungovat vše, ale asi uznáte, že to není to pravé. ● V PHP6 již safe_mode nebude... co dál?

32 PHP open_basedir ● Každému webu nastavíme adresář, ze kterého nesmí uniknout. ● Poměrně dobrý nápad, v kombinaci se safe_mode už poskytuje poměrně rozumnou bezpečnost... ● Jenže opět není vynucováno OS, je to pouze opatření v kódu PHP a některá rozšíření ho nerespektují...

33 Conclusions & solutions ● mod_php + safe_mode_gid + open_bd + SGID – Pokud se aplikace budou chovat slušně a bude rozumně nakonfigurováno webhosterem, bude vše fungovat. – Aplikace se nechovají slušně... – Pořád hrozba díry v PHP ● FastCGI + PHP + suexec – Žádný mně známý hosting neimplementuje – Vše by fungovalo správně – Při chybě v PHP si lokální útočník hackne web akorát sobě...

34 Vnější bezpečnost webových aplikací ● Průnik z venku je u webových aplikací velice častý (hello, phpBB). ● Téměř vždy se jedná o špatně ošetřené vstupy. ● O web je zájem... spam, warez, DDos, redirect, kompromitace hostingového stroje, kompromitace uživatelských údajů na webu...

35 Dotazy? ●... ?