How Does a WAF Work?
What is a WAF and How Does it Work?
WAF ( Web Application Firewall) is the first line of defense between the app and the internet traffic. It monitors and filters internet traffic to stop bad traffic and malicious requests.The WAF is a crucial security solution that ensures the availability and integrity of web services.
It functions as a reverse proxy by serving as an intermediary that safeguards the web app server against malicious clients.
8 Methods WAF Uses to Block Malicious Attacks
1. IP Fencing
It is the simplest method of protection. If you know a malicious request is coming from a specific IP address, deny them with WAF blacklisting. It relies on a static set of information.
AppTrana employs reputation databases such as the HoneyPot Project and spamhaus DB to identify certain IPs and subsequently block requests from those IPs.
2. Geo-fencing and Geo-blocking
Geo-fencing is a technique used by WAF to create a virtual perimeter or boundary around a specific geographical area. When a user’s IP address falls within the predefined boundary, the WAF can allow or restrict access to certain content or features.
AppTrana utilizes Geo IP databases such as MaxMind DB to allow or deny requests.
You can also create Geo-blocking rulesets with the WAF, a more restrictive technique to completely block access from specific regions. For example, if your ecommerce site only caters to US customers, you can restrict access from other regions using this feature.
3. Request Inspection
Inspection is integral to the WAF’s strategy to exert complete control over requests and responses. By examining the contents of requests, the WAF can match them against known good/bad strings and values to distinguish between legitimate and malicious requests.
WAFs analyze traffic using multiple filter layers, which can detect zero-day attacks, client-side attacks, bot attacks (such as DDoS attacks), virus files, and web application vulnerabilities.
The most advanced WAFs can decode and analyze HTTPS traffic, XML, JSON, and other widely used data transfer formats.
By examining the headers, WAF detects specific patterns or anomalies that may indicate malicious activity, such as a malformed user agent or suspicious cookie values.
The header of an HTTP request contains essential information such as the user agent, content type, cookies, and the HTTP method being used (e.g., GET, POST).
Each comprises text strings and has a wide range of potential combinations.
Therefore, WAF inspects each request header individually to identify potentially malicious values rather than relying on predefined allowlists.
GET /login HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
Cookie: PHPSESSID=abcdef1234567890; username=admin; password=admin123
In this example, the request includes a Referer header that points to a malicious website (http://evil.com). The web server uses the Referer header to track the request’s source.
By including a malicious Referer header, the attacker can attempt to trick the web server into believing that the request is coming from a trusted source.
The attacker has also included a Cookie header that contains the session ID (PHPSESSID=abcdef1234567890) as well as the username and password of an administrator account (username=admin; password=admin123).
By including these values in the Cookie header, the attacker can attempt to gain unauthorized access to the web application.
By inspecting these headers, the WAF can detect the malicious Referer header and the suspicious contents of the Cookie header. Further, it blocks the request and prevents the attack from succeeding.
WAF also analyzes the user agent string sent by the browser for other indicators, such as the unusual browser settings and signs that the traffic is automated.
Request Body Inspection
WAF further examines the request body, query parameters, and other elements of the request to identify and block potential threats to the web application.
WAF examines every byte of data within a payload to determine specific combinations of alphanumeric characters that may indicate an exploit attempt targeting a vulnerability.
Suppose a web application has a search feature that allows users to search for products by entering keywords in a search box.
An attacker may exploit this feature by submitting a specially crafted input containing a SQL injection payload.
For example: ‘apple’ OR 1=1;– – which would then be executed as the following SQL query:
SELECT * FROM products WHERE name = 'apple' OR 1=1;--
This query is designed to bypass the authentication mechanism and retrieve all products from the database.
The OR 1=1 part is added to make the query always return true, and the — at the end is used to comment out the rest of the query and prevent any errors.
If the WAF relied solely on predefined allowlists, it might be unable to detect this attack because the query contains valid syntax.
However, by inspecting each request individually and analyzing the contents of the query, a web application firewall can detect the SQL injection payload and block the request.
WAF also analyzes the query and looks for keywords commonly used in SQL injection attacks, such as OR, UNION, SELECT, and DROP. If any of these keywords are detected, the WAF can block the request and prevent the attack from succeeding.
WAF’s threat detection capabilities go beyond SQL injection and cover other frequently occurring high-risk threats like XSS and XXE.
4. Response Inspection
WAF monitors and analyzes the traffic leaving a web application to identify and block any potentially malicious or unauthorized activity.
It verifies the content of packets to ensure that the content type matches the requested resource’s expected content type. For example, if a client requests an image file, the WAF can verify that the response is an image file, not an executable file or malicious content.
The WAF can validate that the response code returned by the web application is valid and expected. For example, if a web application returns a 404-error code (page not found) for a resource that should exist, the WAF can identify this potential attack.
Web application firewall has the capability to prevent data leakage by masking or blocking responses that contain sensitive information, like credit card numbers or any other custom data.
An employee tries to upload a file containing sensitive data to an external file-sharing website. The WAF detects the data transfer attempt and checks if the file contains any sensitive information that should not be shared externally. The WAF scans the file for patterns or keywords that match the organization’s data classification policies.
If the file contains sensitive information, the WAF blocks the upload and sends an alert to the security team. The security team can then investigate the incident and take appropriate action, such as revoking the employee’s access or launching a further investigation.
5. Security Rules
When a request is received, the WAF analyses its payload and compares it to its rules or signatures.
A WAF typically has two types of security rules: pre-defined and custom.
The vendor pre-configures pre-defined rules and is designed to protect against common attacks, such as SQL injection, cross-site scripting (XSS), and other known vulnerabilities. These rules are generally updated regularly to address emerging threats.
AppTrana inspects each application zone and determines the applicable threats by considering the OWASP Top 10 app and API vulnerabilities, along with additional attack vectors that have been pre-programmed into the WAF.
Pre-defined rule set includes protection against:
- SQL Injection
- XSS Attacks
- Local and Remote File Inclusion
- Size Restrictions
- Command Injection
- Unknown Bad Inputs
- Malicious file extensions (e.g., .php, .exe)
- Directory traversal characters (e.g., “..”)
- Command injection payloads
- Java Deserialization payloads
- Localhost in the host header
- PROPFIND HTTP method
- Shell metacharacters (e.g. |, >, <, )
- Arbitrary code execution payloads
- LDAP injection payloads
- XPath injection payloads
- XML External Entity (XXE) payloads
Here is an example of a WAF pre-defined rule to block an XSS attack:
SecRule ARGS "@rx <script[\s\S]*?>[\s\S]*?</script>" \
msg:'XSS Attack Detected',\
tag:'OWASP Top 10',\
This rule checks the request parameters (ARGS) for the presence of the <script> tag, which is commonly used in XSS attacks. If the rule matches, it will trigger an action to block the request (block), log the event (log), and send a message to the server operator (msg).
The rule also includes a tag to indicate that it addresses one of the OWASP Top 10 vulnerabilities and sets the severity level as critical.
The website or application owner creates custom rules to address specific security concerns that are unique to their environment. These rules can be tailored to fit the specific needs of the application and can provide additional layers of protection beyond the predefined rules.
The video showcases how Indusface managed services team developed a custom rule that virtually patched the Remote code execution (RCE) vulnerability detected in Spring Framework within 24 hours of the zero-day vulnerability being reported. Managed services come bundled with AppTrana WAF’s premium and enterprise plans.
Automatic Rules Generation
As the WAF continues to analyze traffic and identify patterns of emerging threats, it can automatically generate policies to protect against them. This can help reduce the time and effort involved in manually creating policies while protecting against new and evolving threats that may not yet have established signatures or rules.
A new attack involves sending specially crafted SQL queries to the application to bypass authentication and gain access to sensitive data. The WAF can analyze the traffic and identify the specific SQL syntax used in the attack. The WAF can then generate policies to block this specific syntax and prevent the attack from succeeding.
Once the security policy has been generated, WAF applies the policy to secure the application. This is where security experts’ support is required. The support team can manually fine-tune the security policy to decrease false positives and negatives.
6. Anomaly Scoring
If a rule matches, WAF applies a score for each deviation in a request as part of its overall approach to threat detection and response. This is known as a “risk-based approach.”
The idea behind the anomaly scoring system is that not all deviations or anomalies in a request are equally significant or indicative of an attack. By assigning a score to each variation or anomaly, the WAF can determine the overall risk level of the request and decide whether to block or allow it.
The WAF employs a variety of factors to assign scores, including the severity and type of deviation, the context of the request, and the behavior of the user making the request.
- A simple deviation like a misspelled URL might only receive a low score
- A more serious deviation, like an attempt to inject SQL code, might receive a higher score.
The WAF can also use the score to trigger different actions, such as
- Blocking requests with a high score
- Allowing low scores
- Proceeding with additional verification for requests with an average score
7. DDoS Rate Limits
DDoS rate limits restrict the number of requests that a particular IP address can send to a server within a given timeframe. The rate limit is typically set based on a predetermined threshold that is considered safe for normal traffic, and any requests that exceed this limit are blocked.
By enforcing DDoS rate limits, a WAF can effectively prevent an attacker from overwhelming the server with a barrage of requests. This helps ensure that legitimate users are still able to access the server and that business operations can continue uninterrupted.
Let’s say that a business has a website that typically receives around 1,000 requests per minute. To protect against DDoS attacks, the business sets a DDoS rate limit of 2,000 requests per minute for any given IP address. This means that if an IP address sends more than 2,000 requests per minute to the server, the WAF will block those requests.
Now, suppose that an attacker launches a DDoS attack against the business’s website, using a botnet to flood the server with requests. Even if the attacker controls thousands of compromised devices, the WAF will block any IP address that exceeds the 2,000 requests per minute threshold. This effectively limits the impact of the DDoS attack, allowing the website to continue operating normally for legitimate users.
The static rate limit mechanism’s primary flaw is its reliance on a fixed traffic threshold. As a result, attacks may not be detected until the threshold is reached, leading to slow or inadequate attack detection.
The video highlights how AppTrana’s behavioral analysis for DDoS rate limiting overcomes this challenge.
8. Bot Mitigation
WAFs can analyze cookies sent by the browser and check them to the databases of known bot cookies such as Udger, Checktor, and Whatisyourbrowser DB.
The bot control components include but are not limited to:
- CAPTCHA challenges
- Rate limiting
- Bot Pretender
- Web Scraping Protection
- Bot Intelligence (Fingerprints, IP, behavioral patterns)
WAF employs behavior-based analyses to detect automated traffic. This can include analyzing the speed and frequency of requests, the order in which pages are accessed, and other factors that can help differentiate between a bot and human behavior.
Bot protection includes the following goals:
- Detect bots from human
- Identify good bot vs. bad bot
- Allow good bots and block bad bots
- Detect the origin of the bot and block the IP address
- Analyse bot behavior and rate limit potential bots
By integrating these methods, WAFs can successfully distinguish between human and bot traffic, identify malicious traffic, and provide an effective defense against DDoS and bot attacks.