If your first run is in IE and you can fire up FireFox and forge the URL with the same cid, you are in trouble ;-) I read the spec as "you should use the session as data storage to ensure that faking the cid involves faking the entire http session"
Or then I misunderstood the scenario. On Sat, Nov 14, 2009 at 9:14 PM, Gurkan Erdogdu <[email protected]> wrote: > Hi; > > I think that this is the normal. > > When you delete cookie, your session is still valid on the server side until > session times out/invalidated. If you send a get request via cid parameter, > conversation is restored again using that cid. Conversations are deleted when > session times out or is invalidated. I do not see any security hole on this. > > This is similar to session management without cookies. If you do not use > cookies, then JSESSIONID is used on every url that server sends. Browser > sends every request with JSESSIONID parameter. If somebody steals your > session id, then he can simulate fake requests but security must be managed > by the application in somehow. > > Thanks; > > --Gurkan > > > > > ________________________________ > From: Sven Linstaedt (JIRA) <[email protected]> > To: [email protected] > Sent: Sat, November 14, 2009 3:40:39 PM > Subject: [jira] Created: (OWB-163) Conversations are not scoped to a > particular session > > Conversations are not scoped to a particular session > ---------------------------------------------------- > > Key: OWB-163 > URL: https://issues.apache.org/jira/browse/OWB-163 > Project: OpenWebBeans > Issue Type: Bug > Components: Context and Scopes > Affects Versions: 1.0.0 > Reporter: Sven Linstaedt > Assignee: Gurkan Erdogdu > Priority: Blocker > > > According to the spec 6.7.4: "All long-running conversations are scoped to a > particular HTTP servlet session and may not cross session boundaries." > > If I create a long running conversation and delete my browser cookies (or > switch to another browser vendor) the conversation is still available by > attaching the CID to the request URL. IMHO this is a high security risk, > therefore I created this issue as a blocker. > > I stumbled upon this while trying to provide incremental instead of random > CIDs to long running conversations. I am using a nightly build of the trunk. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > -- --- Nik
