PHP a bezpečnost nejen veřejná
Navrhujeme bezpečné aplikace Efektivně spustitelných skriptů by mělo být co nejméně. V ideálním případě jen jeden "bootstrap" skript (index.php). Případně jeden bootstrap skript pro každou aplikaci (službu, ). Knihovní (includované) skripty Neobsahují žádný efektivně spustitelný kód. Jen deklarace tříd, funkcí, Nastavení serveru by nemělo umožnit přímý přístup ke knihovnám. Pokud je to možné zařídit (např. vhodnou modifikací.htaccess). Vkládání je bezpečnější s include_once() a require_once(). Nejlépe pouze na začátku skriptu. Existují i dobré výjimky např. šablony. verze 1.1 2008-2009, Martin Kruliš 2
Přenos dat mezi klientem a serverem HTTP pracuje přímo nad TCP Komunikace není šifrovaná. Kdokoli může vidět zasílaná a přijímaná data. HTTPS šifrované HTTP Spojení nad TCP je transparentně šifrováno OpenSSL. Webový server může i nemusí HTTPS podporovat. Otázka korektního nastavení, vlastního SSL certifikátu, PHP nemůže ovlivnit, zda se klient připojí přes HTTP, nebo HTTPS. Ale můžeme zjistit, zda byl požadavek šifrovaný. $_SERVER['HTTPS'] = 'on'; I přes šifrované spojení by se měla citlivá data (např. uživatelské heslo) přenášet co nejméně. Zejména není vhodné ukládat citlivá data do cookies. verze 1.1 2008-2009, Martin Kruliš 3
Hodnoty z formulářů Rozlišujme GET a POST parametry Není vhodné používat pole $_REQUEST, ani starší metody získávání zaslaných parametrů. Integrita parametrů Je třeba ověřovat integritu všech parametrů, které skript dostal. Uživatel (útočník) zvládne jednoduše modifikovat URL nebo upravit formulář v HTML. Opakované odesílání formulářových dat Většinou není žádoucí, aby mohl uživatel odeslat data vícekrát. Řešením je HTTP redirect, případně další techniky (počítadla, nastavení expirace, ). verze 1.1 2008-2009, Martin Kruliš 4
Databáze Zabezpečení databáze Databáze by měla být ve vaší "trusted base". Tedy tam, kde k ní máte přístup jen vy. Na serveru, který je zabezpečen (tj. i fyzicky). Samostatný uživatelský účet pro připojení z PHP. Princip minimálních práv Časté zálohy jsou nutností. Nejlépe na jiný server, v jiné budově (na jiném kontinentu ) Citlivé údaje v databázi Citlivé údaje by měly být šifrovány, nebo jinak znepřístupněny. Hesla se často hašují: <salt>,sha1(<salt>,<heslo>) "Salt" je sekvence náhodných znaků. verze 1.1 2008-2009, Martin Kruliš 5
Databáze http://xkcd.com/327/ Vstupní data do SQL dotazů Při vkládání formulářových dat přímo do SQL hrozí nebezpečí SQL-injection útoku. Vstupní data je třeba ošetřit (např. v MySQL existuje funkce mysql_real_escape_string()). verze 1.1 2008-2009, Martin Kruliš 6
Další injection útoky HTML (JavaScript) injection Uživatelem zadaná (a neošetřená) data se vkládají přímo do HTML. Útočník může vložit vlastní kód (např. <script> ). Pomocí JavaScriptu je jednoduché číst např. cookies na straně klienta a přes HTTP je poslat na jiný server. Stačí data ošetřit při vkládání (např. htmlspecialchars()). Další (méně obvyklé) varianty PHP injection Uživatelem zadaná data se použijí v PHP funkci eval(). Existují i méně očividné varianty např. použití nebezpečných dat v kombinaci s include(), require() nebo fopen(). Command-line injection Uživatelem zadaná data se použijí v příkazu system(), exec(), shell_exec() apod. verze 1.1 2008-2009, Martin Kruliš 7
Autentizace Autentizace je proces ověření totožnosti uživatele. U webových aplikací se nejčastěji používá kombinace jméno-heslo. Největším problémem je udržování informace o přihlášení. Uživatel by neměl neustále znovu zadávat přihlašovací údaje. Informace o přihlášení by měly být uloženy bezpečně. Musí být uloženy na straně klienta i na straně serveru. Možnosti uložení informací Na straně klienta Předáváním parametrů v HTML Cookies Na straně serveru Sessions Databáze, soubory, případně jiné persistentní úložiště verze 1.1 2008-2009, Martin Kruliš 8
Autentizace odcizení identity Problém bezstavovosti HTTP Každý požadavek je zpracováván zvlášť na základě informací od klienta. Pokud útočník duplikuje parametry, které uživatel přechovává na klientu, může odcizit jeho identitu a přihlásit se místo něj. Možná řešení Stoprocentně spolehlivé řešení neexistuje. Útočníkovy šance můžeme minimalizovat: Více ověřovacích informací na straně klienta a jejich obměňování Vypršení přihlášení při neaktivitě Ověřování specifických vlastností klienta (typ prohlížeče, IP adresa, ) U kritických operací vyžadovat heslo znovu (např. při změně hesla) Nejspolehlivější je ověřování podpisového certifikátu na klientovi. Pokud nedojde k jeho odcizení, nebo prolomení šifrování. verze 1.1 2008-2009, Martin Kruliš 9
HTTP Autentizace Protokol HTTP podporuje vestavěnou autentizaci Je-li uživatel autentizován, informace o něm jsou uloženy v: $_SERVER['PHP_AUTH_USER'] $_SERVER['PHP_AUTH_PW'] Pokud přihlašovací údaje nejsou k dispozici (nebo jsou neplatné), skript požádá v hlavičkách o autentizaci: header('www-authenticate: Basic realm="auth test"'); header('http/1.0 401 Unauthorized'); exit; Problémy: Klient i server musí HTTP autentizaci podporovat. Přihlašovací informace se posílají opakovaně (při každé akci). Není rozumně definované odhlašování. verze 1.1 2008-2009, Martin Kruliš 10
Autorizace Autorizace je proces ověřování uživatelských práv. V běžném IS se většinou vyskytují uživatelé s různými právy. Bezpečnostní model Definuje, co smí kteří uživatelé s jakými objekty provádět. Součástí def. je seznam chráněných objektů a možné operace s nimi. Jednoúrovňový bezpečnostní model vrací pouze ano/ne. Existují i složitější modely. Součástí definice modelu je seznam chráněných objektů a možné operace s nimi. Implementace Kód by měl být implementován na jednom místě (např. v jedné třídě nebo funkci). Práva je potřeba ověřovat při zobrazení dat i při jejich modifikaci. verze 1.1 2008-2009, Martin Kruliš 11
Bezpečnostní modely Adresář (Directory, Capability list) Každý uživatel má seznam objektů, ke kterým smí přistupovat. U každého objektu má seznam operací, které s ním smí provádět. Access Control List (ACL) U každého objektu je uložen seznam uživatelů, kteří s ním smí manipulovat (a povolené operace nad objektem). Access Control Matrix Matice uživatelé x objekty. Každé pole obsahuje seznam oprávnění uživatele pro daný objekt. Bell-Lapadula Každý uživatel má úroveň oprávnění, každý objekt (případně operace na objektu) má min. požadovanou úroveň oprávnění. Uživatel musí mít vyšší nebo stejná oprávnění. verze 1.1 2008-2009, Martin Kruliš 12
Autorizace další drobnosti Princip minimálních práv Co není povoleno, je zakázáno. Seskupování uživatelů Vytváření skupin uživatelů (ad unixové systémy). Práva se přidávají uživatelům i skupinám. Role Práva se nepřiřazují uživatelům, ale rolím. Uživatel odkazuje na jednu, nebo více rolí, které zastává. Jeho práva jsou maximální práva ze všech rolí. Capabilities Dočasná oprávnění jako např. lístek do kina. Lze je přidělit na základě složitějších ověření. verze 1.1 2008-2009, Martin Kruliš 13
Kde číhá nebezpečí Kdo (co) představuje největší hrozbu pro váš systém? Piráti? Hackeři? Zloději? verze 1.1 2008-2009, Martin Kruliš 14
Kde číhá nebezpečí Kdo (co) představuje největší hrozbu pro váš systém: Běžní uživatelé Selhání nosné infrastruktury (síť, disky, ) Výpadek elektřiny verze 1.1 2008-2009, Martin Kruliš 15
Pár rad na závěr Uklízejte po sobě Nenechávejte zbytečné informace v HTML, URL, cookies Nenechávejte otevřené sessions Omezte přístup k souborům, které nemá nikdo vidět Udržujte software aktuální Velké množství průniků je způsobeno chybami v PHP, web. serveru a jiném souvisejícím software. Zálohujte a zaznamenávejte logy operací Většina ztrát dat je zaviněna selháním nosné infrastruktury. Vlastní uživatelé jsou větší hrozbou než útočníci zvenku. Dávejte uživatelům minimální práva a dbejte na osvětu. verze 1.1 2008-2009, Martin Kruliš 16