Forum Discussion

Hugo_Frauches_2's avatar
Dec 11, 2018
Solved

ASM Transparent mode blocking CORS requests

Hello community,

 

I would like to know if anyone have seen or had an issue with CORS (Cross-Origin Resource Sharing) and ASM, i have an problem with Javascript request that its been blocked by CORS policy on browser when i assign the the ASM profile on the virtual server, the main issue is that the ASM profile its an newly created ASM policy in transparent mode (It should not block anything), and i can not see any violation on the ASM>Events Logs.

 

Im sure that the ASM profile its causing this issue with the site, i made some tests and after removing the ASM profile from the virtual server there is no error from CORS in the browser. I also have searched abou this on DevCentral and found that this feature its from Proative Bot Defense, and its configured in DoS Profile, the problem is that i do not have an DoS profile on the virtual server, and its has became very diffcult to find the root cause of this.

 

Here iss on example of the request blocked in Google Chrome when the ASM profile its assign:

 

Access to XMLHttpRequest at 'https://app.host-a.com/Geral/MasterPage?pais=a` from origin 'https://www.host-b.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Do you guys have a clue were should i search for this strange behaviour ?

 

  • Hi Hugo,

     

    Thanks for the update. I agree, this is unacceptable. Never encountered something like this with ASM and I have dealt with CORS many times before. You can play with the CORS configuration through ASM or with an irule, I think that this is what I will do.

     

11 Replies

  • Just found out that the ASM its removing the Security Headers from response, and then causing CORS erros for the clients.

    Removed Headers:
    
    Access-Control-Allow-Origin: https://www.app.com
    Access-Control-Allow-Credentials: true
    Access-Control-Allow-Methods: GET, POST
    Access-Control-Allow-Headers: Content-Type, *
    

    in fact the headers are presented in HTTP_RESPONSE (APP>F5) but are removed in HTTP_RESPONSE_RELEASE (F5>CLient) by ASM.

    Could this be an BUG or some feature by design? Because ASM transparent mode should not block/change anything in the request...

  • Stumbled upon very similar issue yesterday. When ASM is configured( simple profile ) even in transparent mode, users on mobile chrome receive CORS error on certain iframes. When ASM is disabled, everything works flawlessly. Need to verify if ASM is striping down the CORS headers...

     

    • Hugo_Frauches_2's avatar
      Hugo_Frauches_2
      Icon for Cirrus rankCirrus

      Hello Alex,

      In fact the ASM does this, the F5 support told me this its by design on ASM:

      "If you do not enable cross-domain request enforcement, the system removes all cross-origin request headers and CORS is not allowed for the URL."

      For me this its unacceptable, F5 ASM shouldnt do this by default, because we have an feature called "transparent mode" and this CORS protection should be disabled and allowing * (Wildcards) by default. I have requested an RFE for this.

    • rodolfosalgado_'s avatar
      rodolfosalgado_
      Icon for Altostratus rankAltostratus

      I just had the same problem in my F5 BIG IP ASM 14.1.0.1. If I remove the WAF everything works flawless, I would expect at least the WAF in transparent mode to work but that isn't the case either...

       

    • rodolfosalgado_'s avatar
      rodolfosalgado_
      Icon for Altostratus rankAltostratus

      After opening a ticket with the F5 they gave the following irule as solution (known bug = https://support.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/related/relnote-supplement-bigip-14-1-0-1.htmlA746394-1ğŸ˜ž

      Setup an irule on a virtual server:

      when HTTP_RESPONSE {
          array set header_list { }
          foreach header_name [HTTP::header names] {
              if { [string tolower $header_name] starts_with "access-control-" } {
                  set header_list($header_name) [HTTP::header $header_name]
              }
          }
      }
      when HTTP_RESPONSE_RELEASE {
          foreach header_name [array names header_list] {
              if {!([HTTP::header exists $header_name])} {
                  HTTP::header insert $header_name $header_list($header_name)
              }
          }
      }
      
  • Hi Hugo,

     

    Thanks for the update. I agree, this is unacceptable. Never encountered something like this with ASM and I have dealt with CORS many times before. You can play with the CORS configuration through ASM or with an irule, I think that this is what I will do.

     

  • If you have a limited number of URL, you can selectively add them to your ASM policy and more CORS enforcement into the policy.

     

  • The bugfix says its fixed in 14.1.2.1. But i still see it in 14.1.2.6

    • What build do you have?

      Do you see the same behavior - no removing CORS headers without ASM and removing, in case of attach ASM policy?

      What do you have in "HTML5 Cross-Domain Request Enforcement" tab for URL with CORS headers?

       

      Thanks, Ivan