F5 CORS

What is CORS?

F5 CORS can mean a few different things. Probably the most common, which we’ll look at here is enabling Cross-Origin Resource Sharing for the applications behind the BIG-IP. Alternatively, you can check out our article on actually enabling the BIG-IP to support CORS for the management GUI. You can also read a little bit about what CORS is. Another topic related to F5 CORS is what the ASM will allow and block when it sees CORS. Configuration of that is discussed in this F5 ASM CORS Support post here.

First, a quick recap on CORS. CORS is used when the browser is making an automated request to a site that is different than the one the user put in their browser. It’s a protection built-in by the browser that javascript isn’t allowed to send data all over the place. Often though, this is exactly what the application architects need to happen. In comes CORS. Basically, the site that is getting a request from a non-local origin needs to allow the request to come in.

CORS has two types of requests, simple requests and requests that require more work. For basic requests, the browser is notified that this is OK with a simple header. For more complicated requests, you need to what’s called a pre-flight request to get some additional data before sending the actual request. What makes them complicated or simple is outside the scope of this post, but your application people should be able to tell you which of the methods you need to support.

The Mozilla CORS page gives a lot more detail if you want to get into the details of the requests.

Configuring F5 CORS

For the simple one, you just need to insert the “Access-Control-Allow-Origin:” header with the value of the domain that should be allowed to make the cross origin request. If you want any website on the internet to be allowed, just set an asterisk.

You can do this with just an HTTP profile and the header insert, or you can do it in an iRule and insert the header based on whatever conditions you want.

Preflighted requests are a bit trickier. First, you’ll intercept the OPTIONS request, and respond with the proper information for the client. Next, the client will send the actual request.

Rather than reinvent the iRule, you can take a look at this thorough example on devcentral: F5 cors iRule

One thing to note about the iRule, create a datagroup outside of the iRule as shown in one of the comments. That’s what they are there for, so use it.

Good luck, and feel free to comment if you’re having issues getting the iRule working either here or on DevCentral.

2 Replies to “F5 CORS”

  1. What Makes a F5 WAF Advanced?

    ==========================================

    F5 WAF(ASM) Batch Starting From 4th Jan 2020.

    As the threat landscape evolves, so must our security controls and countermeasures. The most advanced perimeter threats for data loss or exfiltration occur at the application layer, rendering most next-gen firewalls (NGFW) and intrusion prevention systems (IPS) much less effective. This effect is compounded by the fact that most communications are moving to encrypted data channels not well-supported by NGFW or IPS, particularly at scale. Web application firewalls (WAF) are specifically designed to analyze each HTTP request at the application layer, with full decryption for SSL/TLS.

    In recent years, most WAF technologies have remained largely unchanged, as passive filter-based detection systems, much like the related NGFW and IPS technologies. WAF systems apply protocol compliance (ensuring a well-formed request) and signature comparisons (ensuring no known malicious content) to filter and block potential attacks. Additional features have been added to enable session- and user-awareness to fight hijacking and brute force attacks, and IP reputation feeds are applied to attempt to filter out known-bad sources such as botnets, anonymizers, and other threats. These are still largely passive technologies at the data center perimeter, with very limited capacity for interrogating the client.

    There are a few things we know about the current threat landscape:

    Most threats are automated in nature. Attackers automate scans for vulnerabilities. They automate resource hoarding such as purchases of tickets or sneakers for grey-market resale. Distributed denial-of-service (DDoS) attacks are fully-automated to enable the kind of 1Tbps+ attack traffic volume that has become commonplace. Automation is difficult to detect because it is often designed to mimic good traffic and go undetected. Technologies like CAPTCHA have been used to detect such automation, but these verification methods prove ineffective over time and impact the experience of legitimate users.

    Credential stuffing is a specific kind of automated attack which leverages the billions of known username and password combinations from prior breaches. Use of stolen credentials was the most prevalent type of application attack of 2017, according to recent threat reports. These attacks prey upon password re-use common for the average citizen of the Internet. Credential stuffing is particularly difficult to detect because these requests not only look normal, they are often “low and slow” by design to avoid detection as a brute force attack.

    Malware is pervasive and is used to exploit weaknesses in browsers and the users operating those browsers. Malware has many delivery methods, from email attachments to malicious links on social media and in ads. These compromised machines are used to attack other websites for DDoS, data theft, and resource hoarding. Limited detection and mitigation methods are available unless the client machine is managed by an experienced IT infosec team.

    DDoS attacks are not just volumetric in nature. Many attacks are designed to cause resource exhaustion somewhere in the application stack, the application servers, middleware, or back-end database. Detecting these conditions can be difficult since the traffic conforms to most standard input validation checks.

Leave a Reply

Your email address will not be published. Required fields are marked *