Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

httponly 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

0
Rate this Question
Comments on this Question
Comment made 29-Dec-2015 by Greg 248
Your 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.
0
Comment made 29-Dec-2015 by cdjac0bsen 60
Where 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.
0

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
Comments on this Answer
Comment made 31-Dec-2015 by cdjac0bsen 60
JC, good information but could you translate that into a suggestion on which cookies (app or ASM) we should really be enabling these attributes so it passes the vuln scans? I agree that the backend servers should likely be setting this, but in lieu of getting the app teams to make the change, we have to do in on the ASM in the interim.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0