Forum Discussion

cdjac0bsen's avatar
cdjac0bsen
Icon for Nimbostratus rankNimbostratus
Dec 29, 2015

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

 

ASM Advanced WAF
httponly
secure
security

4 Replies

Sort By
  • gowenfawr's avatar
    gowenfawr
    Icon for Nimbostratus rankNimbostratus
    Dec 29, 2015
    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.
  • cdjac0bsen's avatar
    cdjac0bsen
    Icon for Nimbostratus rankNimbostratus
    Dec 29, 2015
    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.
  • JCohen's avatar
    JCohen
    Icon for Employee rankEmployee
    Dec 31, 2015

    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.

     

  • Jason_Cohen_417's avatar
    Jason_Cohen_417
    Historic F5 Account
    Jan 03, 2016

    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.