secure
4 TopicsCookies 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 } } /jeff1.9KViews0likes1Commenthttponly 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, Chris499Views0likes4CommentsiRule to secure flag on specific URL (Multiple URL in one VS)
Hi We know that F5 can add secure attr in cookie from irule HTTP_RESPONSE <https://support.f5.com/csp/article/K11324> but this is apply to all website in virtual server!! We have many URL in one virtual server. (Multi domain). ie URL-a.example.com and URL-b.example.com have the same Virtual server Can we just add secure flag on cookie only when we access URL-a.example.com ? no need to add flag when we access URL-b I think we need variable to check if http:host is URL-a or URL-b, but I don't know how to do it when this variable has to share on HTTP_REQUEST and HTTP_RESPONSE event on the same times. Thank you374Views0likes1CommentSecure Cookie when the VIP is requested by IP (not URL)
Hello. I have a VIP config where the pool member is the one handling the cookie to the client. The pool member has a limitation when the client access the VIP via IP (not URL), the cookie is served not secured. I created this iRule which one of the side effects is an increased in the CPU utilization. when HTTP_RESPONSE { set cookies [HTTP::cookie names] foreach aCookie $cookies { HTTP::cookie secure $aCookie enable } } Is this the most efficient way? Is there a way to use a policy vs an irule? Thank you J349Views0likes2Comments