A Web Application Firewall (WAF), as the name suggests, is a security device designed for blocking potential threats. WAFs are commonly used to protect web applications that are exposed to the internet. In this article, we’ll explore the application of WAFs by testing SafeLine WAF.
SafeLine WAF Testing
First, I set up a basic HTTP server and added SafeLine WAF as a proxy in the backend.
SQL Injection Test (1=1):
The attack was successfully blocked.
Malicious File Uploads (Webshells):
Only PHP and ASPX webshells were blocked. JSP and other types were still accessible, but that’s understandable—after all, this is a WAF, not an endpoint security solution.
Directory Scanning with Dirsearch:
While tools like AWVS would trigger a block, I tested with Goby (over 1000 PoCs). It didn’t trigger an immediate block but did log the requests. SafeLine does allow setting a threshold to block excessive requests, so that’s a good backup for handling various scanners. The logs still prove useful for detecting ongoing scans.
Here’s a look at the blocked attacks in the backend:
This article mainly focuses on WAF functionality rather than an in-depth review of SafeLine’s features. SafeLine WAF is an excellent project overall, particularly suitable for small and medium-sized websites. It’s practical, effective, and easy to understand.
WAF Functional Overview
From the tests above, we can summarize that the primary function of a WAF is to block attacks on the web layer.
1. Types of Attacks Blocked
Injection Attacks:
Most WAFs target injection-based attacks, such as SQL injection. These attacks exploit poorly filtered parameters. WAFs can detect potential SQL injections by inspecting the parameters, although bypassing a WAF is often a challenge for security professionals. Another example is XSS (Cross-Site Scripting), which relies on specific tags (e.g.,<,>). Since most websites don’t need users to input these characters, XSS attacks are easier to detect.Request Inspection (Headers, Cookies):
WAFs also examine headers, cookies, request paths, and even request methods or proxies to identify potential threats.
2. Rule Sets
WAFs operate using a combination of pre-defined and custom rule sets for threat detection:
Predefined Rule Sets:
These rules, provided by the vendor, cover common threats like SQL injection payloads, XSS scripts, and known webshells. They are regularly updated with threat intelligence from the vendor.Custom Rule Sets:
These allow users to create specific rules based on their unique needs. For example, if a web application has a known vulnerability in a particular parameter but the user cannot modify the code, they can add a custom rule to block attacks targeting that parameter.
3. Blacklists/Whitelists
Since no rule set is perfect, WAFs may occasionally block legitimate traffic. In such cases, a whitelist can be added for specific IPs. Blacklists, on the other hand, immediately block known malicious IPs, offering an extra layer of protection in case the predefined rules don’t catch them.
Top comments (0)