Administrace komentářů

Chci vidět příklad, kdy útočník může v kontextu aplikace spouštět svůj kód, ale jediný problém by byl, pokud by tento kód měl přístup ke sdílenému heslu do databáze. A pokud takové heslo neexistuje, spouštění útočníkova kódu v aplikaci nevadí a klidně to můžu povolit.

Já nevím, myslím že jsem tu už navrhnul schema kde každý požadavek na web server poběží v kontextu, který nemůže dělat o mnoho více než je zamýšleno. V takovém případě klidně můžu dát k dispozici input box napojený na eval(). Použití master hesla do db by pak jen podtrhlo jeho nesmyslnost.

Proč se držíte tohoto speciálního případu? I pokud dostanu mnohem širší práva na průměrně zabezpečeném systému, tak použití účtů v db a systému "každý má přístup do svého" bude hrát významnou roli.

Z Vašeho uvažování by plynulo, že pokud zákeřná stránka dostane možnost vykonávat kód v kontextu webového prohlížeče oběti, tak má automaticky administrátorský přístup k celému počítači. Na základě této úvahy byste pak doporučoval lidem spouštět firefox pod rootem.

Můžu se zeptat, co pak zůstane na aplikačním serveru?

To co tam je teď. Klikátka, generování tabulek, grafů, posílání mejlů, a dalších tisíc píčovin, kvůli kterým jste si ten aplikační systém objednal. Ne každej je tak ostřílenej aby na Alze objednával pomocí "INSERT INTO objednavky" ...

Například mezi webovými aplikacemi, o kterých je celou dobu řeč, jich je přesně nula.

Asi jste spíš chtěl říct, že webových aplikací, které by používaly nativní databázovou bezpečnost je nula.

Jednak se nebavím jen o webových aplikacích, ale o obecném principu, ze kterého můžou webové aplikace těžit.

A jednak je určitě všechny znáte do detailů, abyste to mohl tvrdit. A patrně nikdo nepotřebuje všechny ty věci, které se vyvinuly ve prospěch tohoto schematu. Můžeme u toho zůstat, jestli chcete.