Cookies with Duplicate Names, but different values not getting Secure and HttpOnly attributes set
We had an ASV scan come back with one of our applications not setting the Secure and HttpOnly attributes. When they set at the application layer it seems to break their SSO functionality. We are digging into that, but in the meantime, we are using the following iRule to add Secure and HttpOnly attributes. It works; however I noticed that the application has two cookies they are sending with identical names, but different values. For one reason or another, the first cookie with the same name gets the attributes and the second is ignored. We are exploring if the application team needs these and if not we can remove them; however, until then I'm trying to see if anyone else has had this issue or thoughts on a solution. https://support.f5.com/csp/article/K84048752 when HTTP_RESPONSE { foreach mycookie [HTTP::cookie names] { set ck_value [HTTP::cookie value $mycookie] set ck_path [HTTP::cookie path $mycookie] HTTP::cookie remove $mycookie HTTP::cookie insert name $mycookie value $ck_value path $ck_path version 1 HTTP::cookie secure $mycookie enable HTTP::cookie httponly $mycookie enable } } /jeff
How to add Httponly and Secure attributes to HTTP cookies (for 11.5.x)
Problem this snippet solves: Problem this snippet solves: The script adds Httponly and Secure attributes to cookies issued by the server. In v12.x software there is a better way to achieve the same outcome with using HTTP::cookie commands (even though adding Httponly requires additional tweaks because of the issue with cookie version field see discussion here). However, in v11.5 and earlier releases HTTP::cookie commands do not work as expected (in particular, upper case chracters cookie attributes e.g. "Expire" and "GMT" are parsed with errors, as discussed in 19-Oct-2013 post by DanW here). Furthermore, in these software versions F5 Persistent Cookies do not have "Httponly" attributes and adding them using HTTP::cookie command appears to be impossible (as "HTTP::cookie version" command cannot be used for F5-generated cookies). Note: the HTTP::cookie commands repairs non-RFC-compliant attributes "httponly=<any text>" and "secure=<any text>" by replacing them with "Httponly" and "Secure" respectively. The script below does not perform such replacements and leaves these non-RFC-compliant attributes unmodified (without adding duplicates of the attributes). We consider fixing non-RFC-compliant syntax to be out of the scope. Browsers we tested ignored the <any text> values (in "httponly=<any text>" and "secure=<any text>" attributes). How to use this snippet: How to use this snippet: The same instance of this iRule can be applied to a mixture of HTTP or HTTPS Virtual Servers and will automatically disable insertion of “Secure” attribute for the HTTP VSs. Tested on Versions: 11.5.2 HF1; 11.5.4 HF2; 12.1.1 HF1 Code : when CLIENT_ACCEPTED { set httpsVs [PROFILE::exists clientssl] # to determine whether the connection is via an HTTP or HTTPS VS # it can be done with [SSL::cert count] and catch in HTTP_RESPONSE # event, but there would have been a bigger perfomance impact } when HTTP_RESPONSE { set setckval [HTTP::header values "Set-Cookie"] HTTP::header remove "Set-Cookie" # this command removes all cookies from the responce, so we have to remove and then # re-insert in any case (rather then do it selectively on an as-needed per-cookie basis) foreach cookie1 $setckval { set cookie1 [string trimright [string trimright $cookie1] ";"] # to avoid obtaining multiple semicolons (e.g. ";;Secure" or "; ;Secure") in the output # if the orginal cookie had a trailing semicolon, possibly, followed by spaces # trailing semicolons, strictly saying, do not meet rules described in RFC 2965 # but there are reports of applications using them (e.g. Cisco Bug: CSCso95114) set list1 [lrange [split $cookie1 ";"] 1 end] # the first field (cookie name=value pair) is skipped to ensure that even cookies # that happen to have names "httponly" or "secure" are processed properly set hasHttpOnly false if { $httpsVs } { set hasSecure false} else { set hasSecure true } #i.e. insertion of "Secure" is disabled for non-HTTPS VSs foreach item1 $list1 { set titem1 [string tolower [string trim $item1]] # accordring to RFC 2965 leading and trailing WSP characters in atrributes # should be ignored and attributes should be treated as case-insensitive; if { ($titem1 eq "httponly") or ($titem1 starts_with "httponly=") } { set hasHttpOnly true } if { ($titem1 eq "secure") or ($titem1 starts_with "secure=")} { set hasSecure true } } if { not $hasHttpOnly } { set cookie1 "${cookie1}; Httponly" #log local0. "Missing Httponly attribute is being added to cookie: $cookie1" } if { not $hasSecure } { set cookie1 "${cookie1}; Secure" #log local0. "Missing Secure attribute is being added to cookie: $cookie1" } #log local0. "The following cookie is being rewritten: $cookie1" HTTP::header insert "Set-Cookie" $cookie1 } }
F5 APM cookie F5_ST not supporting httpOnly - is there any explicit documentation on that?
Env: LTM 13.1.3.6 Hi - we are working to address with our Security department a vulnerability scan, which has pointed out that during APM-managed login sessions the cookie "F5_ST" is set without the httpOnly option. In the documentation for the APM cookies (https://support.f5.com/csp/article/K15387), it describes how this cookie is processed by Javascript - which makes complete sense of why it doesn't support httpOnly. However, we would benefit from an explicit statement to that effect. Is anyone aware of any such statement in F5 documentation? I have searched, but have not been able to find anything. I also can't find anything in devcentral (except individuals asking how to set httpOnly, without receiving any replies). If anyone is aware of any statement, even if not official, that supports my assertion that httpOnly cannot be used, that would be helpful in absentia of an explicit statement. Thank you!
Aduit Log full of Operation not supported Errors
We created an irule to address a security audit that dinged us on "Sensitive Cookie Missing 'HTTPONLY' Attribute". Since then our audit log is full of errors from this irule. Though the irule appears to be working as expected. The errors we are seeing are: Tue Sep 9 09:28:42 EDT 2014 err local/tmm tmm[5026] 01220001 TCL error: iRule_Name_HTTPONLY - Operation not supported (line 2) invoked from within "HTTP::header remove "Set-Cookie"" Tue Sep 9 09:28:40 EDT 2014 err local/tmm tmm[5026] 01220001 TCL error: iRule_Name_HTTPONLY - Operation not supported (line 1) invoked from within "HTTP::header remove "Set-Cookie"" I've copied the irule below, any help in solving this would be greatly appreciated! Also we are running version 10.2.x and our device can not be upgraded to 11.x when HTTP_RESPONSE { set ck [HTTP::header values "Set-Cookie"] HTTP::header remove "Set-Cookie" foreach acookie $ck { if { [string tolower $acookie] contains "httponly" } { HTTP::header insert "Set-Cookie" "${acookie}" } else { HTTP::header insert "Set-Cookie" "${acookie}; HttpOnly" } } }
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