Web applications are magnets for cyber attacks, like DDoS, SQL hacks, and XSS, which can steal data, cause financial problems, and damage your organization's image. Although web applications have countless benefits for users and businesses alike, it’s essential to prioritize security as much as usability and performance.
As a result, organizations enforce web application firewalls (WAFs) to prevent those attacks. But, your WAF is only as strong as its ruleset, and 65% of organizations report frequent WAF bypassing due to weak rulesets.
What are WAF Rules and How Do They Work?
A web application firewall (WAF) enforces rules that monitor, filter, and block incoming HTTP requests based on defined criteria. These rules, known as WAF rules, are configured to look for suspicious patterns, payloads, or behavior in web traffic and take action if malicious activity is detected, such as zero day or OWASP Top 10 attacks.
WAF rules consist of conditions and actions. The conditions specify what to look for in the request, such as a pattern in the URL, headers, or body. The actions define what the WAF should do if the conditions are met, like blocking the request or logging an alert.
For example, consider a WAF rule designed to block SQL injection attacks:
Condition: Check for specific keywords often associated with SQL injection, such as "SELECT," "INSERT," "UPDATE," "DELETE," "UNION," "DROP," "EXEC," and "OR."
Action: Immediately block the request from reaching the web application.
If an attacker tries to inject SQL code by sending a request like:
user_id=123 OR 1=1Using the rule, the WAF would identify the "OR" and "1=1" as suspicious SQL injection patterns and block the request, preventing the attack from proceeding.
These rules work by inspecting all layers of incoming HTTP requests before they reach the web application. As requests flow through the WAF, they are checked against the configured ruleset to identify attacks. If a rule is triggered, the WAF executes the defined action, like blocking the malicious request.
Usually, the best WAF tools come with predefined rule sets targeting common attacks like cross-site scripting and path traversal. Developers can also create custom rules tailored to their application's specific vulnerabilities.
What To Do if You Remove a WAF Rule
Removing or disabling a WAF rule can seriously impact your application. Sometimes, you might not even notice the impact until it's too late. So, here are some key things you can do to remove or disable a WAF rule:
Test in a staging environment first - Before disabling a rule in production, test the impact in a development environment that mirrors production.
Increase monitoring and alerts - When disabling a rule, boost monitoring and alerts to watch for suspicious activity that may indicate the rule was blocking an active threat. Have an action plan for responding to observed attacks.
Conduct regular audits - Periodically review all active and disabled rules to realign with the evolving threat landscape. Ensure the ruleset matches the latest application vulnerabilities and attack techniques.
Have a rollback plan - Be prepared to quickly re-enable the rule if disabling it has adverse effects and causes an uptake in attacks.
Document all changes - Thoroughly document any rule changes, including disabling rules. Note the rationale, testing details, potential risks, and rollback process.
7 WAF Rules You Can Twilight
Let's see what WAF rules you can tweak or remove without affecting the security of your system.
1. SQL Injection Detection Rules
SQL injection detection rules look for patterns and signatures of SQL injection attacks in incoming HTTP requests. These rules help block SQL injection attempts by scanning user inputs, URLs, headers, and POST data for potentially malicious SQL syntax and commands.
Some common patterns these rules look for include:
Suspicious SQL keywords like SELECT, UNION, DROP, INSERT, etc.
Illegal characters like semicolons, single quotes, backticks, etc.
Comments used to terminate queries like /* */
Tautologies that evaluate to true, like 'OR 1=1'
Code for conditional errors like converting a string to an int
Calls to internal functions like SLEEP() or BENCHMARK()
However, if the web application does not use SQL databases and relies on NoSQL alternatives, these rules may be unnecessary and lead to false positives. The SQL syntax scanning would trigger blocks on legitimate requests without any vulnerability.
In such cases, removing these rules after a thorough web application testing process is recommended to reduce processing overhead on the WAF. But you should only do this if the app architecture confirms SQL is not a risk.
2. Local File Inclusion Rules
Local file inclusion (LFI) rules in a WAF block directory traversal attacks. In these attacks, the bad actor aims to access unauthorized files on the server by manipulating path names in the application.
Some common patterns these LFI rules look for include:
Suspicious sequences like ../../ to traverse folders
Requests with /etc/paths to access system files
Encoded variants of traversal sequences like %2e%2e%2f
Use of null bytes or encoded null bytes (%00) to break out of paths
Attempts to access sensitive files like /etc/passwd or .htaccess
These rules could cause false positives if the application intentionally allows users to upload files. For example, any file upload path containing sequences like /uploads/user1/file.txt may get blocked incorrectly.
In such cases, the rules could be fine-tuned only to block access to critical system files while permitting valid user uploads. For example, the rules could be adjusted to allow /uploads/ paths but still /etc/ and .htaccess access.
3. Outdated Signature Rules
Many WAFs have predefined rules containing signatures or patterns to detect old threats and exploits. These can include regexes, strings, or payloads to identify attacks like Code Red, Slammer, or older cross-site scripting vectors.
For example, rules may look for:
Specific user-agent strings used by exploit kits.
Known malicious file hashes.
Payloads associated with worms like Code Red.
Old virus signatures.
These rules were useful when the threats were active. However, as applications get patched and upgraded, these old threats are no longer relevant and can negatively impact application performance by using resources for scanning for irrelevant patterns. In such cases, removing or updating these outdated regex-based signature rules can help lighten the load on the WAF.
4. Excessive IP Blacklisting
Many WAF rules enable blocking or restricting requests from malicious IP addresses by maintaining blacklists of IPs associated with attacks, spam, or other abusive behavior.
For example, rules may blacklist:
Botnet C&C server IPs.
IPs flagged for brute force attacks.
Tor exit nodes.
Spam email server IPs.
Blocking IPs is an effective way to filter out high-risk traffic. Be aware that you may face issues when the IP blacklist rules become too broad, containing thousands of banned IPs, and legitimate users could get blocked.
Pruning the blacklists by removing inactive IPs, focusing only on active botnet controllers, and whitelisting trusted IPs helps prevent legitimate traffic from being blocked. The rules should be periodically reviewed to ensure the IP restrictions remain relevant and reasonable.
5. Redundant XSS Detection Rules
Many WAFs have multiple rules to detect cross-site scripting (XSS) attacks. This includes rules that look for:
Script tags like <script>.
Common script functions like alert().
Script protocols like javascript:
Script encoding/obfuscation.
DOM-based XSS vectors.
Having layers of overlapping XSS detection rules increases security coverage, but it can also cause performance issues. For example, if multiple broad rules are looking for <script> blocks, a single request will trigger 2-3 rules, leading to duplicated scanning and overhead.
In such situations, you can identify and remove redundant rules by comparing pattern similarities. You can also remove rules specific to old IE-based vectors when working with modern tech stacks.
6. Overactive Rate Limiting
WAFs enable rate limiting by default to set thresholds to control traffic volumes of web apps and APIs. These limitations improve protection against DDoS attacks, brute force login attempts, and other request floods. For example, you can limit:
Maximum requests per IP per minute.
Maximum requests per session.
Maximum API calls with a certain parameter.
However, these thresholds can inadvertently block legitimate users if they are too tight. For example, setting a global limit of twenty requests per IP per minute could hamper users with unstable connections.
In such cases, a better approach is to set more targeted thresholds per endpoint or resource based on analyzing usual traffic patterns. For example, you can set higher rates on public pages, lower rates on admin pages, even lower for login pages, and strict limits on high-risk actions like money transfers.
7. Unused Application-Specific Rules
WAFs often have various rules tailored to specific web frameworks, platforms, or software. For example:
Rules specific to blocking Java exploits.
Rules for app servers like Tomcat or Nginx.
Rules protecting PHP apps from CMS-specific threats.
These rules are mostly effective at the initial application architecture. Over time, as codebases evolve, chunks of the app get retired or rewritten, and some rules can become obsolete. For example, if the PHP backend gets replaced by Node.js, all the PHP-related rules are no longer needed.
Periodically pruning these rules to match the current application stack helps clean up technical debt and improve WAF performance. However, before removing framework-specific rules, a careful analysis is required to confirm those technologies are truly gone from the current app environment.
Finding the Right Balance with Your WAF Rules
WAF rules play a significant role in protecting web applications against various cyber threats. However, defining a large set of WAF rules can cause considerable application performance and security issues. Therefore, it is essential to maintain a balance between security and performance to provide the best security and user experience.
In real-world scenarios, it's not easy to manually maintain this balance, which is why an install-and-forget WAF solution is so valuable. open-appsec is a pre-emptive solution that protects against OWASP Top 10 and zero-day threats while helping you save resources and time.
open-appsec is an open-source project that builds on machine learning to provide pre-emptive web app & API threat protection against OWASP-Top-10 and zero-day attacks. It simplifies maintenance as there is no threat signature upkeep and exception handling, like common in many WAF solutions.
To learn more about how open-appsec works, see this White Paper and the in-depth Video Tutorial. You can also experiment with deployment in the free Playground.
