Dotaz: Zabezpečení ve vícevrstvé aplikaci

[Filip Jirsák]

Diskuse vznikla z vlákna této diskuse.

Odpovědi

[pht]

Ad. Everest, MySQL není pupkem světa, ale předmět dotazu je jasný :)

Tazatel nepíše nic o centrální autentizaci. Uživatele nabušíte do mysql přes myadmin stejně dobře jako byste je bušil do té aplikace.

Ad. Centrální heslo, kde ? co ? jak ?, každá aplikace má vlastní každý server má vlastní (je to jen jiný pohled na bezpečnost, Vám hesla kolují světem a je jich hodně, ale zajišťují oprávněnost požadavku na každé úrovni, a někomu jedno silné skryté heslo, které nikde nekoluje).

To jste ještě úplně asi nepochopil tu myšlenku. Bude-li N uživatelů, budu já mít N hesel, zatímco Vy budete mít N+1 hesel, kde právě to plus první bude heslo, kterým se aplikace připojuje do databáze. Uživatelská hesla budou kolovat světem stejně v obou modelech. Ve Vašem modelu navíc musíte dbát nejen o vysokou bezpečnost toho aplikačního hesla ale i o integritu celé aplikace. To jsou tisíce řádků navíc a tedy tisíce možných problémů. Ve Vašem modelu stačí najít jednu problematickou část a BANG uživatel aplikace má najednou všechna práva. To je pak bezvadné, když já jako registrovaný zákazník e-shopu můžu měnit stavy zásob na skladě.

A ano, každá aplikace může mít svoje vlastní heslo. Více aplikací neřeším bez újmy na obecnosti. Řeším jen více uživatelů s různými právy v rámci jedné aplikace.

tak si ten audit (chcete-li kontrolu) udělám abych zjistil jestli tam není nějaké potenciální riziko

Aha. Takže zřejmě máte schopnost najít všechny chyby v aplikaci během jednoho večera (nebo jak dlouho auditujete:)

A nebo ne? Jakou metodiku a nástroje používáte? Kolik lidí a jakých má Váš auditovací tým? Kolik času věnujete auditu? Auditujete i proces vývoje u dodavatele? Co děláte s chybami, opravujete je, posíláte patche? Ukažte reference na Vaši auditorskou činnost u několika OSS projektů.

Ad. Váš model (je jeden z modelů), ale je si třeba uvědomit, že tím musíte hlídat bezpečnost všech článků - DB server musí být odolný vůči vnějším útokům.

A Vy bezpečnost všech článků nehlídáte? Pak máte bezpečnost závislou na nejslabším z nich, tj. zřejmě velmi nízkou. To je ostatně vidět i na konceptu "aplikačního hesla". Jedna úroveň ochrany a konec.

100% integritu

Proč ne rovnou 110 :)

Všimněte si že připouštím více uživatelů na DB (read/write) a těch může být více (zmiňované role) - je to další stupeň bezpečnosti, eliminující jisté chyby v aplikaci.

To je hezké, ale pokud jsou hesla ke všem rolím na jednom místě, tak to zas tak moc velká výhra není.

Ruku na srdce jste schopen nastavit jednotlivé uživatele na velkém projektu přesně a do detailu tak aby měli oprávnění přesně na každý sloupec databáze (struktura DB se pak řídí jen bezpečnostním modelem)?

Ano jsem. V definici takových pravidel není rozdíl proti "programování aplikační logiky". Samozřejmě ta politika musí mít hlavu a patu nebo se z toho zblázníte. Jen v databázi je výsledek že to nenadefinujete, zatímco v "aplikační logice" to nějak uděláte, ale bude neprůhledné a pravděpodobně ochcatelné.

Rozlišit oprávnění na data a současně na procesy a akce na úrovni DB vyžaduje mít nastavenu 100% aplikační logiku v DB na vše VIEW a funkce metody a trigery. Samozřejmě je to cesta, a perfektní, ale realizace je mnohem náročnější a zrovna na intranet(záleží co to obnáší) mi to nepřipadne vhodná.

Vážně? Když bude mít Franta přístup do "objednávek" jen pro čtení a Honza jen pro připisování, tak mi na to stačí dva SQL příkazy při inicializaci účtů. Pak tato pravidla budou platit univerzálně, i kdyby se aplikační logika postavila na hlavu. Ve Vašem případě budete mít u každé činnosti deset ifů a pokud něco někde zmrvíte, tak objednávku přepíšete třeba jen omylem.

Triggery a funkce budete potřebovat až v druhé fázi (a to kdoví jestli). Například když budete chtít aby se při každé nové objednávce něco stalo. Jenže to může zrovna tak dělat ta aplikační logika jako dřív, protože to s bezpečností nesouvisí.

[Šangala]

Debata je nad rámec tohoto fóra a jak si myslíte vy, že nerozumím Vám tak vězte, že to platí i obráceně a není důvod proč dojít ke konsenzu.
Jen nevím proč tolik vášně, zvláště kvůli spojení mini-audit v závorce a ve větě, která neříká nic jen, že aplikace používanou na intranetu při přenosu do internetu je vhodné zkontrolovat.
Jinak všechny chyby většinou najdu ráno, večer vyvíjím už zas nové…

[pht]

No, pokud chcete vidět, kam všemocný přístup aplikace do všech svých dat spěje, tak viz třeba momentální aféra kolem iggiho.

[Filip Jirsák]

Přístup, kdy uživatelé aplikace jsou 1:1 mapováni na uživatele databáze, se prakticky nepoužívá (popravdě si nevzpomínám na žádnou aplikaci, která by to takhle měla). Ona totiž přístupová práva často nejsou definována jen tabulkami a sloupci, ale často také aplikační logikou. Navíc pro přihlášení k databázi musíte až k té databázi dostat heslo v otevřeném tvaru, což taky nemusí být vždy bezpečné (třeba vás to donutí použít HTTP Basic autentizaci místo Digest autentizace). Uživatel, pod kterým přistupuje aplikace, by neměl mít práva, která nepotřebuje (třeba ke změnám schématu databáze), ale jinak není na principu, že k databázi přistupuje jen prověřená aplikace, nic špatného (samozřejmě pokud dokážeme dodržení tohohle pravidla zaručit – což u vícevrstvých nebo webových aplikací jde relativně snadno).

[pht]

popravdě si nevzpomínám na žádnou aplikaci, která by to takhle měla

To je bohužel tragédie současnosti.

Já bych si i vzpomněl ale je to mimo tenhleten "sdílej s přáteli své fotky a videa a když to někdo probourá tak se přinejhorším bude někdo cítit chvíli trapně" folklór.

Pokud budete chvíli hledat na webu, tak najdete spoustu instancí, kde se tohle řeší nebo používá.

třeba vás to donutí použít HTTP Basic autentizaci místo Digest autentizace

On někdo používá na tohle digest? Hahahahaha... ahahaha... všechny tyhle weby maj přihlášení přes formulář, a pár těch lepších to tam volitelně pleskne přes https (jen to přihlášení, ta videa už ne ;)

Kde na tom záleží, se to dá samozřejmě elegantně řešit pomocí klientských SSL certifikátů, ten může ověřit web i databáze.

Ona totiž přístupová práva často nejsou definována jen tabulkami a sloupci, ale často také aplikační logikou.

To je dost nesmysl. Pokud je bezpečnost již základní, nikoliv dodatečná funkce, tak lze vždy navrhnout schema tak, aby to fungovalo. Přinejhorším se na komplikované úkony vyhradí nějaká procedura.

(Ukažte mi nějaký příklad, kde je to tak hrozné, jak říkáte.)

není na principu, že k databázi přistupuje jen prověřená aplikace, nic špatného (samozřejmě pokud dokážeme dodržení tohohle pravidla zaručit – což u vícevrstvých nebo webových aplikací jde relativně snadno)

Pokud Vám nestačí, že to jde proti logice věci (hůře se bezpečnost hlídá na vnějších složitých vrstvách než na vnitřních a jednoduchých), tak se podívejte na příkladná selhání uvedené výše.

[Filip Jirsák]

On někdo používá na tohle digest? Hahahahaha... ahahaha... všechny tyhle weby maj přihlášení přes formulář, a pár těch lepších to tam volitelně pleskne přes https (jen to přihlášení, ta videa už ne ;)

Takže vy chcete, aby uživatel mohl na databázi spustit libovolný SQL příkaz, a jen databáze hlídala, zda mu to dovolí, a zároveň chcete posílat hesla nešifrovaně přes internet?

Ukažte mi nějaký příklad, kde je to tak hrozné, jak říkáte.

Všude. Třeba v e-shopu bych měl asi vidět jen obsah svého košíku, v elektronickém bankovnictví jen svoje transakce – tabulka položek v košíku nebo tabulka transakcí ale asi bude společná, jenom bude každý řádek patřit někomu jinému. Když použijete uložené procedury, znovu je musíte spouštět pod uživatelem, který má přístup k datům všech uživatelů – takže jste tu hranici pouze posunul z rozhraní aplikace–databáze dovnitř databáze na rozhraní uložené procedury – SQL.

Dělat veškeré zabezpečení už na úrovni databáze je hezká věc, ale dnes se to moc nepoužívá, protože je jednodušší to zabezpečení udělat v aplikaci. A pokud programátor aplikace není trouba, aplikace využívá jen omezenou sadu SQL příkazů, jejichž správnost je možné kontrolovat, a nedovolí uživateli spouštět libovolný uživatelem zadaný SQL dotaz.

[pht]

aby uživatel mohl na databázi spustit libovolný SQL příkaz, a jen databáze hlídala, zda mu to dovolí

Ano to je správný přístup.

chcete posílat hesla nešifrovaně přes internet

Přečtěte si laskavě pořádně příspěvek na který reagujete, žádnou takovou touhu jsem nevyjádřil.

BTW i kdyby (a zdůrazňuji to kdyby) se heslo poslalo nešifrovaně tak je to pořád bezpečnější, když přes to heslo má útočník přístup jen někam, než když se heslo neprozradí ale díky jiným chybám bude mít útočník přístup všude.

tabulka položek v košíku nebo tabulka transakcí ale asi bude společná, jenom bude každý řádek patřit někomu jinému

Hmm, tak pro takhle jednoduchý příklad si uděláte view který zobrazí uživateli jen ty jeho řádky.

CREATE VIEW muj_kosik AS SELECT * FROM kosik WHERE uzivatel = CURRENT_USER;

Složitost sama!

Pro obecný případ se dá použít row level security. Securityfocus uvádí tutorial z roku 2003 (!). Dnes toto samozřejmě umí tato i jiné databáze mnohem víc. Určitě jen proto, aby to nějaký chytrolín všechno hned vypnul a dělal si "aplikační logiku"

Když použijete uložené procedury, znovu je musíte spouštět pod uživatelem, který má přístup k datům všech uživatelů – takže jste tu hranici pouze posunul z rozhraní aplikace–databáze dovnitř databáze na rozhraní uložené procedury – SQL.

Nevidím důvod proč by procedura měla mít nějaké vyšší oprávnění než ten uživatel. Její použití bude spíše takové, že ulehčí komplikované operace, nebo zavede dodatečné kontroly. Každopádně ale bude platit, že bez i s procedurou se nedostanu do košíku jiných lidí.

Dělat veškeré zabezpečení už na úrovni databáze je hezká věc, ale dnes se to moc nepoužívá, protože je jednodušší to zabezpečení udělat v aplikaci.

Zrovna jako je jednodušší všechno spouštět pod Administrátorem...

A pokud programátor aplikace není trouba, aplikace využívá jen omezenou sadu SQL příkazů, jejichž správnost je možné kontrolovat, a nedovolí uživateli spouštět libovolný uživatelem zadaný SQL dotaz.

Bohužel to není jen o kontrole SQL. Budete muset kontrolovat správnost úplně všeho, počínaje tím SQL, přes logiku, která implementuje Váš bezpečnostní model, vlastní pravidla v té logice, až po úplně nesouvisející kód, který ale při kompromitaci bude mít možnost pracovat s databází. Samozřejmě průměrné webové studio má dozajista dostatek prostředků i odborníků, takže ta kontrola je samo sebou, a předčí kvality desetiletí vývoje databází...

Když se na to podíváte takhle, tak nevím, jestli to je jednodušší. Samozřejmě ta jednoduchost je asi jen v tom, že to takhle nikdo nedělá. Každý si to napíše od boku, jak se mu to líbí. Jak jsem říkal, takový kód je pak možno použít jen tam, kde nějaké prolomení jednou za čas je přinejhorším "malá nepříjemnost".

BTW, proč si to takhle nezkusíte někdy naprogramovat, a pak si promluvíme znova.

[Filip Jirsák]

Nevidím důvod proč by procedura měla mít nějaké vyšší oprávnění než ten uživatel. Její použití bude spíše takové, že ulehčí komplikované operace, nebo zavede dodatečné kontroly. Každopádně ale bude platit, že bez i s procedurou se nedostanu do košíku jiných lidí.

Pokud procedura zavádí dodatečné kontroly, znamená to, že uživatel k dané věci nesmí mít práva (jinak by snadno dodatečné kontroly obešel tak, že by příkazy z procedury spustil bez kontrol). Tedy procedura musí běžet s právy jejího vlastníka, která musí být vyšší, než práva uživatele.

Zrovna jako je jednodušší všechno spouštět pod Administrátorem...

Jádro operačního systému taky klidně můžete naprogramovat tak, že bude mít různé úrovně oprávnění. Přesto se to ve spoustě systémů (i v Linuxu) řeší tak, že v jádru běží „vše pod Administrátorem“, a práva se řeší až v uživatelském prostoru.

Bohužel to není jen o kontrole SQL. Budete muset kontrolovat správnost úplně všeho, počínaje tím SQL, přes logiku, která implementuje Váš bezpečnostní model, vlastní pravidla v té logice, až po úplně nesouvisející kód, který ale při kompromitaci bude mít možnost pracovat s databází.

Bezpečnostní model budu muset kontrolovat v obou případech, akorát jednou bude zapsán v aplikační logice, podruhé v databázové. Nesouvisející kód z tohoto pohledu kontrolovat nemusím – buď kód pracuje s databází a pak se v něm používá omezená množina SQL příkazů, nebo s databází nesouvisí, a pak ho nemusím kvůli bezpečnosti dat v DB řešit. Pokud je někde chyba, která umožní v kontextu aplikace spouštět útočníkův kód, je možnost přístupu do databáze pouze jedním dílčím průšvihem…

BTW, proč si to takhle nezkusíte někdy naprogramovat, a pak si promluvíme znova.

Protože programuju tak, že používám v databázi pohledy a uložené procedury a v aplikaci mám už jen jednoduché SQL příkazy. Což je o dost víc logiky v databázi, než jak se dnes s databázemi běžně pracuje. Dělat na straně databáze i ověřování přístupových práv se podle mne nevyplatí – třeba proto, že nepotřebuju jen dělení na jednotlivé uživatele, ale třeba i na jejich session, a to už bych tu logiku musel psát dvakrát – jednou v databázi pro uživatele, podruhé v aplikaci pro session. A některé věci bych jen s pomocí databáze dělal horko těžko, nebo by nešly udělat vůbec – ať už je to HTTP digest přihlášení, „malé“ přihlášení (uživatel je na základě cookie identifikován, může prohlížet část údajů, ale ne všechny a není mu umožněn zápis, to až po přihlášení heslem), nebo třeba změna zapomenutého hesla. První případ je bez podpory v databázi neřešitelný, druhé dva vyžadují použití „skoro všemocného“ uživatelského účtu, který umožní obejít oprávnění kontrolovaná databází, a aplikace musí umět tenhle účet použít – jakmile něco takového do aplikace zavedete, je vám k ničemu to, že ostatní přístupová práva chrání databáze.

[pht]

jinak by snadno dodatečné kontroly obešel tak, že by příkazy z procedury spustil bez kontrol

To je možné, ale ne vždy něco obejít znamená bezpečnostní riziko. Může to znamenat, že pak budou v databázi nesmysly, bordel, nekompletní informace, atp. Takový stav se pak dá detekovat a ošetřit.

Tedy procedura musí běžet s právy jejího vlastníka, která musí být vyšší, než práva uživatele.

Ne nezbytně; pokud tedy už by měla procedura dělat nějakou privilegovanou činnost, tak patrně budou její práva omezená pouze na tuto jednu činnost. Kód takové procedury bude krátký a doufejme že bez děr. I kdyby díry měla, bude její působnost silně omezena právy.

Např. odeslat košík můžete jen pomocí procedury odesli_kosik, která něco změní v tabulce objednavky, kam normálně nemáte vůbec přístup. Procedura bude mít přístup k tabulce objednavky na připisování ale už nebude mít přístup k Vašemu košíku. Jednoduchý a standardní postup. Porovnejte to s tím, když s vysokými právy k databázi běží tuna PHP kódu (viz níže).

Přesto se to ve spoustě systémů (i v Linuxu) řeší tak, že v jádru běží „vše pod Administrátorem“, a práva se řeší až v uživatelském prostoru.

No a kód samotné databáze také běží jakoby "pod administrátorem" vzhledem k db. Ačkoli se to dá vhodnou separací procesů dost omezit.

A co se týče Linuxu, nikdo neřekl, že jeho monolitický design je state-of-the-art bezpečnosti, spíše naopak. Pokud blbě napsaný driver na USB vařič na kafe, který je součástí všech distribucí, může shodit celé jádro, tak potěš koště. Nerad to říkám, ale vemte si příklad z přístupu, který je použit ve vistě (64), kde v jádře běží podstatně méně ovladačů a zbytek jsou normální procesy...

Nesouvisející kód z tohoto pohledu kontrolovat nemusím

Blbost; dokud lze znásilnit jakýkoliv odlehlý kout Vaší aplikace, máme přístup k master heslu, nebo k běžícímu spojení a tudíž k celé db.

Pokud je někde chyba, která umožní v kontextu aplikace spouštět útočníkův kód, je možnost přístupu do databáze pouze jedním dílčím průšvihem…

Musíte předpokládat, že tam je (můžete se vsadit že tam bude), a musíte se snažit ten průšvih minimalizovat. Bezpečnost musíte řešit na více úrovních, ne jen na přihlašovacím formuláři. BTW zkuste být kreativní: jaké další problémy můžou plynout z takové situace?

než jak se dnes s databázemi běžně pracuje

Prosím Vás, jak kde. "Fórum pro můj kolejní blok" není celosvětové mistrovské dílo. Tam kde o to jde, se databáze používají se vším co umí.

třeba proto, že nepotřebuju jen dělení na jednotlivé uživatele, ale třeba i na jejich session

K čemu je tohle dobré?

„malé“ přihlášení

nebo třeba změna zapomenutého hesla

No, myslím že na oboje by se dalo lamentovat dlouze, ale sečteno podtrženo ani jedno nemá co dělat v aplikaci kde je kladen důraz na bezpečnost dat. Tam je totiž lepší, když něco nejde, a musí to počkat na administrativní zásah, než aby toho šlo víc než bylo původně zamýšleno. Tím ale nechci říct, že taková věc nejde naimplementovat. Uděláte si proceduru, která poběží s právy dostatečnými na reset hesla, konec.

[Filip Jirsák]

To je možné, ale ne vždy něco obejít znamená bezpečnostní riziko.

Pak ale nevadí ani to, když to někdo obejde kvůli chybně napsané logice aplikace.

Ne nezbytně; pokud tedy už by měla procedura dělat nějakou privilegovanou činnost, tak patrně budou její práva omezená pouze na tuto jednu činnost. Kód takové procedury bude krátký a doufejme že bez děr. I kdyby díry měla, bude její působnost silně omezena právy.

To pak ale znamená pro každou jednotlivou činnost nadefinovat extra uživatele a přidělit mu práva.

A co se týče Linuxu, nikdo neřekl, že jeho monolitický design je state-of-the-art bezpečnosti, spíše naopak.

Také ale nikdo neříká, že e-shop musí být bezpečnější, než kdejaká bankovní aplikace.

Blbost; dokud lze znásilnit jakýkoliv odlehlý kout Vaší aplikace, máme přístup k master heslu, nebo k běžícímu spojení a tudíž k celé db.

měl jste pokračovat ve čtení. Dál jsem jasně napsal, že v takovém případě je plný přístup k databázi pouze jedním dílčím průšvihem. Ono když můžu v kontextu aplikace spustit libovolný kód, můžu si tam spustit i kód, který bude sledovat a uchovávat hesla uživatelů, kteří se prostřednictvím aplikace přihlašují k databázi – takže vámi popsané řešení je na tom úplně stejně, jako aplikace, která používá hlavní heslo.

Musíte předpokládat, že tam je (můžete se vsadit že tam bude), a musíte se snažit ten průšvih minimalizovat.

Tak se snažte. Spouštění SQL dotazů v kontextu konkrétního uživatele vám v tomto případě ale nepomůže, jak už jsem psal výše. Když předpokládáte, že se v kontextu vaší aplikace může spustit libovolný kód, máte jedinou možnost – přidat celou další vrstvu, která bude zajišťovat bezpečnost, aplikační logiku, ukládání dat – prostě vše. To pak ale můžete tu původní děravou aplikaci vyhodit.

BTW zkuste být kreativní: jaké další problémy můžou plynout z takové situace?

Plyne z ní problém jediný – že tu aplikaci můžete zahodit a napsat místo jí jinou, která takové problémy mít nebude.

Tam kde o to jde, se databáze používají se vším co umí.

Což budou tady v ČR jednotky aplikací, a rozhodně se v nich nevyskytuje ani PHP ani MySQL.

třeba proto, že nepotřebuju jen dělení na jednotlivé uživatele, ale třeba i na jejich session

K čemu je tohle dobré?

Třeba k tomu, že jeden uživatel může pracovat na dvou věcech najednou, a když si otevře dvě různé faktury a na první dá storno, stronuje se mu opravdu první faktura a ne ta druhá.

No, myslím že na oboje by se dalo lamentovat dlouze, ale sečteno podtrženo ani jedno nemá co dělat v aplikaci kde je kladen důraz na bezpečnost dat. Tam je totiž lepší, když něco nejde, a musí to počkat na administrativní zásah, než aby toho šlo víc než bylo původně zamýšleno. Tím ale nechci říct, že taková věc nejde naimplementovat. Uděláte si proceduru, která poběží s právy dostatečnými na reset hesla, konec.

Naopak, v aplikaci, kde je kladen důraz na bezpečnost dat, je rozumné, aby uživatel pracoval s minimálními právy, která potřebuje. Takže když potřebuje zjistit počet nepřečtených zpráv, nemusí mít práva, která mu umožní zprávy vytvářet, upravovat a mazat.

Čekat na administrativní zásah má smysl tam, kde se to děje výjimečně a administrátor má šanci oprávněnost požadavku si ověřit. Když bude administrátorovi volat dvacet lidí denně, že zapomněli heslo, bezpečnost bude nulová – bude stačit, aby mu tam takhle zavolal jako dvacátý prví útočník, a administrátor změnu provede.

Postupem času jste dospěl k tomu, že na všechno budete mít zvláštní procedury s příslušným oprávněním. Takže celou aplikační a bezpečnostní logiku budete mít naprogramovanou v SQL databázi a aplikace to bude jenom převolávat. Ano, je to možné řešení. Jenom si zkuste porovnat možnosti SQL a vyšších programovacích jazyků (Java, Python, C++) – výrazové možnosti jazyka a knihoven, kontrolu kódu IDE, testování, ladění…

[pht]

Pak ale nevadí ani to, když to někdo obejde kvůli chybně napsané logice aplikace.

Ne, to nevadí.

To pak ale znamená pro každou jednotlivou činnost nadefinovat extra uživatele a přidělit mu práva.

Ne uživatele ale kontext a ano, separace práv je jeden z nástrojů které použijete. A nemusíte to tak dělat se vším, jen s rizikovými operacemi. V operačním systému také nemusíte separovat práva pro "sed" zavolaný z bashe, ale pro "passwd" už ano.

Ono když můžu v kontextu aplikace spustit libovolný kód, můžu si tam spustit i kód, který bude sledovat a uchovávat hesla uživatelů, kteří se prostřednictvím aplikace přihlašují k databázi

To není nutně pravda. Pokud je aplikace udělaná dobře, tak po autentizaci můžete dostat jiný kontext pro každého uživatele. Váš pracovní thread pak nebude mít prakticky právo na víc než se hrabat v té databázi, respektive k tomu, co by ta aplikace legitimně dělala.

Ale i v tom horším případě, kdy skutečně můžu nějak znásilnit přihlašovací formulář, nebude vše tak zlé. Jednak jak jsem říkal, je toto jeden z důvodů proč se používají cerifikáty, tokeny, atd. (To platí i např. o ssh.) Pak si můžete poslouchat co chcete.

Vaší další možností jako útočník bude počkat až se uživatel přihlásí a pak nějak převzít jeho session (útok typu "čas autentizace verzus čas použití"). Tomu se dá bránit tím, že každou důležitou operaci autorizuje uživatel separátně (např. e-banka autorizuje zvláštní SMS každou provedenou platbu atd).

Samozřejmě pak existují postupně další a další levely útoků a ochran. Je to ale úplně jiná situace než když po první chybě v PHP skriptu mám k dispozici neomezeně celou databázi (data, hesla, ...), ne?

To pak ale můžete tu původní děravou aplikaci vyhodit.

To je nesmysl. Nikdo nikdy (možná až na nějaké extrémy) nic vyhazovat nebude. Bezpečnost není binární (děravá verzus bezpečná aplikace). Není ani skalární (90% bezpečná) - vyhodnocuje se vždy vzhledem k nějakým okolnostem a předpokladům a není ani statická - mění se v čase. Ergo nemá cenu nic vyhazovat, ale má cenu to postupně zlepšovat.

přidat celou další vrstvu, která bude zajišťovat bezpečnost, aplikační logiku, ukládání dat

Přesně tak, vrstvu za vrstvou, kde každá eliminuje nějaké riziko, ale zároveň počítá s tím, že předchozí vrstvy jsou plně v rukou útočníka.

Příklad: nejlepší šifry (např AES) jsou odolné proti útoku, kde si útočník může nechat od Vás zašifrovat libovolně mnoho libovolných zpráv, a stejně nezjistí klíč jinak než hrubou silou. Slabší šifry se při takovémto útoku rozpadnou.

Analogie: v mém případě databáze předpokládá, že se na ni útočník může připojit a provést libovolnou operaci, výsledek bude, že stejně bez hesla nenapáchá víc škody než by mohl přes tu web aplikaci.

Takže když potřebuje zjistit počet nepřečtených zpráv, nemusí mít práva, která mu umožní zprávy vytvářet, upravovat a mazat.

To lze vyřešit rolemi, pokud tohle Vaše aplikace má umět, tak se uživatel přihlásí do role pro čtení. (Může a nemusí mít jiné heslo/jiný autentizační mechanizmus než k roli pro zápis.) Výsledek ale nebude dvojnásobný počet uživatelů, jen to jedno rozlišení rolí v politice.

Když bude administrátorovi volat dvacet lidí denně, že zapomněli heslo, bezpečnost bude nulová – bude stačit, aby mu tam takhle zavolal jako dvacátý prví útočník, a administrátor změnu provede.

Tohle by vedlo k rozsáhlejší debatě na zamyšlení. Pravda je taková, že když každý web bude po mně chtít unikátní, bezpečné, atd. heslo (které si pak uloží plaintextově :), tak se z toho zachvíli pos*ru (některé weby i několikrát, jednou do bugzilly, jednou na fórum, ...) a buď budu používat slabá hesla, nebo je budu zapomínat. Volba "zapomněl jsem heslo" není řešení, ale obejití tohoto problému. (U aplikací, kde tato volba chybí, uživatelé zas tak často heslo nezapomínají.:)

Samozřejmě pokud bude existovat linka, kde zavolá každý hej počkej a vyžádá si nové heslo pro kohokoliv, tak se toho moc nevyřeší. Telefonní operátoři Vás obvykle donutí přijít na pobočku a prokázat se obč. průkazem.

Postupem času jste dospěl k tomu, že na všechno budete mít zvláštní procedury s příslušným oprávněním.

Nemůžete chodit z extrému do extrému. Nic nemusí být perfektní, stačí aby to bylo dost dobrý. IMHO posunutí bezpečnosti z 90% aplikačních serverů směrem k db by stálo marginální úsilí a pozitivní výsledek by se dostavil poměrně brzo.

Což budou tady v ČR jednotky aplikací, a rozhodně se v nich nevyskytuje ani PHP ani MySQL.

Myslím si, že toho bude víc. Dále si myslím, že většina věcí u nás nebude vyvinuta u nás. PHP si svou cestu už prošlo a myslím si, že v něm lze při troše snahy psát bezpečné aplikace. MySQL je použitelné, ale trochu pokulhává. Pokud chcete víc, nic Vám nebrání použít místo MySQL třeba postgres nebo oracle. V PHP jsou ty funkce úplně stejné.

[Filip Jirsák]

To není nutně pravda. Pokud je aplikace udělaná dobře, tak po autentizaci můžete dostat jiný kontext pro každého uživatele. Váš pracovní thread pak nebude mít prakticky právo na víc než se hrabat v té databázi, respektive k tomu, co by ta aplikace legitimně dělala.

A teď píšete ještě pořád o PHP, nebo už o nějaké aplikaci, která snad běží rovnou na hardwaru, aby se vyhnula případných chybám operačního systému?

Je to ale úplně jiná situace než když po první chybě v PHP skriptu mám k dispozici neomezeně celou databázi (data, hesla, ...), ne?

Můžete popsat konkrétní příklad, jak by vypadala taková chyba v PHP, jejíž zneužití by znamenalo přístup k celé databázi, ale pokud by se uživatel přihlašoval svým jménem a heslem až k databázi, tato chyba by jej neohrozila?

Přesně tak, vrstvu za vrstvou, kde každá eliminuje nějaké riziko, ale zároveň počítá s tím, že předchozí vrstvy jsou plně v rukou útočníka.

Takže každá taková vrstva musí opakovat všechny zabezpečovací mechanizmy vrstev předchozích. K čemu tam pak ty předchozí vrstvy jsou? A kde se tohle v praxi používá? Já bych si tipnul, že vůbec nikde.

Tohle by vedlo k rozsáhlejší debatě na zamyšlení. Pravda je taková, že když každý web bude po mně chtít unikátní, bezpečné, atd. heslo (které si pak uloží plaintextově :), tak se z toho zachvíli pos*ru (některé weby i několikrát, jednou do bugzilly, jednou na fórum, ...) a buď budu používat slabá hesla, nebo je budu zapomínat. Volba "zapomněl jsem heslo" není řešení, ale obejití tohoto problému. (U aplikací, kde tato volba chybí, uživatelé zas tak často heslo nezapomínají.:)

Jsou dvě možnosti – buď si ta unikátní hesla někam ukládat a používat k nim hlavní heslo (už zase), nebo za předpokladu, že se používají otisky hesel se solí (třeba HTTP Digest) můžete klidně používat všude jedno a to samé heslo.

Nemůžete chodit z extrému do extrému.

Mít zabezpečení aplikace na úrovni účtů jednotlivých uživatelů v databázi mi připadá jako právě jeden z extrémů.

IMHO posunutí bezpečnosti z 90% aplikačních serverů směrem k db by stálo marginální úsilí a pozitivní výsledek by se dostavil poměrně brzo.

Úsilí by nebylo marginální, protože byste musel zahodit celou současnou aplikaci i běhové prostředí a začít úplně znova. Existuje vůbec nějaký hotový aplikační server, který počítá s možností používat ke kontrole oprávnění přímo účty v databázi? A jaký pozitivní výsledek by se dostavil? Kdy jste slyšel o nějakém případu, kdy by se podařilo získat kontrolu nad spojením aplikačního serveru do databáze, kdy se nejednalo o hloupé skládání SQL příkazů?

[pht]

A teď píšete ještě pořád o PHP, nebo už o nějaké aplikaci, která snad běží rovnou na hardwaru, aby se vyhnula případných chybám operačního systému?

Tohle zabezpečení lze použít na Apache, takže myslím, že PHP se do toho počítá. Nevím, proč bych měl řešit v aplikaci chyby OS. Každý řeší jen to, co mu náleží. Chyby OS řeší dodavatel OS.

Můžete popsat konkrétní příklad, jak by vypadala taková chyba v PHP, jejíž zneužití by znamenalo přístup k celé databázi, ale pokud by se uživatel přihlašoval svým jménem a heslem až k databázi, tato chyba by jej neohrozila?

Velmi zjednodušeně:

eval($input)

kde proměnná input je nastavená uživatelem. Složitější chyby se pak na toto dají zredukovat.

Takže každá taková vrstva musí opakovat všechny zabezpečovací mechanizmy vrstev předchozích.

Proč? Každá vrstva řeší svoji část. Copak snad jádro řeší problémy blbě napsaných setuid aplikací? Nebo filtruje připojení k X serveru?

A kde se tohle v praxi používá? Já bych si tipnul, že vůbec nikde.

Máte pravdu, duplicitní snaha o totéž se nepoužívá nikde

Jsou dvě možnosti – buď si ta unikátní hesla někam ukládat a používat k nim hlavní heslo (už zase), nebo za předpokladu, že se používají otisky hesel se solí (třeba HTTP Digest) můžete klidně používat všude jedno a to samé heslo.

A co třeba na kolejforum.cz odeslat místo hesla veřejnou část svého SSL cert. ? Nebo tuna jiných možností. Bohužel na to nikdo nebere ohled. OpenID je jedna malá snaha.

Mít zabezpečení aplikace na úrovni účtů jednotlivých uživatelů v databázi mi připadá jako právě jeden z extrémů.

Jiným zase připadá extrémní používat různé účty v OS

Existuje vůbec nějaký hotový aplikační server, který počítá s možností používat ke kontrole oprávnění přímo účty v databázi?

Počítá s tím pravděpodobně každý, protože na to nepotřebujete nějaké extra úsilí. Místo login(universal_pw) použijete login(user_pw). Každopádně middleware produkty, které k takovému postupu aktivně navádí, existují. Lotus Notes, Oracle TopLink, a další si jistě dohledáte sám.

Kdy jste slyšel o nějakém případu, kdy by se podařilo získat kontrolu nad spojením aplikačního serveru do databáze, kdy se nejednalo o hloupé skládání SQL příkazů?

No, tak za prvé, to "hloupé skládání" je docela nepříjemná věc, která je jedna z nejčastějších metod útoku. V trochu složitější aplikaci se SQL skládá na spousta místech a různými způsoby, divil bych se, kdyby to bylo perfektní. A pokud se můžu zaregistrovat jako návštěvník a pak zneužít nějaký blbě napsaný modul, abych dostal plná práva k databázi, tak to není zrovna dobré zabezpečení.

Za druhé nepotřebujete moc důvtipu, abyste si domyslel, že pokud mi chyba v AS dovolí vykonávat kód ve svém chlívku, tak budete moci iniciovat SQL spojení pod jejím účtem :)

A za třetí, spousta firemních programů (účto, projekty, docházka, ...) běží v režimu tlustý klient. Tj. aplikace připojující se do db běží na Vašem počítači. Stále máte pocit, že je dobrý nápad aby použila jedno heslo, které může ke všemu?

A vůbec, proč já se snažím. Najděte si ty use casy sám.

[Filip Jirsák]

Velmi zjednodušeně:

eval($input)

kde proměnná input je nastavená uživatelem. Složitější chyby se pak na toto dají zredukovat.

Zapomněl jste na druhou část mého dotazy, tedy aby ta chyba neohrozila jiné uživatele.

Proč? Každá vrstva řeší svoji část.

Předtím jste ale psal, že každá vrstva předpokládá to, že předchozí vrstvu má plně pod kontrolou útočník.

Počítá s tím pravděpodobně každý, protože na to nepotřebujete nějaké extra úsilí. Místo login(universal_pw) použijete login(user_pw).

To ale nebude fungovat v prostředí, které používá sdílená připojení, umožňuje běžet nad různými databázemi, používá sdílené transakce – tohle všechno vám nebude s vaším modelem fungovat jen tak samo od sebe.

Každopádně middleware produkty, které k takovému postupu aktivně navádí, existují. Lotus Notes, Oracle TopLink, a další si jistě dohledáte sám.

Oracle TopLink? To je nějaký jiný Oracle TopLink, než ten, který implementuje JPA, nebo Oracle TopLink umožňuje JPA tak znásilnit, aby se to takhle chovalo, a v dokumentaci to není nikde zmíněno?

No, tak za prvé, to "hloupé skládání" je docela nepříjemná věc, která je jedna z nejčastějších metod útoku.

Mne by zajímaly ty další metody.

V trochu složitější aplikaci se SQL skládá na spousta místech a různými způsoby, divil bych se, kdyby to bylo perfektní.

Proč? Připadá mi mnohem jednodušší opravit tohle než se přihlašovat do databáze pod různými databázovými uživateli.

Za druhé nepotřebujete moc důvtipu, abyste si domyslel, že pokud mi chyba v AS dovolí vykonávat kód ve svém chlívku, tak budete moci iniciovat SQL spojení pod jejím účtem :)

Jak už jsem psal, pokud AS dovolí vykonávat útočníkův kód, je získaný přístup k databázi pouze jedním z mnoha dílčích problémů.

A za třetí, spousta firemních programů (účto, projekty, docházka, ...) běží v režimu tlustý klient. Tj. aplikace připojující se do db běží na Vašem počítači. Stále máte pocit, že je dobrý nápad aby použila jedno heslo, které může ke všemu?

Napíšu o aplikacích klient–server, kdy uživatel přímo komunikuje s databází. Celou dobu píšu o případu, kdy k databázi může jen aplikační server.

[pht]

Zapomněl jste na druhou část mého dotazy, tedy aby ta chyba neohrozila jiné uživatele.

Nějak úplně nechápu, co chcete vidět?

Předtím jste ale psal, že každá vrstva předpokládá to, že předchozí vrstvu má plně pod kontrolou útočník.

A tudíž?

To ale nebude fungovat v prostředí, které používá sdílená připojení, umožňuje běžet nad různými databázemi, používá sdílené transakce – tohle všechno vám nebude s vaším modelem fungovat jen tak samo od sebe.

A? Bezpečnost není nikdy zadarmo.

To je nějaký jiný Oracle TopLink, než ten, který implementuje JPA, nebo Oracle TopLink umožňuje JPA tak znásilnit, aby se to takhle chovalo, a v dokumentaci to není nikde zmíněno?

Nevím, co tím myslíte, ale TopLink podporuje jak RLS tak proxy autentizaci 1 2 což by Vám mělo stačit.

Jak už jsem psal, pokud AS dovolí vykonávat útočníkův kód, je získaný přístup k databázi pouze jedním z mnoha dílčích problémů.

Není důvod aby šlo do háje všechno, i to co nemusí, pokud vzala za své jedna věc.

Napíšu o aplikacích klient–server, kdy uživatel přímo komunikuje s databází.

Což neznamená že neexistují aplikace, které tento syndrom mají, a že jich je

[Filip Jirsák]

Chci vidět příklad, kdy útočník může v kontextu aplikace spouštět svůj kód, ale jediný problém by byl, pokud by tento kód měl přístup ke sdílenému heslu do databáze. A pokud takové heslo neexistuje, spouštění útočníkova kódu v aplikaci nevadí a klidně to můžu povolit.

Není důvod aby šlo do háje všechno, i to co nemusí, pokud vzala za své jedna věc.

Takže máme klasickou třívrstvou aplikaci databáze – aplikační server – klient. Vy navrhujete veškerou aplikační logiku a zabezpečení přesunout z aplikačního serveru do databáze. Můžu se zeptat, co pak zůstane na aplikačním serveru? Pokud to bude jenom prázdná vrstva, která bude jen přeposílat požadavky a odpovědi sem a tam, může se odstranit, ne?

Což neznamená že neexistují aplikace, které tento syndrom mají, a že jich je

Například mezi webovými aplikacemi, o kterých je celou dobu řeč, jich je přesně nula.

[pht]

Chci vidět příklad, kdy útočník může v kontextu aplikace spouštět svůj kód, ale jediný problém by byl, pokud by tento kód měl přístup ke sdílenému heslu do databáze. A pokud takové heslo neexistuje, spouštění útočníkova kódu v aplikaci nevadí a klidně to můžu povolit.

Já nevím, myslím že jsem tu už navrhnul schema kde každý požadavek na web server poběží v kontextu, který nemůže dělat o mnoho více než je zamýšleno. V takovém případě klidně můžu dát k dispozici input box napojený na eval(). Použití master hesla do db by pak jen podtrhlo jeho nesmyslnost.

Proč se držíte tohoto speciálního případu? I pokud dostanu mnohem širší práva na průměrně zabezpečeném systému, tak použití účtů v db a systému "každý má přístup do svého" bude hrát významnou roli.

Z Vašeho uvažování by plynulo, že pokud zákeřná stránka dostane možnost vykonávat kód v kontextu webového prohlížeče oběti, tak má automaticky administrátorský přístup k celému počítači. Na základě této úvahy byste pak doporučoval lidem spouštět firefox pod rootem.

Můžu se zeptat, co pak zůstane na aplikačním serveru?

To co tam je teď. Klikátka, generování tabulek, grafů, posílání mejlů, a dalších tisíc píčovin, kvůli kterým jste si ten aplikační systém objednal. Ne každej je tak ostřílenej aby na Alze objednával pomocí "INSERT INTO objednavky" ...

Například mezi webovými aplikacemi, o kterých je celou dobu řeč, jich je přesně nula.

Asi jste spíš chtěl říct, že webových aplikací, které by používaly nativní databázovou bezpečnost je nula.

Jednak se nebavím jen o webových aplikacích, ale o obecném principu, ze kterého můžou webové aplikace těžit.

A jednak je určitě všechny znáte do detailů, abyste to mohl tvrdit. A patrně nikdo nepotřebuje všechny ty věci, které se vyvinuly ve prospěch tohoto schematu. Můžeme u toho zůstat, jestli chcete.

[Filip Jirsák]

Já nevím, myslím že jsem tu už navrhnul schema kde každý požadavek na web server poběží v kontextu, který nemůže dělat o mnoho více než je zamýšleno.

To, že může spouštět systémové příkazy pod účtem, pod kterým běží webový server, a tedy třeba číst všechny skripty na serveru, to vám připadá málo?

To co tam je teď. Klikátka, generování tabulek, grafů, posílání mejlů, a dalších tisíc píčovin, kvůli kterým jste si ten aplikační systém objednal. Ne každej je tak ostřílenej aby na Alze objednával pomocí "INSERT INTO objednavky" ...

Podle vaší logiky ale posílání e-mailů a generování tabulek a grafů patří do databáze, a klikátka na klienta. Mně by zajímalo, co zůstane uprostřed – vy jste totiž z třívrstvé aplikace udělal zpátky dvouvrstvou. Já se jen ptám, zda opravdu to přidání třetí vrstvy je tak hloupý nápad, jak se tady celou dobu snažíte tvrdit.

Asi jste spíš chtěl říct, že webových aplikací, které by používaly nativní databázovou bezpečnost je nula.

Ne, nechtěl. Chtěl jsem napsat opravdu to, že klient–server webové aplikace se nepoužívají – i když je jenom otázka času, kdy při současném AJAXovém šílenství někoho napadne, že by prohlížeč rovnou mohl posílat SQL dotazy do databáze a databáze by odpovídala rovnou XML, pak byste opravdu dostal webovou klient–server aplikaci.

[pht]

To, že může spouštět systémové příkazy pod účtem, pod kterým běží webový server, a tedy třeba číst všechny skripty na serveru, to vám připadá málo?

Jde to nastavit tak, že nemůže. A i kdyby mohl, tak si tím k databázi nepomůže.

Podle vaší logiky ale posílání e-mailů a generování tabulek a grafů patří do databáze, a klikátka na klienta.

A proč to?

Já se jen ptám, zda opravdu to přidání třetí vrstvy je tak hloupý nápad, jak se tady celou dobu snažíte tvrdit.

Skutečně to tvrdím?

klient–server webové aplikace

Vždyť web sám je klient-server :)

[Filip Jirsák]

Jde to nastavit tak, že nemůže.

Aha, takže webserver zpracuje příchozí požadavek, vytáhne si z něj přihlašovací údaje, ty nechá ověřit databázi, pak se na základě nich přepne (su) na daného systémového uživatele (tj. uživatel e-shopu je zároveň uživatel v databázi i systémový uživatel). A to všechno s PHP a MySQL.

A i kdyby mohl, tak si tím k databázi nepomůže.

Opravdu? Jste si jist, že když může útočník spustit kód v rámci aplikačního serveru, nemůže třeba číst a zapisovat na libovolné místo paměti daného procesu, nebo dokonce všech procesů patřících uživateli? A pokud může, jak mu zabráníte, aby ukradl spojení jiného uživatele do databáze?

Stavíte zabezpečení úplně na hlavu. Samozřejmě je nesrovnatelně jednodušší zabezpečit webovou aplikaci na straně ke klientovi, než pustit útočníka na server a pak se snažit něco dělat s tím, když může útočník na aplikačním serveru spouštět libovolný kód. Zkuste si aspoň porovnat četnost bezpečnostních problémů, kdy lze roota získat vzdáleně, a kdy to lze udělat lokálně.

A proč to?

Protože to je aplikační logika chráněná přístupovými právy. Nebo snad zákazník e-shopu má mít právo posílat e-maily komukoli?

Skutečně to tvrdím?

Ano, tvrdíte. Na aplikačním serveru je normálně aplikační (a bezpečnostní) logika. Vy to chcete přesunout do databáze, takže vám na aplikačním serveru nezbyde nic.

Vždyť web sám je klient-server :)

Nějak se vám tam vytratila databáze, ne? S vaším přístupem klidně můžete prohlásit, že web je samostatná aplikace, která je jen vevnitř rozdělená na webový server, databázi a prohlížeč.

[pht]

Aha, takže webserver zpracuje příchozí požadavek, vytáhne si z něj přihlašovací údaje, ty nechá ověřit databázi, pak se na základě nich přepne (su) na daného systémového uživatele (tj. uživatel e-shopu je zároveň uživatel v databázi i systémový uživatel). A to všechno s PHP a MySQL.

Zhruba tak nějak.

Opravdu? Jste si jist, že když může útočník spustit kód v rámci aplikačního serveru, nemůže třeba číst a zapisovat na libovolné místo paměti daného procesu, nebo dokonce všech procesů patřících uživateli? A pokud může, jak mu zabráníte, aby ukradl spojení jiného uživatele do databáze?

Dá se to tak nastavit, a i kdyby to tak nastaveno nebylo, tak musíte počkat, až se ten druhý přihlásí, což je dost jiná situace, než když do půl hodiny stáhnete obsah db a konec. (Už jsme to probírali výše.)

Stavíte zabezpečení úplně na hlavu.

Jistě.

Samozřejmě je nesrovnatelně jednodušší zabezpečit webovou aplikaci na straně ke klientovi, než pustit útočníka na server a pak se snažit něco dělat s tím, když může útočník na aplikačním serveru spouštět libovolný kód. Zkuste si aspoň porovnat četnost bezpečnostních problémů, kdy lze roota získat vzdáleně, a kdy to lze udělat lokálně.

Na útoky tohoto typu nepotřebujete roota. A že je něco složitější a něco jednodušší neznamená že se na jedno z toho musíme vykašlat. Jak jsem říkal, správná aplikace je zabezpečena odzhora dolů. Není to tak, že když mám bezpečný back-end tak na webovém serveru rozdávám privilegované účty kolemjdoucím.

Protože to je aplikační logika chráněná přístupovými právy. Nebo snad zákazník e-shopu má mít právo posílat e-maily komukoli?

E-maily a jejich bezpečnost snad řeší e-mailový server?

Na aplikačním serveru je normálně aplikační (a bezpečnostní) logika. Vy to chcete přesunout do databáze, takže vám na aplikačním serveru nezbyde nic.

Jediné co chci, je posunout kontrolu přístupových práv o úroveň níž.

Kód typu

if (muze_odeslat_objednavku(current_user)) {
    try {
        odesli_objednavku;
    } catch chyba {
        vypis_chybu(chyba);
    }
} else {
    vypis_chybu("nedostatecna opravneni");
}

se změní na

try {
    odesli_objednavku;
} catch chyba {
    vypis_chybu(chyba);
}

Zbytek "aplikační logiky" zůstane tak jak je.

[Filip Jirsák]

Zhruba tak nějak.

Otázka je, jestli to někdy někdo do Apache, PHP a MySQL implementuje. Zatím se všichni snaží docílit naopak toho, aby nikdo svůj libovolný kód v kontextu aplikačního serveru nebo databáze provádět nemohl.

Dá se to tak nastavit, a i kdyby to tak nastaveno nebylo, tak musíte počkat, až se ten druhý přihlásí, což je dost jiná situace, než když do půl hodiny stáhnete obsah db a konec.

Jaký „ten druhý“? Prostě se dostanu k datům všech, kteří jsou zrovna připojeni. To je málo?

Na útoky tohoto typu nepotřebujete roota.

Nepotřebujete. Jen jsem podotknul, že vy si v rámci vyšší bezpečnosti pouštíte uživatele do lokálního počítače, odkud může mimo jiné daleko snáz roota získat.

A že je něco složitější a něco jednodušší neznamená že se na jedno z toho musíme vykašlat. Jak jsem říkal, správná aplikace je zabezpečena odzhora dolů. Není to tak, že když mám bezpečný back-end tak na webovém serveru rozdávám privilegované účty kolemjdoucím.

Můj způsob zabezpečení je, že např. aplikační server zabezpečím proti spouštění libovolného kódu a libovolných SQL dotazů, a u databáze už pak mohu předpokládat, že na ni jdou jenom „prověřené“ dotazy. Váš přístup je, že uděláte x nezabezpečených vrstev a všechno pak zabezpečujete až na nejnižší úrovni (kde už spoustu věcí zabezpečit nedokážete, protože je to nesrovnatelně složitější).

Já jsem nepsal nic o rozdávání privilegovaných účtů kolemjdoucím – zabezpečit webovou aplikaci tak, aby z ní nebylo možné spouštět útočníkův kód ani libovolné dotazy je triviální.

E-maily a jejich bezpečnost snad řeší e-mailový server?

Cože? Pokud např. v e-shopu chcete odeslat rekapitulaci objednávky, ve vašem případě to chcete udělat z kontextu uživatele, ne? Přece nechcete, aby uživatelův e-mail mohl číst někdo jiný, než uživatel sám.

Jediné co chci, je posunout kontrolu přístupových práv o úroveň níž. … Zbytek "aplikační logiky" zůstane tak jak je.

Takže třeba v tom e-shopu povolíte uživateli libovolně manipulovat s počtem položek na skladě (aby mohl přesunout položku ze skladu do košíku), nebo budete mít aplikační logiku i v databázi (která např. bude kontrolovat, zda uživatel mění stav položek na skladě povoleným způsobem)? Pokud zvolíte první způsob, je sice hezké, že uživatele k některým datům nepustíte, jenže zabezpečení nemá jenom tři stavy nesmí nic – může číst – může měnit, ale může mít i spoustu dalších variant, které závisejí na aplikační logice (třeba že uživatel může věci ze skladu dávat jen do svého košíku a zpět).

[pht]

Otázka je, jestli to někdy někdo do Apache, PHP a MySQL implementuje. Zatím se všichni snaží docílit naopak toho, aby nikdo svůj libovolný kód v kontextu aplikačního serveru nebo databáze provádět nemohl.

Ano, je to tam naimplementováno. Všichni se snažit můžou, to ničemu nevadí.

Jaký „ten druhý“? Prostě se dostanu k datům všech, kteří jsou zrovna připojeni. To je málo?

Záleží na tom, kdo je připojen Ale obvykle se tohle dá eliminovat právě tím, že kompromitované vlákno nebude mít možnost ptrace()ovat ostatní vlákna.

Nepotřebujete. Jen jsem podotknul, že vy si v rámci vyšší bezpečnosti pouštíte uživatele do lokálního počítače, odkud může mimo jiné daleko snáz roota získat.

Pouštím ho tam stejně tak jako Vy. Akorát že tomu uživateli dám míň práv než Vy. A když to chci mít odolné proti root kompromisu, tak dám databázi na jiný server.

Můj způsob zabezpečení je, že např. aplikační server zabezpečím proti spouštění libovolného kódu a libovolných SQL dotazů, a u databáze už pak mohu předpokládat, že na ni jdou jenom „prověřené“ dotazy.

To já dělám taky, až na ten předpoklad. Já zabezpečuju SQL dotazy stejně jako Vy, jen navíc předpokládám, že i tak se může útočníkovi podařit to prvotní zabezpečení nějak obejít a bráním se i proti tomu. Váš model je hrad s bránou, ale uvnitř jsou už všechny dveře odemčené a poklad se válí někde na stole, můj model je hrad s toutéž bránou a zamčenými komnatami, a uvnitř zamčenou truhlou.

uděláte x nezabezpečených vrstev a všechno pak zabezpečujete až na nejnižší úrovni

Ne, takhle to není, viz výše.

zabezpečit webovou aplikaci tak, aby z ní nebylo možné spouštět útočníkův kód ani libovolné dotazy je triviální

Nemyslím si, že by bezpečnost čehokoliv byla triviální.

Pokud např. v e-shopu chcete odeslat rekapitulaci objednávky, ve vašem případě to chcete udělat z kontextu uživatele, ne? Přece nechcete, aby uživatelův e-mail mohl číst někdo jiný, než uživatel sám.

To ňák nechápu, tak prostě aplikační server pošle mail (přes SMTP nebo rouru do sendmailu). To, jestli ten mail někomu přijde, řeší MTA. Je to stejný způsob přesunu zabezpečení jako při přístupu k DB. Kdyby filtrování mailů řešila aplikace sama, tak její kompromitací získám neomezenou možnost spammovat; když to řeší až mail server, tak si nepomůžu.

Takže třeba v tom e-shopu povolíte uživateli libovolně manipulovat s počtem položek na skladě (aby mohl přesunout položku ze skladu do košíku), nebo budete mít aplikační logiku i v databázi (která např. bude kontrolovat, zda uživatel mění stav položek na skladě povoleným způsobem)?

To je dost fatální chyba - sklad se nemůže měnit v závislosti na košíku uživatelů (tím bych Vám vyprázdnil sklad), ale v závislosti na expedici. Uživatel skladník vezme zboží ze skladu a dá ho do balíku, zároveň změní údaj v databázi (nebo to za něj udělá čtečka čárových kódů).

[Filip Jirsák]

Ano, je to tam naimplementováno.

Příklad konfigurace nebo odkaz do dokumentace by nebyl?

Záleží na tom, kdo je připojen Ale obvykle se tohle dá eliminovat právě tím, že kompromitované vlákno nebude mít možnost ptrace()ovat ostatní vlákna.

Předpokládám, že vlákny myslíte procesy, které mají různé uživatele. Pořád mi ale připadá daleko jednodušší zabezpečit aplikaci tak, aby v jejím rámci útočník nemohl spouštět svůj kód, než zabezpečovat počítač tak, aby si tam kdokoli mohl pouštět libovolný kód a nic se nestalo.

Pouštím ho tam stejně tak jako Vy. Akorát že tomu uživateli dám míň práv než Vy.

Já uživateli webové aplikace neumožňuju spouštět libovolný kód na aplikačním serveru.

A když to chci mít odolné proti root kompromisu, tak dám databázi na jiný server.

To si hodně pomůžete. Pokud bude mít útočník roota na webovém serveru, jak mu zabráníte, aby sledoval a měnil spojení uživatelů do databáze?

To já dělám taky, až na ten předpoklad. Já zabezpečuju SQL dotazy stejně jako Vy, jen navíc předpokládám, že i tak se může útočníkovi podařit to prvotní zabezpečení nějak obejít a bráním se i proti tomu. Váš model je hrad s bránou, ale uvnitř jsou už všechny dveře odemčené a poklad se válí někde na stole, můj model je hrad s toutéž bránou a zamčenými komnatami, a uvnitř zamčenou truhlou.

Nezabezpečujete stejně. Váš model je hrad s pootevřenou bránou a pokladem za závěsem – a doufáte, že když útočník dokáže najít otevřenou bránu, už nedokáže najít poklad za závěsem. A jiný útočník, který by dokázal najít poklad, zase nenajde otevřenou bránu.

Podívejte se na to třeba takhle – máte 50 tisíc Kč na zvýšení bezpečnosti toho hradu. Investujete je raději do pořádného zámku na bránu, nebo je rozdrobíte a nakoupíte obyčejný zámek na bránu, příruční trezůrek a další kopu jednoduchých bezpečnostních prvků? Pořád zapomínáte na to, že u bezpečnosti se deset slabých prvků za sebou nerovná jednomu silnému prvku, ale jednomu slabému prvku.

Nemyslím si, že by bezpečnost čehokoliv byla triviální.

Často je to triviální, a abyste někde vyrobil bezpečnostní díru, musíte udělat dost velkou botu. Třeba možnost spouštět na web serveru útočníkův kód musíte do PHP nebo Java aplikace (poměrně pracně) naprogramovat. Nenaprogramovat tam takovou funkcionalitu je opravdu triviální.

To ňák nechápu, tak prostě aplikační server pošle mail (přes SMTP nebo rouru do sendmailu). To, jestli ten mail někomu přijde, řeší MTA. Je to stejný způsob přesunu zabezpečení jako při přístupu k DB. Kdyby filtrování mailů řešila aplikace sama, tak její kompromitací získám neomezenou možnost spammovat; když to řeší až mail server, tak si nepomůžu.

Problém je v tom, že aplikace ví, co je regulérní e-mail a co ne, ale mail server to neví.

To je dost fatální chyba - sklad se nemůže měnit v závislosti na košíku uživatelů (tím bych Vám vyprázdnil sklad), ale v závislosti na expedici. Uživatel skladník vezme zboží ze skladu a dá ho do balíku, zároveň změní údaj v databázi (nebo to za něj udělá čtečka čárových kódů).

Je úplně jedno, zda je to zrovna košík a sklad nebo nějaká jiná kombinace. Prostě přidáním do košíku nebo potvrzením objednávky by se mělo snížit množství, které je ihned k dispozici ostatním (pokud mám na skladě jediný výrobek, není zrovna rozumné to inzerovat několik dní, než dojde ke skutečné expedici). Uživatel by měl mít možnost jen přesouvat mezi košíkem a tímto místem, neměl by mít možnost tento stav aktualizovat nezávisle (tak, že ostatním uživatelům poskytne informaci, že na skladě není nic, nebo naopak že je tam tisíc výrobků, když ve skutečnosti mám jen jeden). A k tomu už potřebujete aplikační logiku.

[pht]

Příklad konfigurace nebo odkaz do dokumentace by nebyl?

Pro apache můžete od dávných dob použít suEXEC, nebo obdobný princip. Ten ale není kompatibilní s built-in skriptováním (PHP), musíte použít tradiční CGI. Modernější přístup je Apache/SELinux plus, který jednak funguje s built-in a jednak je flexibilnější. Pokud místo MySQL použijete sepostgres, budete mít nativní SELinuxovou kontrolu přístupových práv, pokud použijete MySQL, budete muset udělat nějakej bazmek, kterej bude alespoň mapovat kontexty na uživatele. Podobný přístup poskytuje Oracle ve svém aplikačním portfoliu.

Já uživateli webové aplikace neumožňuju spouštět libovolný kód na aplikačním serveru.

Tohle je dobrý kandidát na "slavná poslední slova". Myslíte snad, že tvůrci produktů, které obsahovaly bezpečnostní chyby, to dělali schválně?

Pokud bude mít útočník roota na webovém serveru, jak mu zabráníte, aby sledoval a měnil spojení uživatelů do databáze?

Nijak, ale zabráním mu ve zkopírování databáze. Pokud budu chtít ošetřit bezpečnost každého probíhajícího spojení, tak použiju nezávislou autorizaci každé akce, viz výše.

Podívejte se na to třeba takhle – máte 50 tisíc Kč na zvýšení bezpečnosti toho hradu. Investujete je raději do pořádného zámku na bránu, nebo je rozdrobíte a nakoupíte obyčejný zámek na bránu, příruční trezůrek a další kopu jednoduchých bezpečnostních prvků?

Budu je investovat do takového opatření, aby jeho překonání stálo podstatně více než 50000, tj. aby se jeho zavedení vyplatilo. Kde to bude, je otázka konkrétní aplikace. Může se nakonec ukázat že kvůli škodě 50000 bude lepší použít out of the box produkty a spíše proškolit personál

Dejme tomu že se rozhodování zredukuje na výše uvedený případ. Pokud je zabezpečení truhly a brány stejným zámkem, zabezpečím truhlu a nechám otevřenou bránu. K otevření brány bude totiž mít přístup personál který nemusí nutně pracovat s pokladem v truhle.

Pokud bych utratil 2x tolik peněz a zabezpečil i bránu, nezískám žádnou výhodu. Útočník s paklíčem na bránu se dostane i do truhly s marginálním úsilím navíc.

V realitě ale je to jinak. Zabezpečení různých vrstev je různé. Mám na výběr:

- Zámek na bránu s 1% pravděpodobností průniku za 50000.

- Zámek na bránu s 5% pst. průniku za 25000.

(dtto na truhlu).

Pokud jsou tyto zámky různé, vyplatí se koupit 2 levnější varianty. Výsledná pst. pro průnik oběma bude 0.25%. I kdyby levnější zámek měl 10%, a výsledek u obou byl 1%, stejně se vyplatí 2 zámky, protože můžete průnik bránou odhalit, ještě než je útočník u truhly.

Pořád zapomínáte na to, že u bezpečnosti se deset slabých prvků za sebou nerovná jednomu silnému prvku, ale jednomu slabému prvku.

Tohle ale platí i na ten Váš model, kde je bezpečnost na nižší vrstvě nulová.

Třeba možnost spouštět na web serveru útočníkův kód musíte do PHP nebo Java aplikace (poměrně pracně) naprogramovat. Nenaprogramovat tam takovou funkcionalitu je opravdu triviální.

Samozřejmě pokud nenaprogramujete vůbec nic, tak nebude s bezpečností problém. Ale v realitě musíte vyhovět požadavkům na produkt. Požadavky a zabezpečení jsou na kolizním kurzu. Historie je plná příkladů, kdy se nějaká dobře míněná funkcionalita otočí proti bezpečnosti. Je lepší implementovat funkcionalitu na dobře zabezpečeném základě, aby případná chyba neměla fatální následky, a stačilo ji opravit v dalším release a ne v hotfixu.

Problém je v tom, že aplikace ví, co je regulérní e-mail a co ne, ale mail server to neví.

Já zas nevím, o čem mluvíte, dejte mi nějaký příklad.

Je úplně jedno, zda je to zrovna košík a sklad nebo nějaká jiná kombinace. Prostě přidáním do košíku nebo potvrzením objednávky by se mělo snížit množství, které je ihned k dispozici ostatním (pokud mám na skladě jediný výrobek, není zrovna rozumné to inzerovat několik dní, než dojde ke skutečné expedici).

OK, takže mluvíte o tom, že implementujete zabezpečení neatomické operace. Např. snížit jedno číslo a zvýšit jiné (o ten samý počet) Máte možnosti:

1. povolit web aplikaci kompletní přístup k tabulkám pod jedním uživatelem (Váš přístup) a nechat "AL" aby to vyřešila - pokud se AL zblázní, budete mít totální fuck up. navíc budete mít problémy s koukáním do cizích košíků atd.

2. mít uživatele e-shopu na úrovni db a povolit jim přístup k tabulkám - pokud se AL jednoho uživatele zblázní, dojde k omezené škodě. budete jednou za hodinu kontrolovat konzistenci tabulek a případně můžete dohledat a rollbacknout špatné transakce. budete mít zabudovanou separaci košíků na úrovni db.

3. dtto jako 2. ale skrouhnete práva na zvyšovat 1. číslo a snižovat 2. číslo. podobné jako výše, bude záležet na konkrétní situaci, zda toto přinese další bezpečnost. u košíku pravděpodobně ne, u hypotéky pravděpodobně ano.

4. nepovolíte přímý přístup k tabulkám, ale jen k proceduře, která atomicky (z vnějšího pohledu) provede danou operaci - přesunete problém na nižší vrstvu a můžete začít znova od bodu 1 s tím že AL=procedura. tohle se vyplatí dělat pokud potřebujete mít zajištěnou realtime konzistenci na úrovni db.

Všimněte si že přechod od bodu 1 k bodu 2 přináší razantní zlepšení za poměrně malé oběti.

Spokojen?

[Filip Jirsák]

Pro apache můžete od dávných dob použít suEXEC, nebo obdobný princip.

Jenže ten nastavuje systémového uživatele podle aplikace, ne podle uživatele přihlášeného přes web.

Tohle je dobrý kandidát na "slavná poslední slova". Myslíte snad, že tvůrci produktů, které obsahovaly bezpečnostní chyby, to dělali schválně?

Ono se dá eval(), include() nebo skládání SQL dotazu udělat omylem?

Nijak, ale zabráním mu ve zkopírování databáze. Pokud budu chtít ošetřit bezpečnost každého probíhajícího spojení, tak použiju nezávislou autorizaci každé akce, viz výše.

Tohle podezření jsem měl delší dobu, že jste se upnul jen na kopírování celé databáze, a nic jiného (třeba okopírování po částech) vás nezajímá.

Tohle ale platí i na ten Váš model, kde je bezpečnost na nižší vrstvě nulová.

Ano. Akorát že v mém případě je pravděpodobnost průniku přes nejslabší místo 0,01 %, ve vašem 1 %. Ale hlavně že máte některé způsoby průniku ošetřené i na 0,0001 %…

Samozřejmě pokud nenaprogramujete vůbec nic, tak nebude s bezpečností problém. Ale v realitě musíte vyhovět požadavkům na produkt. Požadavky a zabezpečení jsou na kolizním kurzu. Historie je plná příkladů, kdy se nějaká dobře míněná funkcionalita otočí proti bezpečnosti. Je lepší implementovat funkcionalitu na dobře zabezpečeném základě, aby případná chyba neměla fatální následky, a stačilo ji opravit v dalším release a ne v hotfixu.

Ovšem rozdíly v implementaci té nové funkcionality jsou dva – v aplikačním serveru ji naprogramujete snáz než v databázi (takže je menší pravděpodobnost chyby), snáz to taky implementujete jednou na jednom místě, než když to musíte implementovat v aplikační logice a pak ještě jednou v nějaké logice, která jednou za hodinu kontroluje konzistenci databáze.

Dobře zabezpečený základ můžete mít jak v databázi, tak v aplikačním serveru. Ale v aplikačním serveru může být za stejnou cenu mnohem bohatší, takže pak budete mít mnohem menší potřebu dělat do toho základu nějakou díru kvůli „dobře míněné funkcionalitě“.

Já zas nevím, o čem mluvíte, dejte mi nějaký příklad.

Zákazník právě dokončil objednávku, takže aplikace ví, že v tomto okamžiku mu má poslat právě jednu rekapitulaci objednávky. Mail server o tom neví nic, takže těžko může rozhodovat o tom, jestli e-mail zákazníkovi, který právě dostal k doručení, je regulérní mail, nebo jestli je to spam.

Všimněte si že přechod od bodu 1 k bodu 2 přináší razantní zlepšení za poměrně malé oběti.

Podle mne přechod od bodu 1 k bodu 2 přináší akorát razantní zvýšení pravděpodobnosti, že někde něco přestane fungovat.

Podle vás nutnost programovat extra nějakou kontrolu konzistence, spouštět jí (opět další nutná práva navíc, další možnost chyby), umět nějak rozumně zareagovat na chybu – to je podle vás malá oběť? Nebylo by jednodušší naprogramovat správně tu původní logiku, která má zabezpečit onu atomickou operaci?

Nevím, kde pořád berete tu víru, že aplikační logika bude chybná, ale kontrolní kód nebo kód v databázi bude bezchybný. Právě naopak – čím víc kódu, tím větší pravděpodobnost, že v něm budou chyby.

[pht]

Ono se dá eval(), include() nebo skládání SQL dotazu udělat omylem?

Tak nevím, jak se ty chyby do aplikací dostávájí? Viz třeba drupal security, myslíte že to tam ty lidi dávají schválně? Nebo to tam doprogramovávají zlí ufouni pod rouškou tmy?

"The ... module does not correctly handle ... Users ... can insert arbitrary HTML and script code ... may lead to the malicious user gaining administrative access."

Jak by se důsledek té chyby změnil, pokud by se používala bezpečnost na úrovni db?

Tohle podezření jsem měl delší dobu, že jste se upnul jen na kopírování celé databáze, a nic jiného (třeba okopírování po částech) vás nezajímá.

Jestli si myslíte, že jsem se na něco upnul, tak mi dejte nějaký scénář k vyřešení.

Akorát že v mém případě je pravděpodobnost průniku přes nejslabší místo 0,01 %

Ve Vašem případě je nejslabší místo ta databáze, kde je možno libovolně operovat, jakmile se k ní dostanu, takže pst. průniku uvnitř db je 100%. A 1*x=x takže ve výsledku celá bezpečnost závisí jen na jednom článku a to je pst. průniku skrze web aplikaci. Pokud je 0,01% tak tam jste skončil. Pokud za tu samou aplikaci přidám ještě bezpečnost databáze s dalšími 0,01%, tak na tom budu vzhledem k bezpečí dat podstatně lépe. Pokud mi sama databáze bude zaručovat 0,0001% tak začnu polemizovat, zda mi těch prvních 0,01% stojí za námahu.

Ale v aplikačním serveru může být za stejnou cenu mnohem bohatší

To si nemyslím, protože db už přichází se zabudovanými věcmi jako je GRANT, zatímco v AS budete stavět na zelené pláni.

Zákazník právě dokončil objednávku, takže aplikace ví, že v tomto okamžiku mu má poslat právě jednu rekapitulaci objednávky. Mail server o tom neví nic, takže těžko může rozhodovat o tom, jestli e-mail zákazníkovi, který právě dostal k doručení, je regulérní mail, nebo jestli je to spam.

To je pravda a dál? Jaké je tu bezpečnostní riziko a co vlastně za bezpečnost řešíte vzhledem k mailu v tom AS?

Podle vás nutnost programovat extra nějakou kontrolu konzistence, spouštět jí (opět další nutná práva navíc, další možnost chyby), umět nějak rozumně zareagovat na chybu – to je podle vás malá oběť? Nebylo by jednodušší naprogramovat správně tu původní logiku, která má zabezpečit onu atomickou operaci?

Nějak jsem doufal, že když napíšete něco o čem tvrdíte že to je správně, tak budete mít v ruce něco víc než svůj slib, tj. že ten kontrolní kód tak nějak vzniká za pochodu. Budete ho potřebovat v případě 1, 2, 3 i 4. Pokud ho nemáte, tak nemáte jak zjistit, že je něco špatně. To je nejlepší cesta do průseru. Kontroly na stav zásob vůči objednávkám se dělají od nepaměti, už jen proto, aby si zaměstnanci všechno nevzali domů.

Takže gró bodu 2 opravdu není v tom, že byste musel najednou sepisovat kontrolní program. Spíš naopak. Databázový záznam a odlišitelnost uživatelů Vám dá do ruky nástroje na vyšetření a ošetření abnormálních stavů.

[Filip Jirsák]

Tak nevím, jak se ty chyby do aplikací dostávájí? Viz třeba drupal security, myslíte že to tam ty lidi dávají schválně? Nebo to tam doprogramovávají zlí ufouni pod rouškou tmy?

Já si myslím, že to tam programátoři dávají schválně s tím, že si myslí, že to napíšou správně. Stejně jako by si mysleli, že napíšou správně tu logiku v databázi. Jenže zatímco vyvarovat se těchto chyb je snadné – stačí si dobře rozmyslet každé použití uživatelem zadané hodnoty a vyhnout se známým věcem jako includování neznámého zdroje, skládání SQL dotazů nebo výpis uživatelského vstupu přímo do stránky, když povolíte útočníkovi spouštět jeho kód v kontextu aplikace, je toho na ohlídání najednou strašně moc.

Jak by se důsledek té chyby změnil, pokud by se používala bezpečnost na úrovni db?

Pokud by došlo jenom k téhle změně (tj. najednou by se někde vyčaroval čas na to dodělat k stávající aplikaci tu bezpečnost přes DB), nedošlo by ke zhoršení bezpečnosti. Zda by zůstala stejná nebo by se bezpečnost zvýšila, to neví nikdo.

Jestli si myslíte, že jsem se na něco upnul, tak mi dejte nějaký scénář k vyřešení.

Dal jsem vám jich několik. Vždy jsem se dozvěděl – to nevadí, že může útočník jiného uživatele zaplavit e-maily, hlavně že nezíská celou databázi e-mailů. Nevadí, že útočník může měnit stav skladu, hlavně, že nezíská celou databázi.

Ve Vašem případě je nejslabší místo ta databáze, kde je možno libovolně operovat, jakmile se k ní dostanu

No právě, jakmile se k ní dostanete. Jenže v mém případě se věnuje úsilí tomu, aby se k ní útočník nedostal, ve vašem případě se počítá s tím, že se k ní útočník dostal – takže věnovat nějaké úsilí tomu, aby se k ní nedostal, je zbytečné, tudíž pravděpodobnost průniku k databázi je 1.

Pokud za tu samou aplikaci přidám ještě bezpečnost databáze s dalšími 0,01%, tak na tom budu vzhledem k bezpečí dat podstatně lépe.

No jo, ale to jste k současné aplikaci přidal další zabezpečení, tedy jsou to dodatečné náklady. Pokud má někdo neomezený rozpočet, může si samozřejmě dělat zabezpečení na padesáti vrstvách. Jenže v reálném světě je rozpočet zpravidla konečný, takže si můžete vybrat, jestli dobře zabezpečit webovou aplikaci a databázi mít „nechráněnou“, nebo jestli trochu zabezpečit webovou aplikaci a trochu databázi.

To si nemyslím, protože db už přichází se zabudovanými věcmi jako je GRANT, zatímco v AS budete stavět na zelené pláni.

Infrastruktura pro zabezpečení je hotová jak v databázi, tak v aplikačním serveru, v tom rozdíl není. Takže jde o to, jakým způsobem se využije – a jak to zatím popisujete, využití v aplikačním serveru je mnohem snazší (tedy méně náchylné na chybu).

To je pravda a dál? Jaké je tu bezpečnostní riziko a co vlastně za bezpečnost řešíte vzhledem k mailu v tom AS?

Řešíme to, že zatímco aplikační server s plným přístupem k databázi normálně funguje a posílá e-maily jen tehdy, když má, váš server se zabezpečením v databázi spamuje (minimálně) přihlášené uživatele, a možná je na něj taky veden DoS útok z lokálního počítače (čímž se za chvíli vyřeší problém s přihlášenými uživateli, kteří za chvíli nebudou).

Nějak jsem doufal, že když napíšete něco o čem tvrdíte že to je správně, tak budete mít v ruce něco víc než svůj slib, tj. že ten kontrolní kód tak nějak vzniká za pochodu.

Ten kontrolní kód těžko může vznikat za pochodu, když dělá úplně něco jiného, než ten běžný aplikační kód.

Budete ho potřebovat v případě 1, 2, 3 i 4. Pokud ho nemáte, tak nemáte jak zjistit, že je něco špatně.

Ne, nebudu. Že je něco špatně budu zjišťovat tam, kde mám podezření, že něco může být špatně – rozhodně nebudu kontrolovat vše, protože úplný seznam všech kontrol se ani nedá udělat.

Kontroly na stav zásob vůči objednávkám se dělají od nepaměti, už jen proto, aby si zaměstnanci všechno nevzali domů.

To si pletete s inventurou, a ta se dělá fyzicky, takže ji těžko můžete provádět každou hodinu. Kontrolu na stav zásob v DB nemusím provádět, když vím, že všechny části manipulující se stavem zásob fungují správně. Kontrolovat to stejně můžete jedině tak, že ten k bude napsaný dvakrát od dvou různých týmů, a bude se porovnávat výsledek operací – ale to se dělá třeba u zabezpečovací techniky, ale ne u e-shopu.

Takže gró bodu 2 opravdu není v tom, že byste musel najednou sepisovat kontrolní program. Spíš naopak. Databázový záznam a odlišitelnost uživatelů Vám dá do ruky nástroje na vyšetření a ošetření abnormálních stavů.

Nedá. Ta vaše kontrola by vám složitou cestou odhalila problém, pokud by nefungoval přenos ze skladu do košíku a zpět. Ale už vám neodhalí chybu v naskladňování nebo v tom, že se vám budou věci z košíku ztrácet. Takže ta vaše složitá kontrola každou hodinu bude kontrolovat jenom to, jestli je správně napsaná jedna aplikační metoda. To jde ale snáz a s větším efektem kontrolovat už při vývoji, třeba pomocí jednotkových a integračních testů.

[pht]

stačí si dobře rozmyslet každé použití uživatelem zadané hodnoty a vyhnout se známým věcem

...

Největší chyba kterou můžete udělat je, že si myslíte že něco stačí a pak už to bude dobrý. Ono to tak může vypadat když stojíte na začátku cesty, myslíte si, že to uděláte dobře a všechno si ohlídáte, jenže pak přijdou složité věci, narychlo dělané úpravy, delegace činnosti jiným a kdoví co ještě a najednou máte produkt plný chyb, z nichž nějaká část budou chyby v zabezpečení. Autor drupalu a možná i autoři těch chybných doplňků jsou si určitě vědomi základních principů, ale i přes to se stále objevují nové a nové záplaty.

Jenom blázen, který neví co dělá dá na stůl produkt a řekne, že je 100% bezpečný. Předpokládat že něco funguje dobře a bezchybně jenom podněcuje ledabylost v používání.

U zabezpečení se rozlišuje několik úrovní: odpuzení, ochrana, detekce průniku a omezení škod. Co se tu snažíte říci, je, že dáváte všechny svoje síly na první dva stupně, v naději že se nebudete muset zabývat tím zbytkem. Co říkám já je, že to je metodicky špatně a musíte se zabývat celým problémem, ne jen jeho polovinou. Je mi úplně jedno, jaké nástroje k tomu použijete (jen jsem jeden doporučil), hlavně když to splní svou funkci.

Neomezený rozpočet nebudete mít nikdy a vždycky budete muset vážit co naimplementujete, to se týká nejen bezpečnosti ale i funkčnosti. Ale mohl byste to udělat líp, než většina firem které se ženou za úspěchem, tj. a nejdřív nakódujou všechny možné tintítka a až teprve když internet zaplaví masa útoků na jejich produkt tak se začnou věnovat zabezpečení.

Více se mi k tomuto tématu psát nechce. Pokud to někdo dočetl až sem, doufám že si vzal poučení (jakékoliv).

[Filip Jirsák]

Největší chyba kterou můžete udělat je, že si myslíte že něco stačí a pak už to bude dobrý. Ono to tak může vypadat když stojíte na začátku cesty, myslíte si, že to uděláte dobře a všechno si ohlídáte, jenže pak přijdou složité věci, narychlo dělané úpravy, delegace činnosti jiným a kdoví co ještě a najednou máte produkt plný chyb, z nichž nějaká část budou chyby v zabezpečení. Autor drupalu a možná i autoři těch chybných doplňků jsou si určitě vědomi základních principů, ale i přes to se stále objevují nové a nové záplaty.

Což platí stejně obou případů, ať to budete dělat v databázi nebo v nějakém vyšším programovacím jazyce. Rozdíl je v tom, že pro vyšší programovací jazyky máte mnohem více již hotových knihoven, mnohem víc možností a nástrojů k ladění a testování. A vyhnout se spouštění cizího kódu nebo SQL injection je opravdu snadné.

Předpokládat že něco funguje dobře a bezchybně jenom podněcuje ledabylost v používání.

To předpokládáte pouze vy u databáze. Já nepředpokládám, že aplikace funguje bezchybně – ale veškeré síly napřu na to, aby tak fungovala. Přijde mi to lepší, než se snažit, aby trochu fungovala aplikace a trochu databáze.

Co se tu snažíte říci, je, že dáváte všechny svoje síly na první dva stupně, v naději že se nebudete muset zabývat tím zbytkem.

Já nic takového netvrdím. Jenom tvrdím, že je nesmysl zapomenout na ochranu (a případně odpuzení) s tím, že máme přece dokonalou detekci a omezení škod.

Ale mohl byste to udělat líp, než většina firem které se ženou za úspěchem, tj. a nejdřív nakódujou všechny možné tintítka a až teprve když internet zaplaví masa útoků na jejich produkt tak se začnou věnovat zabezpečení.

Myslím, že to dělám líp. Ono stačí nenechat se oblbnout tím, že (v PHP) přece všichni používají skládání dotazů a jako velký objev v zabezpečení prezentují addslashes(), uvědomit si, že skládání dotazů s uživatelskými vstupy bude vždy problém, a najít si řešení v podobě prepared statements. Tím mám hned ošetřeno, že v aplikaci nemůžu napsat místo, které by se dalo použít k podvržení útočníkova SQL dotazu. No, a takhle stačí postupovat u všech věcí, které nemám pod kontrolou, ale od kterých můžu očekávat útok. Případně si stačí projít pár internetových diskuzí o bezpečnosti a zkusit přijít na to, proč houfně doporučovaná řešení nebudou fungovat

[Šangala]

Protože jsem, byť neúmyslně, tuto lavinu spustil dovolím si vstoupit s dvěma malými postřehy abych rozbil dvou-tvárnost autorů :).

• K bodu 4. Jsem rád, že jste nakonec připustil, že je třeba definovat procedury a k nim oprávnění aby jste mohl aplikaci přiblížit Vámi zastávaného modelu a současně byla aplikace funkcční…
• Zmiňovaný phpMyAdmin také používá své master heslo pro svoji pma databázi,
  $cfg['Servers'][$i]['controlpass'] a $cfg['Servers'][$i]['controluser'] není jen pro přihlášení, ale i pro plnou vládu nad pma databází, což je jeho databáze, takže z hlediska bezpečnostního modelu je to zase ten Vámi odmítaný způsob.

[pht]

Co tak koukám do dokumentace, tak pma je možno umístit i do databáze uživatele (kam se hlásí pod svým účtem)... a jelikož nemám páru jak se ty tabulky používají tak si nedovolím spekulovat jestli je master heslo nebezpečné nebo ne.