Administrace komentářů

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.