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
"Always Send Cookie" problems?
Is there a downside to choosing "Always Send Cookie" in an "HTTP Cookie Insert" persistency profile? I am troubleshooting an issue with Cloudflare and a potential issue with my current F5 settings. The below is specifically called out by CF (re: the F5), but I am not 100% that it correlates to the "Always Send Cookie" setting. Per Cloudflare, via https://support.cloudflare.com/hc/en-us/articles/212794707-General-Best-Practices-for-Load-Balancing-with-Cloudflare; // Session cookies section above Cloudflare article If using HTTP cookies to track and bind user sessions to a specific application server at the load balancer, it is best is to configure the load balancer to parse HTTP requests by cookie headers and directing each request to the correct application server even if HTTP requests share the same TCP connection due to keep-alive. For example: F5 BIG-IP load balancers will set a session cookie (if none exists) at the beginning of a TCP connection and then ignore all cookies passed on subsequent HTTP requests made on the same TCP socket. This tends to break session affinity because Cloudflare will send multiple different HTTP sessions on the same TCP connection. (HTTP cookie-based session affinity).list element in quotes followed by <something> instead of space
The following iRule occasionally produces errors: foreach cookie [HTTP::cookie names] { switch -glob -- $cookie { "xxxxx" - "xxxx" - "xxxx" - "xyxyxyx" - "xxyxyx" - "xyxyxy*" { HTTP::cookie remove $cookie } } } } I was scrolling through logs and noticed this: - list element in quotes followed by "de25df2-103438293-"" instead of space while executing "foreach cookie [HTTP::cookie names] { switch -glob -- $cookie { "xxxxx" - "xxxx" - "xxx" - "xxxx" - "xxx" - "xxxxxxx" { ..." Initially I tried to use the catch command to prevent execution failures. Mostly I wanted to see the cookie name. I wasn't able to figure out where to place it, however, as the error seems to fire on the line that initiates the switch. I was able to prevent this error form occurring by doing the following, but it seems less efficient. when HTTP_REQUEST { set cookies [HTTP::cookie names] set cookie_list [split $cookies " "] foreach cookie $cookie_list { switch -glob -- $cookie { "xxxx" - "xxxxx" - "xxxxx" - "xxxx" - "xxxx*" - "xxxxxx*" { HTTP::cookie remove $cookie } } } } I would like to understand how to catch the error, or figure out why the native [HTTP::cookie names] list doesn't parse well unless I split it out specifying the " " character.
How to maintain Cookie persistence across web application with multiple ports (i.e. 80, 8443)
We have an F5 LB. There are two back-end servers that sit behind it. SSL termination is at the LB. Mapping to the back-end servers is 443 to 80, 80 to 80, and 8443 to 8443. That is, on the back-end servers, we have ports 80 and 8443 open. The LB was first setup with source IP persistence. We just moved to Cookie persistence to alleviate some issues with IP addresses switching mid-session and the like. The cookie persistence is session cookie, meaning no expiry and the cookie should expire when the user closes the browser. The cookie is also encrypted with a passphrase to comply with security practices (not sure why F5 would set the cookie value to some obfuscated value that maps to the back-end server IP and port, since that is apparently not very difficult to un-obfuscate). In testing the web application behind the LB, everything seemed to be OK. Then, we got a report from users with a particular piece in the web application, which loads pages over multiple ports (i.e. 80, 8443). What I see happening is, whether the request first starts with 80 or 8443, the LB cookie value is being generated again when the page is requested from the other port. It doesn't happen 100% but it happens frequently. Then the application reports that the application session is invalid. My guess is even if the cookie value changes, if it happens to hit the same back-end server, there will be no issue. However, if the request happens to hit the other back-end server, the web application will see the request as a new application session and, thus, report that the application session is invalid. What I think what might fix it is maintaining the cookie persistence across the multiple ports we have configured (i.e. 80, 8443). The problem is I'm not quite sure how to do that. That's why I'm here, to ask people who are smarter than me and more experienced and may know some solutions that would work. I would prefer to keep using HTTP Cookie Insert method, although I understand cookie hash does have options similar to source ip persistence such as match across virtual servers and the like. I don't know how much that would help me here, if at all. Can I use an iRule? If so, what might that look like? Maybe an iRule that checks if there is an existing LB cookie and if the request is coming from 80 but going to 8443 or vice-versa, then insert the cookie into said request such that no new cookie is generated and the same cookie is shared across port 80 and port 8443. Sounds good in theory but I'm not even sure of the first place to start to even attempt it. I hope what I'm asking is clear. If it isn't, please feel free to ask me to clarify. I want to maintain the LB cookie across multiple ports. Example: User goes to testsite.com/index.html. LB generates a cookie with value 1234. User is sent to back-end server 1. User then goes to testsite.com:8443/index2.html. LB will generate a new cookie with a different value--let's say it's 5678--and it may send the user to back-end server 1 or 2. If it goes to 1, the web app should be OK. If the request goes to 2, the web app will complain because the web app session is on 1. I want testsite.com and testsite.com:8443 to both have the same exact cookie, which, in this example, would be 1234. Does that make sense? Any help would be appreciated. Thank you in advance.
Priority Group Activation Failback with HTTP Cookie Insert
Hello All, Can someone help me the below issue? We have a pool with 3 members. 2 members have high priority (Round Robin) and 1 member has low priority. When both the primary members go down, the low priority member should take over the traffic. We have Cookie Insert persistence enabled on the virtual server. In Cookie persistence, "Expiration: Session Cookie" enabled. When both the primary members were made down, the low priority member took over the traffic. When both the primary members came back UP, the traffic continued to go to low priority backend member. When the browser tab is closed and tried to access the URL in new tab, the traffic went to low priority backend member. When the browser window is closed and tried to access the URL in new tab, the traffic still went to low priority backend member. When the browser cookies were deleted and tried to access the URL in new tab, the traffic was taken over by the high priority members. This behavior is not desired and we need to force the LB to use high priority backend members as soon as they come UP. When user tries the connection from new browser or new tab, the traffic should go to high priority pool members. Please let me know how i can achieve the desired behavior. RegardsWhat happens if the ASM sees a TS cookie it did not set.
I have a configurtion and I am wondering if this causing Timestamp Expired cookie violations. I have a configuration where a TS cookie can pass back through a policy that did not set it. In this config we have different policies for different Url's. In the responce the set-cookie is for a 'higher' point in the domain tree. For exmaple the policy sets the cookie for .abcdef.com in a policy that is mapped to xyz.abcdef.com. Another request is made to another policy that is mapped to 123.abcdef.com but in the request the cookie from the other policy is the TS cookie from the last request, but this policy did not set it so is not aware of it. Policy one set cookie TSxxxxxx in domain abcdef.com from request to zyx.abcdef.com Policy two gets request to 123.abcdef.com and receices the TS cookie for the sub domain abcdef.com Would this create a Cookie Violation - Expired TimeStamp. I am think the ASM reconises it as a TS cookie but also knows it was not set by the policy that is inspeciting it. Any clues would be great GrahamCookie sets domain the same as the requesting Host Header
I have a cookie set with the domain name the same as the requested Host header and I have another cookie set where does not specify the domain. So both cookies end up saved for the same domain location, one because it is default and one because it is specified. The problem is the ASM see's two cookie locations and set two TS cookies one for the default domain location and one for the specified domain location, even though they are the same domain Is there are reason why the domain in the cookie would bet set to match the requesting host header - I cant think of one Any information/responses would be very helpful Graham
Remove Cookie from Request Based on Cookie Domain
I have a web application that will fail if it sees any cookies other than what it knows should be present. I need to scrape/remove all cookies other than that which is required. The required cookie has a semi-dynamic name that could be partially shared with cookies that we do not want. Thus I'm focusing on the cookie domain which I know will be unique. Below is my attempt to complete this. The reason I am not working on the http response is that the other cookies on the client may be required for other applications so I just have to allow only the cookie of interest on the incoming (Request) traffic. The problem I am currently having is that the cookie domain appears to be empty for every incoming cookie. The logging is working properly, but the rule is removing every cookie because the 'cookiedomain' variable is empty. If I change the step 2 logging to "[HTTP::cookie domain $cookie]" it still is blank when outputting the cookie domain. Any help identifying why I am not properly capturing the cookie domain would be much appreciated. when HTTP_REQUEST { set cookies [HTTP::cookie names] foreach cookie $cookies { log local0. "step 1 - cookie name is $cookie" set cookiedomain [HTTP::cookie domain $cookie] log local0. "step 2 - cookie domain is $cookiedomain" if { $cookiedomain ne "test.mysite.org" }{ log local0. "step 3 - Removing cookie $cookie" HTTP::cookie remove $cookie } } }
iRule to store cookie in table
Hi, I am really iRule novice and so any advice, pointing in right direction will be of great help for me. I am short on time and have to create iRule with following logic: Service behind F5 is doing kind of authentication If user succeed cookie is created iRule should monitor HTTP_RESPONSE for presence of this cookie for specific URI When detected in Set-Cookie header entry in session table should be created (with set lifetime like 2400s - counter updates should not extend lifetime of this entry) storing cookie value HTTP_REQUEST should be monitored for presence of above cookie When detected lookup in table should be performed (using cookie value?) If found: Entry should be checked if it is first occurrence of given cookie value (so this value is detected for first time) If yes - values from few headers should be added - like User-Agent, first IP from X-Forwarded-For (the one that should be real user IP that initiated connection from Internet), maybe some more, counter should be set to 1 If not just counter should be incremented If not found lookup in separate subtable (like false_cookie, indefinite lifetime) should be performed If entry found counter should be incremented If not found new entry should be created using cookie value as a key? Connection should be dropped. Optionally sorry page displayed Well, that is my idea but maybe I am missing something or there is better way. Main goal is to drop all HTTP request (POST operation using specific URI) that do not contain valid cookie. Plus collecting stats about how many illegitimate attempts to perform POST to this UIR were issued. Hope it makes sense, will appreciate a lot any help, Piotr