Thanks Alan! I think what the scan is telling me is that the passing back and forth of the session identifier(s) is not guaranteed to happen over https and it thinks the possibility exists for session hijack:
"This cookie will be transmitted over a HTTP connection, therefore if this cookie is important (such as a session cookie), an attacker might intercept it and hijack a victim's session. If the attacker can carry out a man-in-the-middle attack, he/she can force the victim to make an HTTP request to steal the cookie." The remedy says: "Mark all cookies used within the application as secure." I see that ACF has a checkbox for session cookies to be marked as "Secure" and it seems J2EE cookies are secure by default. On Wednesday, April 13, 2016 at 9:28:37 AM UTC-6, [email protected] wrote: > > I may have read this too fast ... our issue was actually two fold - the > Secure only flag should be something in the admin to check. At least that > is the case in Adobe CF... I haven't looked in the openBD admin because as > you see from my other answer, we set our own cookies and it's easy to set > the flag there. > > BUT - you still may need something like our solution because they > (security scanners) get upset because one of the cookie values is a serial > one up generation. Which they say the next session number could be guessed > and hijacked. It's a false positive though because CF/OpenBD use both > cookies together and the other is not one up generated. Which is why we > used the code to combine them into one encrypted cookie value. > -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
