Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
Which attacks does TR7 WAF protect against?
Short answer
TR7 WAF combines three inspections in a single attack score against the attacks coming to web applications and APIs at the application layer (hybrid security model): signature rules distributed across 32 attack categories (the Signature & Rule Library screen shows 3,347 rows and 10,370 signatures together with the structural inspection records when there is no custom rule), the Page Types structural inspections that protect the expected request shape of the application, and Blacklist Protection, which catches the source IPs on the blacklist. The coverage extends from injections such as SQL Injection, Cross-Site Scripting and OS Command Execution to Server-Side Request Forgery, XML External Entity, Insecure Deserialization, HTTP Request Smuggling and LLM Prompt Injection (Signature Categories); there are signatures defined by name for known exploits such as Log4Shell, Spring4Shell, Shellshock and ProxyShell/ProxyLogon. The signature rules and structural inspection records in the library are mapped to all the items of the OWASP Top 10 (Web, 2021) and OWASP API Security Top 10 (2023) lists (10/10 on the screen); hits are reported with CWE, CAPEC and MITRE ATT&CK/ATLAS mappings (classification). Request volume, bot traffic and packet floods are within the scope not of WAF but of Bot/DDoS Protection and the L4 DDoS Protection add-on.
How Does It Work?
TR7 WAF inspects an HTTP request separately in seven parts: Path, Query, Header, JSON, XML, Form and Raw (What is Check Fields; into which seven parts does the WAF split a request to inspect it?). These parts go through signature scanning and structural inspections, and the source IP of the request goes through the IP reputation inspection; every violation found is added to the attack score of the request, and when the total reaches the OWASP Protection Level threshold, the request is blocked in Blocking mode (violation scores).
| Inspection | What it catches | Score | Where in TR7 |
|---|---|---|---|
| Signature scanning (negative model) | Known attack patterns; every signature is bound to a category according to the attack technique it targets and to a score according to its risk level | 2 · 4 · 6 · 8 (9 in three built-in signature rules) | Signature & Rule Library (device-wide) · OWASP Rules (vService) |
| Structural inspections (positive model) | Deviations from the request shape the application expects: out-of-bounds length, count, size and depth; unallowed parameter, HTTP method, content type and file type; value pattern (regex) violation; JSON, XML, form and raw bodies that cannot be parsed or are truncated | 24 | Page Types → Check Fields |
| IP reputation | Source addresses in the categorized blacklist on the IP Intelligence & Reputation screen and in the vService-specific Frontend Blacklist | 100 | Blacklist Protection (on by default) |
- At the default Very Tight level (threshold 4), a single signature hit with a Medium or higher score is enough for blocking on its own, while a structural violation (24) and a blacklist hit (100) are enough on their own at every level (How does TR7 WAF decide whether to block a request?).
- Structural violations enter the score only in the Monitor and Blocking modes; in Learning mode, the path, header and field structure inspections do not run, and the body size, truncated body and multipart inspections run without entering the score (operating modes).
- The type of files uploaded with a multipart form is determined not from the content type declared by the client but from the file content (for plain text files whose type cannot be derived from the content, the extension of the file name is also looked at) and is compared with the list of allowed types (Form · Allowed Upload Mime Types); the content of the file also goes through signature scanning while OWASP Check in Upload is on (default).
Attack Categories
Signature rules are distributed across 32 attack categories; in the table below, the categories are grouped with their names in the interface (Signature Categories). The Signature Categories card on the Signature & Rule Library screen shows 36 when there is no custom rule, by also adding to these the 4 catalog categories of the structural inspection and IP reputation records (Structure Limits, Structure Policies, Content Integrity, IP Reputation); when a custom rule is added, the Custom Rules category is also counted.
| Group | Categories | Attacks it covers |
|---|---|---|
| Injection | SQL Injection, Data Query Injection, OS Command Execution, Template/Expression Eval, CRLF / Header Injection, SSI Injection, CSV Formula Injection, LLM Prompt Injection | Code or command injection into database queries, LDAP, NoSQL and XPath/XQuery queries, operating system commands, template engines and expression languages, HTTP headers, fields exported to spreadsheets, server-side include (SSI) directives and LLM instructions |
| Client side | Cross-Site Scripting, Open Redirect | Injection of malicious scripts into the page; redirecting the user to the attacker's site with a URL parameter |
| File and path | Directory/Path Traversal, Arbitrary File Read, File Write/Upload, File Inclusion | ../ sequences and their encoded variants, reading of configuration and credential files, webshell upload and extension bypass, local and remote file inclusion (LFI/RFI) |
| Server-side request and parsing | Server-Side Request Forgery, XML External Entity, Insecure Deserialization, Prototype Pollution, Unsafe Reflection | Making requests to the internal network and to cloud metadata endpoints, reading files with the XML parser, code execution via Java, PHP, Python and .NET object serialization, modification of the JavaScript prototype chain, code execution by having a class or method selected with external input |
| Protocol and evasion | HTTP Request Smuggling, Parameter Pollution, Encoding Evasion, Cache Poisoning | Exploitation of the parsing difference between the proxy and the server, filter evasion with repeated parameters, double encoding and Unicode abuse, placing malicious content in the shared cache |
| Access and business logic | Access Control Bypass, Authentication Bypass, Session Manipulation, Business Logic Abuse | Privilege escalation, forced browsing and IDOR, authentication bypass, CSRF and session fixation, workflow violations |
| Other | Malicious Code Detection, Information Disclosure, Application DoS, Format String Attack, Input Validation/Neutralization | Webshell, backdoor and crypto miner patterns in the request, access to debug endpoints and directory listings, decompression bomb, ReDoS and XML entity expansion, format string and generic input validation attacks |
Rule and signature counts per category: Which attack categories do the signatures cover? · totals of the library: How many signatures / rules does TR7 WAF have?
Highlighted Coverage
| Topic | Its counterpart in TR7 WAF |
|---|---|
| Known exploits | Signature rules defined by name for Log4Shell, Spring4Shell, Shellshock and ProxyShell/ProxyLogon; all of these rules have a Very High score: most are 8, and the Spring4Shell Exploitation and ProxyShell ProxyLogon Exploit rules are 9 points (My application's code was written securely; is a WAF still necessary?) |
| APIs | JSON and XML bodies are parsed field by field; the positive model can be set up from the OpenAPI document with Import (OpenAPI) (Can I protect my REST APIs with TR7 WAF?) |
| Cloud metadata | Signatures in the Server-Side Request Forgery category that target cloud metadata endpoints; among them, the Cloud Metadata SSRF rule is 9 points (Is there protection against SSRF and cloud metadata (169.254.169.254) access attempts?) |
| AI services | The LLM Prompt Injection category: instruction override, jailbreak patterns and system prompt extraction attempts; the signatures are tagged with MITRE ATLAS techniques (Can it catch prompt injection attacks against my LLM / AI services?) |
| GraphQL, SOAP and XML | Signatures targeting GraphQL queries and XML parsers (Can I protect GraphQL requests? · Can I protect my SOAP / XML services; is there protection against XXE attacks?) |
| Protected platforms | Signatures are classified with 33 platform tags according to the technology they target: SQL and NoSQL databases, Java, PHP, Python, .NET and Node.js runtimes, XML parsers, LDAP directories, template engines, cloud metadata services, LLM services and RAG pipelines are some of them (Protected Target Types) |
| Organization-specific rules | Custom rules are added device-wide in the Signature & Rule Library, and custom rules valid only for that vService are added on the OWASP rules screen of the vService; custom rules are listed in the Custom Rules category and their scores are added to the same attack score (rule layers) |
OWASP and Standard Mappings
The summary cards of the Signature & Rule Library screen show the following coverage when there is no custom rule (library summary cards):
| Framework | Coverage |
|---|---|
| OWASP Top 10 (Web, 2021) | 10/10; all of the A01–A10 items are mapped with signature rules |
| OWASP API Security Top 10 (2023) | 10/10; API1–API9 are met with signature rules, and API10 (Unsafe Consumption of APIs) with structural inspection records |
| CWE | 129 weakness classes (120 in signature rules) |
| CAPEC | 41 attack patterns (40 in signature rules) |
| MITRE | 33 techniques: 29 ATT&CK techniques and 4 ATLAS techniques targeting AI systems |
These mappings are seen per hit in the Event Logs records (Category, OWASP Web, OWASP API, CWE, CAPEC, MITRE ATT&CK), per period on the Classification tab of the WAF Report, and in the attack fields sent to the SIEM with the SIEM & Attack Details setting. The vService Dashboard shows the attacks broken down by category, OWASP Top 10 (Web) and OWASP API Top 10.
Limits of the Coverage in TR7
- The protection works on the HTTP vServices on which WAF is on; for HTTPS content to be inspected, TLS must be terminated on TR7 (Can the WAF see the content of HTTPS traffic; what is required for that?).
- WAF inspects requests; it does not inspect responses; for data leakage in the response: Can I prevent sensitive data (credit card, national ID number) from leaking out in the response?
- Request volume and automated bot traffic are within the scope of Bot/DDoS Protection, which is turned on per vService, and packet and connection floods within the scope of the L4 DDoS Protection add-on that works per route table.
- Which attacks actually arrive is monitored on the vService Dashboard and in Event Logs.
Common Misconceptions
- "WAF catches only attacks that have a signature." Structural inspections also catch deviations that have no signature (Can TR7 WAF catch a zero-day attack without a signature?).
- "Every signature in the library runs at every level." Signatures with a Low (2) score are scanned only at the Aggressive level (What is the OWASP Protection Level; how many levels are there?).
- "Changing the extension in a file upload bypasses the inspection." The type of the uploaded file is determined primarily from its content, and the extension is looked at only for plain text files whose type cannot be derived from the content; the content also goes through signature scanning (Form · Allowed Upload Mime Types).
- "WAF also provides bot and DDoS protection." Request volume and bot traffic are within the scope of Bot/DDoS Protection, and packet and connection floods within the scope of the L4 DDoS Protection add-on.
How it is done in the documentation
