1

I know that F5's Big-Ip ASM offers protection against CSRF regarding links and forms.

However, when it comes to AJAX calls their documentation is somewhat ambiguous. I understand that they DO NOT support CSRF in the context of AJAX calls, but I have no prior experience with this particular system.

I clearly understood that protections are offered regarding AJAX calls, but is CSRF one of those? Or is CSRF only for forms and inline links?

Vilican
  • 2,703
  • 8
  • 21
  • 35
niilzon
  • 1,587
  • 2
  • 10
  • 17
  • AFAIK, to any application firewall, they would not know if the request was issued from a form, a link or an AJAX petition, so if they offer protection from it, it should apply to every case, regardless of form. – NuTTyX Jan 09 '16 at 02:12

2 Answers2

3

It will depend on what F5 software version you have. In the past, ASM only operated by injecting the token in fields on static HTML POST forms, and could not address other kinds of request or client-side-scripting-driven interactions.

It looks like more recently the CSRF feature can now inject client-side script to:

  • Apply the CSRF token to GET forms and plain links. This is a really bad idea—you don't want to leak your CSRF tokens in URLs.

  • Frob the XMLHttpRequest prototype to inject a fixed-value custom header X-TS-AJAX-Request: true to bypass CSRF protection. This is workable but custom headers are the poor man's solution, compared to proper tokens; they have been vulnerable to edge-case attacks like that from Flash in the past.

These features, like much of what ASM does, are useful as a last-ditch/temporary workaround for when you have to deploy applications you know are insecure but you don't have the ability or permission to fix them properly. But if you can, it is much more reliable to address the problem in the application itself.

bobince
  • 12,494
  • 1
  • 26
  • 42
0

As far as i understood how CSRF is implemented, if a request does not contain CSRF information it is discarded. Regardless of how the request was constructed or where it originated from. CSRF adds depth to sessions, meaning a CSRF token not only offers session tracking and uniqueness, it can also be used to go back to an earlier state of a web application. Though this is not the intended use for CSRF, i"ve seen it used as such. I mention this because that's often how an ajax driven website handles a web application user experience ( pointing back to states )