Sessions with(out) cookies
Recently in a penetration test engagement I tested a WebSphere application. The setup was more or less standard, but the interesting thing happened when I went to analyze how the application handles sessions.
Virtually 99% of all web applications today use cookies in order to store session information. However, the application I tested set a very weird cookie with the following content:
SSLJSESSION=0000SESSIONMANAGEMENTAFFINI:-1
Clearly that cannot be used for session handling, however no other cookies were set by the application, yet sessions were handled correctly. After a bit of browsing through WebSphere’s documentation, I found out that WebSphere (actually IBM HTTP Server as well as SUN One Web Server) support a feature called SSL ID Session Tracking. Basically, what this does is bind web application sessions to SSL sessions. This further does not require the web application to do almost any session handling since the server performs this on behalf of the application.
However, in this simplicity lurk several potential problems:
- Since the web application’s sessions are tied to SSL channel session, any user that can somehow access the same SSL session is automatically authenticated by the target web application. While this scenario is not all that likely, it is still possible through, for example, an incorrectly configured proxy that somehow reuses opened SSL sessions – opening Burp proxy and letting it listen on the network interface in such a setup is a really bad idea.
- The web application (as it should always anyways) has to properly handle logout activities and invalidate the SSL session – since there are no cookies it must prevent the web browser from reusing the same SSL session.
On the other hand, there are several really nice features here – probably the most important being that an attacker cannot abuse vulnerabilities such as Cross Site Scripting to steal session information. Of course, XSS can still be used to perform other attacks through the vulnerable application, but session information cannot be stolen any more.
SSL ID Session Tracking is, however, deprecated in WebSphere 7.0 so it is pretty rare today. This means that the applications must use cookies to handle session information, or transfer them as parameters in requests but this is not recommended since such information is visible in logs. In essence this leaves us with cookies which are probably here to stay so it does not hurt to remind your developers to use HttpOnly and Secure parameters; it is trivial to set them and, while they are not a silver bullet, these settings can make exploitation of some vulnerabilities much more difficult.
--
Bojan
@bojanz
INFIGO IS
Comments
www
Nov 17th 2022
4 months ago
EEW
Nov 17th 2022
4 months ago
qwq
Nov 17th 2022
4 months ago
mashood
Nov 17th 2022
4 months ago
isc.sans.edu
Nov 23rd 2022
4 months ago
isc.sans.edu
Nov 23rd 2022
4 months ago
isc.sans.edu
Dec 3rd 2022
3 months ago
isc.sans.edu
Dec 3rd 2022
3 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
isc.sans.edu
Dec 26th 2022
3 months ago
isc.sans.edu
Dec 26th 2022
3 months ago