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" } } }
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
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!
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