Hi
Looking at JSDO js library, I am trying to work out how the JSESSIONID is made. A security audit has asked us to prove that it can not be shared between sessions, either accidentally or maliciously.
The JSDO seems to use math.random features, a timestamp, and some ascending sequence number in _getNextTimeStamp . Subsequent requests only get regenerated fully after a large number of requests.
Is this correct? If the JSESSIONID is regenerated fully with each received request that is probably OK (and previous JSESSIONID invalidated). But if just based on the seq number with the original timestamp and random it may be spoofable (I haven't tried yet but am likely to be asked to).
I am looking at around line 8950 and on in JSDO Ver 4.0
Hello,
The _getNextTimeStamp() function is intended to generate the value of a timestamp parameter ("ts") that is send to the server with a request to prevent caching. It is not related the JSESSIONID.
The JSSESSIONID is an HTTP session token generated on the server and sent to the client to identify a session.
The JSESSIONID is generally sent as an HTTPOnly cookie which means that it is not available to the client via JavaScript. The handling of the cookie is done by the web browser/container. If the client does not accept cookies, the JSESSIONID would be sent as a parameter in the URL.
See general information at en.wikipedia.org/.../Session_(computer_science)
It goes out without saying that you should use HTTPS.
My understanding is that the security support that we use for the application server for REST / WebSpeed is based on Spring Security which is open source (via git).
I will let others in the team comment on how the JSESSIONID is actually generated.
I hope this helps.
One addition to Edsel's post -- as he said, the default behavior is that the JSESSIONID will be sent as an HTTPOnly cookie and therefore not accessible to JavaScript. However, it's possible to configure an OpenEdge Web application so that it sends responses that include the JSESSIONID value in a header that is accessible to JavaScript. When the JSDO library detects this header in a response, it includes it in future requests both as a header and in the URL. The code that I think you're referring to is part of that implementation.