Administrace komentářů

Příklad konfigurace nebo odkaz do dokumentace by nebyl?

Pro apache můžete od dávných dob použít suEXEC, nebo obdobný princip. Ten ale není kompatibilní s built-in skriptováním (PHP), musíte použít tradiční CGI. Modernější přístup je Apache/SELinux plus, který jednak funguje s built-in a jednak je flexibilnější. Pokud místo MySQL použijete sepostgres, budete mít nativní SELinuxovou kontrolu přístupových práv, pokud použijete MySQL, budete muset udělat nějakej bazmek, kterej bude alespoň mapovat kontexty na uživatele. Podobný přístup poskytuje Oracle ve svém aplikačním portfoliu.

Já uživateli webové aplikace neumožňuju spouštět libovolný kód na aplikačním serveru.

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ě?

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?

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.

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

Budu je investovat do takového opatření, aby jeho překonání stálo podstatně více než 50000, tj. aby se jeho zavedení vyplatilo. Kde to bude, je otázka konkrétní aplikace. Může se nakonec ukázat že kvůli škodě 50000 bude lepší použít out of the box produkty a spíše proškolit personál

Dejme tomu že se rozhodování zredukuje na výše uvedený případ. Pokud je zabezpečení truhly a brány stejným zámkem, zabezpečím truhlu a nechám otevřenou bránu. K otevření brány bude totiž mít přístup personál který nemusí nutně pracovat s pokladem v truhle.

Pokud bych utratil 2x tolik peněz a zabezpečil i bránu, nezískám žádnou výhodu. Útočník s paklíčem na bránu se dostane i do truhly s marginálním úsilím navíc.

V realitě ale je to jinak. Zabezpečení různých vrstev je různé. Mám na výběr:

- Zámek na bránu s 1% pravděpodobností průniku za 50000.

- Zámek na bránu s 5% pst. průniku za 25000.

(dtto na truhlu).

Pokud jsou tyto zámky různé, vyplatí se koupit 2 levnější varianty. Výsledná pst. pro průnik oběma bude 0.25%. I kdyby levnější zámek měl 10%, a výsledek u obou byl 1%, stejně se vyplatí 2 zámky, protože můžete průnik bránou odhalit, ještě než je útočník u truhly.

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.

Tohle ale platí i na ten Váš model, kde je bezpečnost na nižší vrstvě nulová.

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

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.

Problém je v tom, že aplikace ví, co je regulérní e-mail a co ne, ale mail server to neví.

Já zas nevím, o čem mluvíte, dejte mi nějaký příklad.

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

OK, takže mluvíte o tom, že implementujete zabezpečení neatomické operace. Např. snížit jedno číslo a zvýšit jiné (o ten samý počet) Máte možnosti:

1. povolit web aplikaci kompletní přístup k tabulkám pod jedním uživatelem (Váš přístup) a nechat "AL" aby to vyřešila - pokud se AL zblázní, budete mít totální fuck up. navíc budete mít problémy s koukáním do cizích košíků atd.

2. mít uživatele e-shopu na úrovni db a povolit jim přístup k tabulkám - pokud se AL jednoho uživatele zblázní, dojde k omezené škodě. budete jednou za hodinu kontrolovat konzistenci tabulek a případně můžete dohledat a rollbacknout špatné transakce. budete mít zabudovanou separaci košíků na úrovni db.

3. dtto jako 2. ale skrouhnete práva na zvyšovat 1. číslo a snižovat 2. číslo. podobné jako výše, bude záležet na konkrétní situaci, zda toto přinese další bezpečnost. u košíku pravděpodobně ne, u hypotéky pravděpodobně ano.

4. nepovolíte přímý přístup k tabulkám, ale jen k proceduře, která atomicky (z vnějšího pohledu) provede danou operaci - přesunete problém na nižší vrstvu a můžete začít znova od bodu 1 s tím že AL=procedura. tohle se vyplatí dělat pokud potřebujete mít zajištěnou realtime konzistenci na úrovni db.

Všimněte si že přechod od bodu 1 k bodu 2 přináší razantní zlepšení za poměrně malé oběti.

Spokojen?