Administrace komentářů

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í…