Administrace komentářů

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ů.