Administrace komentářů

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.