Administrace komentářů

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.