... jak to vlastně dopadlo? Zajímá mě, kde byl zakopaný pes. Petr
2010/9/9 Oto Buchta <ta...@buchtovi.cz> > 2010/9/9 Tomas Beranek <beranek.to...@gmail.com>: > > diky za tipy a rady, > > ale instancni promenna to taky nebude, vim jak se chova Action v Struts. > > zadne takove promenne nepouzivam. > > > > je tam proste jen execute(...) metoda. > > > > zacinam cim dal vice podezrivat ten firewall :-) > > Asi takto: > něco někde není RequestSafe. > Chyba se projevuje tak, že dva requesty s různým sessionID obsahují > stejná data. Předpokládejme tedy na chvíli, že to má opravdu na > svědomí firewall. Dovolím si předpokládat, že onen firewall není > session-based-loadbalancer. Co by to tedy znamenalo? > > a) změní se sessionID > Session (ať už je to HttpSession jiný druh mapy používající sessionID) > přiřazuje k požadavku příjemce, tedy servletový kontejner či jiná > aplikace v servletovém kontejneru běžící. sessionID je přiřazeno vždy > na základě příchozích paketů. Tyto pakety obsahují aplikační data (v > daném případě data HTTP) a síťové hlavičky. Kdyby se sessionID > přiazovalo pouze na základě síťových hlaviček, tak by buď všechny > požadavky jdoucí ze stejné zaNATované sítě získávaly stejné sessionID > (při identifikaci podle MAC adresy, IP adresy či jiného určení > konkrétního počítače) a nebo by nebylo zaručeno, že stejný uživatel > bude mít stále stejné sessionID (při identifikaci podle portu). Když > si tedy řekneme, že nám čisté síťování nestačí, musí se použít něco, > co je v datech. > > Aby došlo na straně přiřazení k záměně session ID, které je > vyhodnocováno i na základě dat, musel by ten, kdo sessionID zamění, > vědět, kde se PŘESNĚ (protože se nenahradila jen tak nějaká data, al > pouze ta pro sessionID) nachází data definující sessionID, a to v obou > požadavcích. To by znamenalo, že dané RequestUnsafe něco musí rozumět > minimálně komunikačnímu protokolu (pokud je sessionID v URL) nebo > přímo datům (cookies či POSTové proměnné) , pokud se jedná o něco v > datech. Z toho plyne, že tu máme co do činění s RequestUnsafe proxy či > transparent proxy v prvním případě, v druhém by navíc musela kompletně > parsovat data a navíc s nimi pracovat velmi zvláštním způsobem. > > b) změní se data > předpokládejme, sessionID je tedy správné. Potom musí něco přepsat > přesně tu část dat, která odpovídá datům zaměněným. Opět tu máme něco, > co rozumí datům a buď úmyslně či díky zvláštnímu a chybnému parsování > nahradí v požadavku právě přesně těmi daty z jiného požadavku > > Musím se přiznat, že nevěřím, že by toto dělal firewall. > > Proto spíš vidím problém na straně aplikace, která datům rozumí a díky > drobné nepozornosti mezi židlí a klávesnicí způsobí, že se data > navzájem přeplácnou. Protože jde podle mého hloupého názoru opravdu o > přeplácnutí dat, nikoli o záměnu sessionID > > -- > Oto 'tapik' Buchta, ta...@buchtovi.cz, http://tapikuv.blogspot.com >
