How To Protect Your Applications from Cross Site Request Forgery (CSRF) with F5 Distributed Cloud

Introduction:

CSRF (Cross-Site Request Forgery) is an attack vector in which the victim user that visits a sensitive site such as a bank account, is lured to click on a malicious link attempting a fraudulent operation on that sensitive site. The link may be sent over email or in a hidden frame on another site. Because CSRF attacks specifically target state-changing requests, F5 Distributed Cloud (XC) WAF only acts on HTTP requests that have a state-changing method (POST, PUT, etc.).

When F5 XC WAF is evaluating a request, it ensures either the source or referrer headers are present and compares their values. If the source origin is missing or the origins do not match the request is rejected. The exception to this being if the source origin has been added to the policy as valid. I will show these distinctions in the following section.

The impact of a successful CSRF attack is limited to the capabilities exposed by the vulnerable application. For example, this attack could result in a transfer of funds, changing a password, or making a purchase with the user’s credentials. CSRF attacks are used by an attacker to make a target system perform a function via the target's browser, without the user’s knowledge

CSRF is also known by several other names, including XSRF, "sea surf," session riding, cross-site reference forgery, and hostile linking. CSRF is listed under the A5 category in the OWASP Top 10.

In this article, I will show how to easily protect your application from CSRF and in doing so, help protect your site visitors from the same.

Configuration:

This article will assume you have a F5 Distributed Cloud Console Account and have already configure a HTTP Load Balancer that is protecting an application.

Select Web App and API Protection:

Verify the correct Namespace:

I currently have one Load Balancer to choose from, your environment may be different.

Click the 3 ellipses on the right side of the page of the Load Balancer you wish to add CSRF Protection to.
When selection changes, select Manage Configuration.

I want to point out the flexibility of F5 XC and how you could have your Load Balancers configured.

If you notice the first image, this has one domain for this one Load Balancer.

In this second image of your Load Balancer, you could just as easily have multiple domains hosted on this Load Balancer. This distinction is important when you configure CSRF protection in the next section.

Notice along the left side are all the configuration items available for your Load Balancer. This is just a view option.

To Edit click the Edit Configuration to the right.

Once you click Edit Configuration, you can either scroll down to Web Application Firewall or click the Web Application Firewall label on the left side.

In the Cross-Site Request Forgery Protection section you see it is not configured.

Click Configure

Here you have two options. “All HTTP Load Balancer Domains” and “Specified Domains.’ If you have multiple domains as above you could protect them all or a subset of the domains by specifying which domains you would allow as the Source Domain.

For this demonstration, I am going to configure a specified Domain.

Click Apply and then Click Save and Exit at the bottom of the pages

You have now completed all the steps to protect yourself from Cross-Site Request Forgery.

Demonstration:

Now, I will show a few results of the following curl commands:

•	curl -X POST  https://byerlynap.tme-lab-works.distributedappsonvolt.org -vvv

•	curl -X POST -H "origin: sr.f5-demo.com" https://byerlynap.tme-lab-works.distributedappsonvolt.org -vvv

•	curl -X POST -H "origin: byerlynap.tme-lab-works.distributedappsonvolt.org" https://byerlynap.tme-lab-works.distributedappsonvolt.org -vvv

Only the last curl command will return a 200 OK. The first two will fail with a 403 Forbidden, as they are either missing an origin/referer header or the header they are supplying is not included in the allowed list above.