Vlákno názorů k článku
Bezpečnostní díra v Java knihovně ohrožuje stovky aplikací od Filip Jirsák - Zprávička zní dost neseriózně, když je v ní...

Ne, nepíše. Podívejte se na ten odkazovaný článek – WebLogic je napaden přes protokol T3, OpenNMS přes RMI…

Vy jste tím webem nějaký uhranutý, ne? Asi jste myslel, kdo má T3 nebo RMI „vystrčené do veřejného internetu“. No tak někdo to tak mít může, vždyť jsou ty přístupy chráněné autorizací a mělo by to být bezpečné. A i když to někdo má přístupné jenom z nějaké privátní sítě, pořád není správné, že kdokoli v té síti může ten server třeba vypnout.

Apache reverse proxy je snad minimum co tam ludia davaju
Soudní lidé tam Apache reverse proxy nedávají.

Diera to je, netvrdim ze nie, ale nie taka velka ako sa snazi autor exploitu naznacit.
To spíš záleží na konkrétní situaci. Horší podle mne je, že ta díra spočívá v něčem jiném, než autoři exploitu naznačují, a hlavně že ten jejich „fix“ zalepí jednu konkrétní díru, kterou zkouší jejich exploit, ale neřeší tu díru jako takovou.

Load balancing a fail over riesite ako?
No tak konkrétně my to řešíme hardwarovým loadbalancerem. Ale některé aplikace jsou rozvažované na úrovni TCP spojení, takže to má hodně blízko k tomu, kdyby ten WebLogic byl přímo vystrčen do internetu?

Ci pouzivate WebLogic za velke peniaze a mate ho rovno vystrceny do internetu?
Bojíte se, aby se neošoupal? Já teda tak nějak u dražšího řešení předpokládám, že by mělo být lepší a tudíž i bezpečnější.

Jinak já jsem narážel na to, že když tak autoritativně zmíníte jedno řešení v situaci, kdy jich existuje n různých podle konkrétních požadavků, nepůsobí to dojmem znalce, o což jste se asi snažil, ale právě naopak.

Diera tam ziadna nie je. Iba niekto zle implementoval deserializaciu udajov.
Jo, a když někdo zadá příjmení „Novák'; drop database;“, tak to také není chyba ale jen „zle implementovaná deserializacia udajov“.

Oni spravili kod v custom deserializacnom hooku ktory robi neplechu, to nie je genericka diera.
Přečtěte si popis té chyby, je to hned druhý příspěvek v diskusi. Ta třída, která v rámci deserializace spouští neznámý kód, je součástí JRE. To je dost generické. A takových tříd, které nemají readObject() odolný proti útokům, bude spousta. Spuštění kódu, který útočník nikdy neměl mít možnost spustit, je docela průšvih. Samozřejmě by mohl být ještě větší, tady má útočník přeci jen omezené možnosti – vedle té třídy s readObject() potřebuje další vhodné třídy, přes které útok povede (např. ty z Apache Commons Collections).

Jo, a když někdo zadá příjmení „Novák'; drop database;“,
Myslel jsem samozřejmě případ, kdy vám tím smaže databázi.

To, že jste něco neviděl, neznamená vůbec nic. A vzhledem k tomu, co tu píšete v komentářích, to neznamená tuplem vůbec nic.

Pro útočníka zajímavé metody poskytuje i standardní knihovna, třeba System.exit nebo Runtime.exec. K tomu, že útočník může smazat databázi, i když v programu žádný takový kód není – hledejte pojem „SQL injection“. Když má útočník v ruce spojení do databáze a může na něm zavolat libovolný příkaz, má dost silný nástroj.

To HTTP a web vás opravdu uhranulo. Vězte, že existují i jiné síťové protokoly, než HTTP, a také se přes ně dají přenášet serializované objekty. A dokonce může útočník podvrhnout serializované objekty i do vstupu, který server nedostane síťovým protokolem, ale třeba ze souboru nebo databáze.

To nevím, co s tou vaší paranoií budete dělat, až zjistíte, že existují i jiné protokoly než HTTP. SQL injection jsem uváděl jako příklad toho, co může útočník udělat, pokud dokáže zneužít téhle chyby. Byla to reakce na vaše tvrzení, že je ta chyba nezajímavá, protože útočník nemůže spustit žádný jiný kód, než ten, který je v aplikaci. Pouze dodržování zásad k zajištění bezpečnosti nestačí – je potřeba tomu také rozumět. Jinak dotyčný dopadne jako vy a bude si myslet, že když používá binding parametrů, nemusí se SQL injection bát.