cookie
56 TopicsRemoval Cookies on Client Browser
Hello I'm trying to erase a bunc of cookies which belongs to expired session. Cookies are sending by the servers (CyberArk) and they are session cookies. Here in this scenario the F5 is used as Auth provider with an APM policy along with the load balancing. The APM policy is in LTM+APM mode so there is no webtop, connectivity profile and advanced resource assaing agent. This is not a new deployment but after the upgrade of Cyberark software in pool members, this design started to act a bit weird. When predefined idle timeout expires on CyberArk, the consequent requests get an error message on client and client sees an empty white page. After claening every thing (Ctrl+Shift+Del or using incognito mode) on the browser the problem vanishes. According to Cyberark support, the client sends a token that is not valid anymore. We identified some cookies that look like carrying these tokens and we wrote an irule to tell the client for clean all those subjected cookies when an APM session started. Seems like the iRule sends all needed cleaning declarations to the client browser and we saw all those cookies removed from cookie store of browser. But somehow some of them (CA11111, CA22222 and CA66666) is still carrying old token informations. According to my google-fu, there is no special removing methods besides mine. Also, found no information about that whether need to specify all those attributes used at the set-cookie moment as well while removing them. I mean those "domain=", "path=", "secure" and other attributes sent by server along with cookie at the beginning. The cookies sent by server: Set-Cookie: CA33333=; path=/PasswordVault/; SameSite=Strict; secure; HttpOnly Set-Cookie: __AntiXsrfToken=; expires=Tue, 11-May-1993 08:57:48 GMT; path=/; secure; HttpOnly Set-Cookie: CA44444=64D55E4839F5ED0032A7D0A7863EB07336F49030; path=/PasswordVault/; SameSite=Strict; secure; HttpOnly Set-Cookie: CA11111=00000002531296421D1226B831C822BA3BEE6FD4245F97F9A49C4C416052B0EC975B1B0C00000000; path=/PasswordVault/; SameSite=Strict; secure; HttpOnly Set-Cookie: CA22222=A1AC061D681C256A9DDF259B64D55E4839F5ED0032A7D0A7863EB07336F49030; path=/PasswordVault/; SameSite=Strict; secure; HttpOnly Set-Cookie: CA55555=cyberark; path=/PasswordVault/; SameSite=Strict; secure Set-Cookie: CA66666=jjxH6-chSXEEGbEjXXl7gyZv8xtT1XfiWqaUz7FPTVqntHw0AfdtPowY5YM0TJv5RHhFJPgoN1Oly2AJzxicXX5RroibSQeh1b4Ua_PTbA3L4fjEVTin3TXQ0bK9PU-VO6koC5iPZ0tOehb8AijWe0zJKaPJ_2hbqIBjgxVsitpxv3VBgXxEFqYQ9If8sE4o2wYS00mu0gVjRZKS9KSVLrbZPDVve0PgNT2alYsAv8Ic1O3mfqkgEYuAuJMndKMxGmE-7ehbwZX373XionLWaq3Viz67yk6UUH8qYCKhf2gpSnkh5PO-u9_e2M5O8uYYEVpTcA4O50Q0IAeU_V4zsg2; path=/PasswordVault/; SameSite=None; secure Set-Cookie: 6a5a355a-0547-40ce-9770-fc22d1f3bbea=8096DBD1E9E9ECF050757DDD2538169332D568558048455B5EC4A9CCB22A74F285F74A13FFF1DAC916C7558EBB15FD0F5EE388C0200435FA4822BD64B5833B0F824A23313EDBDDF519B5170AC7F177FF8D85DF020BEDDD01767EE977A710D5DB3DD6FE3D8A7C0D26442CE3EA472FD456FE69930D39769576D155C488AB79BB08818D36C8253800517365B75AF827BBF6; path=/PasswordVault/; secure; HttpOnly; SameSite=Lax My iRule: when CLIENT_ACCEPTED { set status 0 ACCESS::restrict_irule_events disable } when ACCESS_SESSION_STARTED { set status 1 } when HTTP_RESPONSE_RELEASE { if { $status == 1 } { HTTP::header insert "Set-Cookie" "CA11111=deleted;expires=Thu, 01-Jan-1970 00:00:01 GMT;path=/" HTTP::header insert "Set-Cookie" "CA22222=deleted;expires=Thu, 01-Jan-1970 00:00:01 GMT;path=/" HTTP::header insert "Set-Cookie" "CA33333=deleted;expires=Thu, 01-Jan-1970 00:00:01 GMT;path=/" HTTP::header insert "Set-Cookie" "CA44444=deleted;expires=Thu, 01-Jan-1970 00:00:01 GMT;path=/" HTTP::header insert "Set-Cookie" "CA55555=deleted;expires=Thu, 01-Jan-1970 00:00:01 GMT;path=/" HTTP::header insert "Set-Cookie" "CA66666=deleted;expires=Thu, 01-Jan-1970 00:00:01 GMT;path=/" HTTP::header insert "Set-Cookie" "6a5a355a-0547-40ce-9770-fc22d1f3bbea=deleted;expires=Thu, 01-Jan-1970 00:00:01 GMT;path=/" HTTP::header insert "Set-Cookie" "pam_persist=deleted;expires=Thu, 01-Jan-1970 00:00:01 GMT;path=/" } My questions are: Is there any specific requirement to delete a cookie or can i use above iRule to erase all of them? Should i specify all those attributes along with the cookies while deleting? Some of the above cookies send from server when a specific request made by client. While deleting them is there any specific rule/policy to follow? Like deleting the cookie at the request sent by client. I tried to use "HTTP::cookie remove" method but somehow i did not see any delete (Set-Cookie header) message coming from F5 for cookies. How "HTTP::cookie remove" method actually deletes a cookie? This is for the APM specialists. In a LTM+APM policy, is there any way to determine the moment of the session expiration happend and initiate a HTTP response for cookie clean message to the client? Thanks advance.Solved1.8KViews0likes4CommentsSAML Cookie Persistence after browser/system restart and across service providers
I am fairly new to the F5 world and in the beginning of setting up our LTM's as SAML IdP's for a variety of services. Our first use-case is Jive, which we have working and all the attributes are pulling across just fine, authentication is fine, everything is functional as is. I'm having a hard time translating what we want the user experience to be into the next phase of the configuration. Our hope was that we could authenticate a user to the LTM, they would be provided a cookie that was set to expire in 24 hours, that cookie would provide SSO access to other services that we'll be adding, and once the 24 hours is up the user would be asked to authenticate again regardless of which service they are logging in to. I've set the Maximum Session Timeout to 86400 seconds (24 hours) and set the cookie to persistent, but when I log in with a test account I don't see a new cookie created on the user system and closing the browser loses the session. In addition, I don't have another sandbox service provider to test with currently to ensure that the cookie we are hoping will be creating would be valid for that other service as well. Am I wrong in thinking that the F5 can provide a persistent cookie that survives beyond browser or systems restarts? Can the F5 only provide SSO for that time period and across SAML partners as long as that browser session is open? I presume I'm asking some pretty elementary stuff so forgive my lack of current knowledge. Any pointers on where I can read up on that or help managing my expectations would be appreciated.1.6KViews0likes17CommentsBIG-IP 17.0 ASM Cookie based allow requests
Is it possible to allow requests through the ASM if the client sending the request has a unique cookie with a particular value? I want to whitelist these requests based on this cookie. If this is possible would someone please share with me how this is accomplished?Solved1.2KViews0likes1CommentiRule needed to clear specific cookies from particular domain
Recently we moved our peoplesoft system to a subdomain of our DNS space. So instead of all our VIPs being for example, prod.abc.com they are now prod.ps.abc.com Peoplesoft uses a cookie for single-signon and some other features. The primary cookie is PS_TOKEN, but there are others as well. This move, for the most part, was seamless. However we have a particular case generally involving Safari on mac where the browser can submit the old domain token (cookie), which will sometimes cause the browser to "loop" the guest authentication page hundreds, or thousands of times a minute. We have demonstrated that clearing the old domain cookies will solve the issue. We have demonstrated this using a static webpage with some javascript that is hosted on an address on the old domain (abc.com). If a browser with the "old" cookie visits our page in between, then it is cleared and works. This is a rather manual solution, and redirecting everyone there before logging in would seem to be one solution - but that will not work as we have some deep links that would be broken in that case. What I desire (and have tried to create a few ways) is an iRule to: Check for the existence of the cookie PS_TOKEN (and possibly others) Check that the cookie domain of that cookie(s) is .abc.com If so, delete it (or if necessary set it's expiration to -1, which is what our js had to do) Then pass the request on through to wherever it was headed to start with. Ideally using the pool already defined for the particular virtual server. I haven't been able to get even the basics to seem to work. So I dropped back to seeing if the cookie is even being read by the F5, so here is where I sit now: when HTTP_REQUEST { if {[HTTP::cookie domain "PS_TOKEN"] contains ".abc.com"} { HTTP::respond 200 content {found abccom cookie} } else {HTTP::respond 200 content {did not find cookie} } } This never finds the cookie (at least it doesn't tell me it did). Any help and direction is most appreciated.1.1KViews0likes8CommentsCookie Encryption - duplicate cookies
TL;DR has anyone written code to deduplicate cookies before the cookie encryption feature is used? We had a ticket C1649037 to do with the Cookie Encryption breaking if the cookie was duplicated in the server's response headers. e.g. Server says: set-cookie A hello set-cookie A hello F5 told to encrypt A says: set-cookie encrypted gfddsgde34fwqf34 set-cooke A hello e.g. F5's Cookie encryption was only encrypting one copy of a set-cookie header in the server's response. Its a minor edge case, although for the vendor we spotted it with duplicate the session cookie in response to a successful login request so the session cookie doesn’t get encrypted. Also leaking the plain text of some cookies may make cryptanalysis even easier ;) Since the ticket was raised, we mentioned it to PortSwigger Web Security, who write BurpSuite security testing tool, and they added a duplicate cookie test (they are really good with these kinds of requests). Since then it has become clear: 1) the vendor is not going to remove the duplicate cookies any time soon. 2) duplicated cookie headers are very common in web applications, although usually it is deletion where it goes wrong as the session headers are written and then the deletion. 3) HTTP/2 header compression makes it all the more complicated to diagnose as you need to ensure you have the same protocol version as the browser seeing the issue, since HTTP/2 effectively dedups cookies for you. As such I’m minded to finally address the issue by fixing the F5's behaviour. Presumably de-duplicating cookie headers before encryption. Has anyone written this already? Should be easy, but I vaguely recall at the time that the cookies were presented as an associative array. The “best” solution would be for a supported change to the F5 Cooke Encryption feature, that always prefers later cookies headers with the same name when encrypting a request from the server to the client, as this is the RFC compliance resolution that the browser should do. Cookie encryption is notoriously tricky to do right and generally shouldn't be relied on. Here we are treating it as an additional measure to discourage poking at cookies, and to avoid the issue with sensitive data in the cookies being stored in the browser for long duration. Rather than trying to obscure a known cookie parsing weakness (down this road lies madness and being hacked).Solved1.1KViews0likes2CommentsModified domain cookie TSPD_101
Based on the article we know that the cookie TSPD_101 can be set by ASM even there's no Proactive Bot Defence or DoS-Profile aktive. We have set the type of the cookie with name: * to Enfored, which means that a cookie set (at server side) may not be changed by the client. Interesting is that ASM complains about TSPD_101 has been modified. Do we have to define the TSPD_101 cookie explicit with type Allowed?899Views0likes1Commentirule to remove all cookies
Hello, we are testing an irule to remove all cookie from the client browser after an idle time, the cookie for TCP isn't what we are looking for rather than the actual cookie sent to the server. any suggestion on how to achieve this, if I inserted a cookie manually I want the irule to delete it after I refresh the page. we are testing this on BIG-IP LTM ?irule example : when HTTP_REQUEST { } when HTTP_RESPONSE { set cookieNames [HTTP::cookie names] #array of cookies foreach aCookie $cookieNames { #adding the cookies to the array in a varaible aCookie HTTP::cookie remove $aCookie #removing the virable } }899Views0likes1CommentF5 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!812Views0likes0Comments