Forum Discussion
cdjac0bsen
Nimbostratus
Nimbostratushttponly and secure cookie attributes in application vs. ASM cookies on v11.4.1
Vulnerability scanners in our environment have flagged applications as needing the httponly and secure attributes set so I started investigating what I needed to do. I discovered the ASM cookie settings that require an ASM restart in SOL13787 and the settings in application security headers >> cookie properties where you can insert these attributes.
I'm not sure I fully understand how the ASM cookies "wrap" the application's cookies other than their purpose is to ensure integrity. What I'm trying to determine is which attribute settings I need to enable in order to satisfy the vuln scans. I would really like to avoid the ASM cookie settings for two reasons: it affects all cookies from every policy on the ASM and some applications may not work (called by JS for example) and second, because you have to restart the ASM which is problematic in a change-controlled prod environment when we'd have to get the approval from every application owner.
What happens if you only change the application cookie settings and not ASM cookies? We still have some 10.x systems, how does the answer to this question change?
Thanks, Chris
gowenfawrYour question seems to be: since the ASM cookies aren't part of the application per se, do you need to adjust them or can you get by without adjusting them? The answer is almost certainly that yes, you need to adjust them - the scanner doesn't care where they come from; it was told to scan an IP, it sees cookies it doesn't like at that IP, it reports them. Unless you can somehow convince your scanner vendor to except that finding, which is unlikely.
cdjac0bsenWhere are these attributes enforced, on the client? If you insert these attributes via the application cookie properties but not the ASM cookies, will it (client?) still enforce them? Do the ASM cookie attribute settings override the application cookie settings? Could I, in fact, make the case and prove to the vuln scan team (internal, by the way) that the attributes are set if I only enable them on the application cookie? I wish F5 had some kind of flow diagram that showed how the ASM and application cookies worked together. I've read the individual KB articles on the two cookie types, but I can't get my head around the whole flow. I wonder if anyone has experimented with these settings and have some fiddler traces.If the cookie doesn't provide sensitive information, or session identity if can be reported as a false positive. Persistence cookies, various state cookies, etc... should not require a secure flag. Further, the typical way of "deleting" cookies is to send a Set-Cookie with the content to 'deleted' and removes the secure flag. We have successfully had these non-sensitive cookies reported as false positives.
For the actual session cookies, PHPSESSION, JSESSION, etc... the back end server should be setting the secure flag. Alternatively, you could alter the cookie as it passes by.
I don't think the ASM cookies have any specific login / session info. https://support.f5.com/kb/en-us/solutions/public/6000/800/sol6850.html. Primarily it would be app cookies, specifically the ones used for login / session.
The scan tool should tell you the cookies it doesn't like. You'll have to do some leg work to validate what the cookie is used for. If it is simply holding the background color the user likes for the kitty pictures, you probably don't need a secure flag.
