csrf
5 TopicsSet the SameSite Cookie Attribute for Web Application and BIG-IP Module Cookies
Problem this snippet solves: UPDATE: Note that the work for SameSite is evolving rapidly and this new entry should be considered over the iRule contents below. Chrome (and likely other browsers to follow) will enforce the SameSite attribute on HTTP cookies to Lax beginning soon (initial limited rollout week of Feb 17th, 2020) which could impact sites that don't explicitly set the attribute. This iRule will set the SameSite attribute in all BIG-IP and app cookies found in Set-Cookie headers. Note that this would not modify cookies set on the client using javascript or other methods. Contributed by: hoolio How to use this snippet: Apply the iRule to the appropriate virtual servers. Code : when HTTP_RESPONSE_RELEASE { # Set all BIG-IP and app cookies found in Set-Cookie headers using this iRule to: # none: Cookies will be sent in both first-party context and cross-origin requests; # however, the value must be explicitly set to None and all browser requests must # follow the HTTPS protocol and include the Secure attribute which requires an encrypted # connection. Cookies that don't adhere to that requirement will be rejected. # Both attributes are required together. If just None is specified without Secure or # if the HTTPS protocol is not used, the third-party cookie will be rejected. # # lax: Cookies will be sent automatically only in a first-party context and with HTTP GET requests. # SameSite cookies will be withheld on cross-site sub-requests, such as calls to load images or iframes, # but will be sent when a user navigates to the URL from an external site, e.g., by following a link. # # strict: browser never sends cookies in requests to third party domains # # Above definitions from: https://docs.microsoft.com/en-us/microsoftteams/platform/resources/samesite-cookie-update # # Note: this iRule would not modify cookies set on the client using Javascript or other methods outside of Set-Cookie headers! set samesite_security "none" # Log debug to /var/log/ltm? (1=yes, 0=no) set cookie_debug 1 set cookie_names [HTTP::cookie names] if {$cookie_debug}{log local0. "[IP::client_addr]:[TCP::client_port]: \[HTTP::header values {Set-Cookie}\]: [HTTP::header values {Set-Cookie}]"} if {$cookie_debug}{log local0. "[IP::client_addr]:[TCP::client_port]: \$cookie_names ([llength $cookie_names]): $cookie_names"} foreach a_cookie $cookie_names { # Remove any prior instances of SameSite attributes HTTP::cookie attribute $a_cookie remove {samesite} # Insert a new SameSite attribute HTTP::cookie attribute $a_cookie insert {samesite} $samesite_security # If samesite attribute is set to None, then the Secure flag must be set for browsers to accept the cookie if {[string equal -nocase $samesite_security "none"]} { HTTP::cookie secure $a_cookie enable } } if {$cookie_debug}{log local0. "[IP::client_addr]:[TCP::client_port]: Set-Cookie header values: [HTTP::header values {Set-Cookie}]"} } Tested this on version: 13.04.8KViews4likes5CommentsSet the SameSite Attribute for LTM Persistence Cookies
Problem this snippet solves: Chrome (and likely other browsers to follow) will enforce the SameSite attribute on HTTP cookies to Lax beginning soon (initial limited rollout week of Feb 17th, 2020) which could impact sites that don't explicitly set the attribute. This iRule will add the SameSite attribute to LTM persistence cookies. Contributed by: hoolio How to use this snippet: Apply the iRule to the appropriate virtual servers. Code : when HTTP_RESPONSE_RELEASE { # Log debug to /var/log/tlm? 1=yes, 0=no set persist_cookie_dbg 1 # Set the SameSite cookie attribute value to one of: Strict, Lax or None # # None: Cookies will be sent in both first-party context and cross-origin requests; # however, the value must be explicitly set to None and all browser requests must # follow the HTTPS protocol and include the Secure attribute which requires an encrypted # connection. Cookies that don't adhere to that requirement will be rejected. # Both attributes are required together. If just None is specified without Secure or # if the HTTPS protocol is not used, the third-party cookie will be rejected. # # Lax: Cookies will be sent automatically only in a first-party context and with HTTP GET requests. # SameSite cookies will be withheld on cross-site sub-requests, such as calls to load images or iframes, # but will be sent when a user navigates to the URL from an external site, e.g., by following a link. # # Strict: browser never sends cookies in requests to third party domains # # Above definitions from: https://docs.microsoft.com/en-us/microsoftteams/platform/resources/samesite-cookie-update set samesite_security "none" # Exit this rule if the VS does not have a persist cookie profile attached if {not [PROFILE::exists persist cookie]}{ if {$persist_cookie_dbg}{log local0. "[IP::client_addr]:[TCP::client_port]: Exiting because there isn't a cookie persist profile on the VS"} return } # Get the persistence cookie profile cookie name # [PROFILE::persist mode cookie cookie_name] returns: # - a runtime error, if a persist profile isn't defined on the VS # - a null length string, if the cookie persist profile doesn't have a cookie name set (which is the default) # - the cookie name, if the cookie persist profile has a custom cookie name set if {[set persist_cookie [PROFILE::persist mode cookie cookie_name]] ne ""}{ # Above command returned a custom cookie name from the persistence profile if {$persist_cookie_dbg}{log local0. "[IP::client_addr]:[TCP::client_port]: \$persist_cookie=$persist_cookie"} } else { # Cookie persist profile does not have a custom cookie name set, so derive it from the pool name, using the format BIGipServer set persist_cookie "BIGipServer[LB::server pool]" } if {$persist_cookie_dbg}{log local0. "[IP::client_addr]:[TCP::client_port]: Parsed persist cookie name=$persist_cookie"} # Set the samesite cookie attribute on the persistence cookie switch [string tolower $samesite_security] { "none" { # samesite=none requires the Secure flag also be set HTTP::cookie attribute $persist_cookie insert "SameSite" "None" HTTP::cookie secure $persist_cookie } "lax" - "strict" { HTTP::cookie attribute $persist_cookie insert "SameSite" $samesite_security } default { if {$persist_cookie_dbg}{log local0. "[IP::client_addr]:[TCP::client_port]: Invalid SameSite attribute value ''. \ Needs to be one of None|Lax|Strict"} } } # Log the Set-Cookie header values if {$persist_cookie_dbg}{log local0. "[IP::client_addr]:[TCP::client_port]: Set-Cookie header values=[HTTP::header values {set-cookie}]"} } # Log examples: # No cookie persist profile enabled on the virtual server: : 10.1.1.8:51193: Exiting because there isn't a cookie persist profile on the VS # Default cookie persist profile enabled on the virtual server (no persist cookie name is explicitly defined) : 10.1.1.8:51215: Parsed persist cookie name=BIGipServer/Common/http_pool : 10.1.1.8:51215: Set-Cookie header values={BIGipServerhttp_pool=117506314.20480.0000; path=/; Httponly; Secure} # Custom cookie persist profile enabled on the virtual server with a custom cookie name defined as "my_persist_cookie" : 10.1.1.8:51255: $persist_cookie=my_persist_cookie : 10.1.1.8:51255: Parsed persist cookie name=my_persist_cookie : 10.1.1.8:51255: Set-Cookie header values={my_persist_cookie=117506314.20480.0000; path=/; Httponly; Secure;SameSite=None} Tested this on version: 13.03.8KViews3likes3CommentsUsing ASM and CSRF with Angular
Does any one have experience using ASM CSRF with the Angular framework? I see the in normal responses for HTML that the CSRT URL parameter is appended to for subsequent requests. However, our Angular application does not have this occur. According to the docs for angular it looks, by default, for a cookie named XSRF-TOKEN on the first HTTP request and then replies with subsequent requests with an HTTP header X-XSRF-TOKEN. Is there a way to fill in the value from the default "CSRT" parameter so that Angular can find this? I can't find any docs on how CSRT is generated from ASM.599Views0likes5CommentsCSRF Protection not Working
implmentation of CSRF protection is very simple on f5 device , unfortunately it didn`t work with me and every attempt from my browser " firefox " to access the authenticated URL as "/authenticated/* " is blocked ... as shown below , here are the javascript token added on page response but why f5 cannot detect this CSRF token !!! script type="text/javascript"> !-- window["_csrf_"] = "080672e6ab84a0008fd244ab2571f208bfe3204574c6e527769d1127606cff47e44d7efd81a8416297bbec25adbe3c55a10fa3a3ec1061e32adbdd05c697677a31e70c3f284c5b441b92c973e9c7ef6ef767f94488efa7a7f1118c01228fbb42a420ea3f9e8401f18eb2b9c69a16bd35cbf424e7cdd787c2b8178f070c4942f7cfa56107dca8e2d31bbf8aaa476f1472704dc1ba72e035ff6c132d7ad8f384aceea21b0c29b269e1"; //-- Questions: 1- is there any other CSRF tokens should appear somewhere as i studied it should appear also on url as a paramter ?? 2- what are the prerequisites for enabling CSRF ?599Views0likes3CommentsASM insert CSRF although not specify URL
Hi We're using LTM/ASM with v.12.1.3 and right now we see issue as we have enable CSRF protection but we didn't specify and URL in URL list. From my understanding, F5 should insert csrf in case we specify URL in URL list. Why F5 insert it although we not specift URL list? Is it a bug? ps1. we have issue when using IE11 but we didn't have issue when using chrome. ps2. when using IE11, issue is occur intermittently. Thank you299Views0likes3Comments