Masking jsessionid with ASM

What is your security concern with the jsessionid in the URI? Is the application only accessed over HTTPS? That would be the simplest way of ensuring third parties couldn't steal the session ID. The jsessionid is already encrypted, so I don't think masking it would add any security.

 

 

ASM provides the ability to track the value of a dynamic session ID in the URI. This would allow you to block a client who makes a request with a jsessionid that the server didn't set itself. You can check the ASM configuration guide to get more details on configuring extraction and enforcement of dynamic session IDs:

 

 

https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm_945_config_guide/asm_web_apps.html1027969

 

 

To be honest, I'm not sure if you need to configure extraction of the jsessionid as a dynamic parameter or if ASM automatically looks in the response content using the regex you designate in the web application properties. Maybe someone can clarify this or you could test it?

 

 

Here is the section on dynamic parameter extraction/enforcement:

 

 

https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm_945_config_guide/asm_parameters.html1031654

 

 

Aaron

Doh... actually if the client is being sent the jsessionid in links because it doesn't support cookies, then you won't be able to use the ASM cookie to track whether the server set the jsessionid in a response. Any request from the client with a jsessionid in the URI would be blocked if they didn't have an ASM cookie with the correct hash. Likewise, if someone was able to get the jsessionid from the client and steal the ASM cookie within the timeout period, they'd still be able to steal the session.

 

 

I guess this goes back to the question of what are you security concerns with the jsessionid?

 

 

Aaron

Well the concerns are that this application is accessed over straight http as well as ssl. In my perfect world they would switch to stricktly https and the concern would go away. So really the concern is for the situation where cookies are not suported and the user is accessing the site over http. This is good information for protecting from this when cookies are in use, but I am sorta stumped as to how to handle this for http traffic.

Forcing everything over SSL would the most secure option I can think of--and by far the easiest. If this isn't an option, conceptually you could try to tie the jsessionid to an attribute of the client that would be present for every request. This could be the client IP address (though this is prone to change for DHCP clients or those going through mega-proxies) or the User-Agent header. You could parse response content for the jsessionid, append the client IP address or User-Agent string and then encrypt it. Adding a timestamp to the string you encrypt would allow you to enforce a timeout. You would need to do this encryption for all jsessionid values in the response content, decrypt the jsessionid in the path and replace the encrypted string with the original jsessionid. You would need to handle clients who do support cookies as well as those that don't.

 

 

I did something similar for a client previously using payload collection and rewriting, but it was quite an undertaking. Now that I know about the STREAM_MATCHED event it might be a bit simpler and more efficient to use a stream profile and iRule to do this.

 

 

It wouldn't be easy to develop such a rule. And it's not a bulletproof solution. I'd think it would be a lot easier, more efficient and more secure to just encrypt everything using HTTPS.

 

 

Aaron

So from the second responce in this thread it appears that we could ensure that the jsesionid was only used by the appropriate client assuming we are ok with customers who don't support cookies being blocked. After discussing this with my development team I beleive this is the direction they want us to go in, but I am not sure I am seeing everything needed to do this. I have enabled dynamic sessions using this regex ;jsessionid=.{32} but this seems to make no diffrence even when I put the policy into blocking mode. Do I need to do something in paramaters to make this work?

If you (or your dev team) is willing to block clients who don't support cookies, couldn't you avoid the possible session ID leakage issue by not using the jsessionid in the URI?

 

 

I'd still suggest that using SSL for all but the initial request would provide better security and definitely better functionality for all clients--including those that don't support cookies.

 

 

That doesn't answer your question about enforcing the dynamic session ID in the URI. Does anyone know if you need to configure the dynamic session ID in URI regex as well as the extraction in order to validate the session ID?

 

 

Aaron

Bumping

 

 

Any one have any experience with this?

If you're looking for more info on configuring dynamic session ID in URL enforcement, you might try opening a case with F5 Support and ask them how the feature works.

 

 

Aaron