OWASP Core Rule Set (CRS)

What is the OWASP Core Rule Set (CRS)?

The OWASP Core Rule Set (CRS) is an open-source collection of generic attack detection rules for web application firewalls (WAFs). Developed as part of the Open Web Application Security Project (OWASP), CRS provides a baseline set of rules designed to protect web applications from a wide range of attacks, including the OWASP Top 10 security risks.

CRS is designed to work with ModSecurity and other compatible WAF engines, offering organizations a powerful, community-maintained security solution that can be customized to meet specific application requirements.

Key Features of OWASP CRS

• Open-Source: Free to use and modify under the Apache License 2.0
• Community-Driven: Maintained by security experts and volunteers
• Comprehensive Coverage: Protection against OWASP Top 10 vulnerabilities
• Modular Design: Rules organized by attack type and severity
• Customizable: Rules can be tailored to specific applications
• Regular Updates: Continuously updated to address new threats
• Performance Optimized: Designed for efficient rule processing
• Documentation: Extensive documentation and community support

How OWASP CRS Works

1. Request Inspection: WAF intercepts incoming HTTP requests
2. Rule Matching: CRS rules are applied to the request
3. Anomaly Scoring: Suspicious patterns increase anomaly score
4. Threshold Comparison: Anomaly score compared against thresholds
5. Action Execution: Requests are blocked, logged, or allowed based on score
6. Response Inspection: Outgoing responses are also analyzed

CRS Architecture

graph TD
    A[Client Request] --> B[WAF Engine]
    B --> C[CRS Rule Processing]
    C --> D[Anomaly Scoring]
    D -->|Score < Threshold| E[Allow Request]
    D -->|Score ≥ Threshold| F[Block Request]
    E --> G[Web Application]
    G --> H[Server Response]
    H --> B
    B --> I[Response Rule Processing]
    I --> J[Client]

CRS Rule Structure

CRS rules follow a standardized format:

SecRule REQUEST_FILENAME|ARGS|REQUEST_HEADERS "@detectSQLi" \
    "id:942100,\
    phase:2,\
    block,\
    t:none,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,\
    msg:'SQL Injection Attack Detected via libinjection',\
    logdata:'Matched Data: %{MATCHED_VAR} found within %{MATCHED_VAR_NAME}',\
    tag:'application-multi',\
    tag:'language-multi',\
    tag:'platform-multi',\
    tag:'attack-sqli',\
    tag:'OWASP_CRS',\
    tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',\
    ver:'OWASP_CRS/3.3.0',\
    severity:'CRITICAL',\
    setvar:'tx.sql_injection_score=+%{tx.critical_anomaly_score}',\
    setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"

CRS Rule Categories

Base Rules

• REQUEST-901-INITIALIZATION: Initialization and configuration
• REQUEST-903.9001-DRUPAL-EXCLUSION-RULES: Drupal-specific exclusions
• REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES: WordPress-specific exclusions
• REQUEST-905-COMMON-EXCEPTIONS: Common false positive exceptions

Protocol Violations

• REQUEST-911-METHOD-ENFORCEMENT: HTTP method enforcement
• REQUEST-912-DOS-PROTECTION: Denial of Service protection
• REQUEST-913-SCANNER-DETECTION: Scanner detection
• REQUEST-920-PROTOCOL-ENFORCEMENT: Protocol compliance

Application Attacks

• REQUEST-921-PROTOCOL-ATTACK: Protocol-level attacks
• REQUEST-930-APPLICATION-ATTACK-LFI: Local File Inclusion
• REQUEST-931-APPLICATION-ATTACK-RFI: Remote File Inclusion
• REQUEST-932-APPLICATION-ATTACK-RCE: Remote Code Execution
• REQUEST-933-APPLICATION-ATTACK-PHP: PHP injection
• REQUEST-934-APPLICATION-ATTACK-NODEJS: Node.js attacks
• REQUEST-941-APPLICATION-ATTACK-XSS: Cross-Site Scripting
• REQUEST-942-APPLICATION-ATTACK-SQLI: SQL Injection
• REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION: Session fixation
• REQUEST-944-APPLICATION-ATTACK-JAVA: Java-specific attacks

Data Leakage Protection

• RESPONSE-950-DATA-LEAKAGES: Generic data leakages
• RESPONSE-951-DATA-LEAKAGES-SQL: SQL-related data leakages
• RESPONSE-952-DATA-LEAKAGES-JAVA: Java-related data leakages
• RESPONSE-953-DATA-LEAKAGES-PHP: PHP-related data leakages
• RESPONSE-954-DATA-LEAKAGES-IIS: IIS-related data leakages

Security and Anti-Evasion

• REQUEST-949-BLOCKING-EVALUATION: Blocking evaluation
• RESPONSE-959-BLOCKING-EVALUATION: Response blocking evaluation
• REQUEST-980-CORRELATION: Correlation rules

CRS Anomaly Scoring System

CRS uses an anomaly scoring system to determine when to block requests:

• Critical: 5 points (e.g., SQL injection, RCE)
• Error: 4 points (e.g., RFI, LFI)
• Warning: 3 points (e.g., XSS, session fixation)
• Notice: 2 points (e.g., protocol violations)

Default Thresholds

• Inbound Anomaly Score Threshold: 5 (block if score ≥ 5)
• Outbound Anomaly Score Threshold: 4 (block if score ≥ 4)

Common Attacks Blocked by CRS

• SQL Injection (SQLi): Malicious SQL queries in input fields
• Cross-Site Scripting (XSS): Injection of malicious scripts
• Local File Inclusion (LFI): Unauthorized local file access
• Remote File Inclusion (RFI): Loading remote malicious files
• Remote Code Execution (RCE): Execution of arbitrary code
• PHP Injection: Injection of PHP code
• HTTP Protocol Violations: Non-compliant HTTP requests
• Scanner Detection: Identification of vulnerability scanners
• Session Fixation: Session hijacking attempts
• Data Leakage: Sensitive information exposure
• Command Injection: Execution of system commands
• XML External Entity (XXE): Exploiting XML parsers

CRS Installation and Configuration

Installation Methods

• Manual Installation: Download and configure CRS files
• Package Managers: Install via package managers (apt, yum, etc.)
• Docker: Use CRS Docker images
• Cloud Services: Integrated with cloud WAF services

Basic Configuration

# Include CRS main configuration
Include /etc/modsecurity/crs/crs-setup.conf

# Include CRS rules
Include /etc/modsecurity/crs/rules/*.conf

Common Configuration Options

• crs-setup.conf: Main configuration file
• paranoia-level: Security level (1-4, default: 1)
• anomaly-threshold: Blocking thresholds
• allowed_methods: Permitted HTTP methods
• allowed_request_content_type: Permitted content types
• allowed_http_versions: Permitted HTTP versions
• restricted_extensions: Blocked file extensions
• restricted_headers: Blocked HTTP headers

CRS Paranoia Levels

CRS offers four paranoia levels to balance security and false positives:

CRS Customization

Rule Exclusions

# Example: Disable specific rule for a path
SecRule REQUEST_FILENAME "@beginsWith /api/" \
    "id:1000,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleRemoveById=942100"

Custom Rules

# Example: Custom rule for application-specific vulnerability
SecRule ARGS:username "@contains admin" \
    "id:1001,\
    phase:2,\
    block,\
    msg:'Attempt to use admin username',\
    logdata:'Matched Data: %{MATCHED_VAR} found in %{MATCHED_VAR_NAME}',\
    tag:'custom-rule',\
    severity:'WARNING',\
    setvar:'tx.anomaly_score_pl1=+%{tx.warning_anomaly_score}'"

False Positive Handling

• Rule Exclusion: Disable problematic rules for specific paths
• Threshold Adjustment: Modify anomaly score thresholds
• Rule Tuning: Adjust rule sensitivity
• Exception Handling: Create exceptions for legitimate traffic

CRS Performance Optimization

• Rule Ordering: Place frequently triggered rules first
• Sampling: Use sampling for high-volume traffic
• Caching: Cache rule processing results
• Parallel Processing: Distribute rule processing across cores
• Hardware Acceleration: Use specialized hardware for rule processing
• Rule Pruning: Remove unnecessary rules
• Phase Optimization: Apply rules in appropriate phases

CRS Integration with Security Ecosystem

• SIEM Systems: Integration with Splunk, ELK, QRadar
• Threat Intelligence: Integration with threat feeds
• Vulnerability Scanners: Automated rule generation from scan results
• CI/CD Pipeline: CRS testing as part of deployment process
• Container Security: CRS in containerized environments
• Cloud Security: Integration with cloud-native security tools
• API Security: Protection for REST, GraphQL, and SOAP APIs

CRS vs. Commercial Rule Sets

CRS Best Practices

• Start with Paranoia Level 1: Begin with the default level
• Monitor Before Blocking: Run in detection mode initially
• Customize for Your Application: Tailor rules to your specific needs
• Regular Updates: Keep CRS updated to the latest version
• Monitor Logs: Review logs for false positives and negatives
• Tune Rules: Adjust rules based on application behavior
• Test Changes: Validate rule changes in staging environments
• Implement Rate Limiting: Protect against brute force attacks
• Document Exceptions: Maintain documentation of rule exclusions
• Integrate with SIEM: Correlate CRS events with other security data

CRS Evasion Techniques

• Encoding Attacks: URL, Unicode, or hex encoding to bypass rules
• Case Variation: Changing letter case in attack payloads
• Comment Injection: Using comments to break up attack patterns
• Parameter Pollution: Duplicating or manipulating parameters
• HTTP Header Manipulation: Modifying headers to bypass checks
• Protocol-Level Evasion: Exploiting HTTP protocol quirks
• Fragmentation: Splitting attacks across multiple requests
• Behavioral Evasion: Mimicking legitimate user behavior

CRS Logging and Monitoring

Audit Log Example

--a1b2c3d4-A--
[12/Dec/2025:15:30:45 +0100] WZq1Xm8AAQEAAFNJ-B4AAAAA 192.168.1.1 54321 10.0.0.1 80
--a1b2c3d4-B--
GET /login.php?user=admin'-- HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0

--a1b2c3d4-C--
HTTP/1.1 403 Forbidden
Content-Type: text/html

--a1b2c3d4-D--
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head><title>403 Forbidden</title></head><body></body></html>

--a1b2c3d4-E--
ModSecurity: Warning. Pattern match "(?i:(?:\\b(?:(?:s(?:elect\\b(?:.{1,100}?\\b(?:(?:length|count|top)\\b.{1,100}?\\bfrom|from\\b.{1,100}?\\bwhere)|.*?\\b(?:d(?:ump\\b.*\\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebtask)|ql_(?:longvarchar|type)| ... [file "/etc/modsecurity/crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "64"] [id "942100"] [rev "2"] [msg "SQL Injection Attack Detected via libinjection"] [data "Matched Data: admin'-- found within ARGS:user"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.0"] [maturity "9"] [accuracy "8"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag "OWASP_CRS"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [hostname "example.com"] [uri "/login.php"] [unique_id "WZq1Xm8AAQEAAFNJ-B4AAAAA"]

--a1b2c3d4-F--
HTTP/1.1 403 Forbidden
Content-Type: text/html

--a1b2c3d4-H--
ModSecurity: Warning. Access denied with code 403 (phase 2). Pattern match "(?i:(?:\\b(?:(?:s(?:elect\\b(?:.{1,100}?\\b(?:(?:length|count|top)\\b.{1,100}?\\bfrom|from\\b.{1,100}?\\bwhere)|.*?\\b(?:d(?:ump\\b.*\\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebtask)|ql_(?:longvarchar|type)| ... [file "/etc/modsecurity/crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "64"] [id "942100"] [rev "2"] [msg "SQL Injection Attack Detected via libinjection"] [data "Matched Data: admin'-- found within ARGS:user"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.0"] [maturity "9"] [accuracy "8"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag "OWASP_CRS"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [hostname "example.com"] [uri "/login.php"] [unique_id "WZq1Xm8AAQEAAFNJ-B4AAAAA"]

Monitoring Tools

• SIEM Systems: Splunk, ELK Stack, QRadar
• Log Analyzers: GoAccess, AWStats
• Alerting Systems: Nagios, Zabbix
• Dashboard Tools: Grafana, Kibana
• Threat Intelligence Platforms: MISP, AlienVault OTX

CRS in DevOps and CI/CD

• Automated Testing: CRS testing in CI pipelines
• Rule Validation: Validate rules before deployment
• Security Gates: Block deployments with security vulnerabilities
• Infrastructure as Code: Manage CRS configurations with IaC tools
• Container Security: CRS in containerized environments
• Serverless Integration: CRS with serverless architectures
• Automated Updates: Automated CRS updates in deployment pipelines
• Compliance Checking: Verify CRS compliance with security policies

Future of OWASP CRS

• AI-Powered Rules: Machine learning for adaptive security
• Cloud-Native Integration: Better support for cloud environments
• API-First Protection: Enhanced API security capabilities
• Automated Rule Generation: AI-driven rule creation
• Behavioral Analysis: Advanced user behavior monitoring
• Zero Trust Integration: CRS as part of zero trust architectures
• Enhanced Performance: Optimized rule processing
• Improved Usability: Better management interfaces
• Threat Intelligence Integration: Real-time threat feed integration
• Automated Tuning: AI-driven rule optimization

Example CRS Deployment Workflow

graph TD
    A[Start] --> B[Install CRS]
    B --> C[Configure Paranoia Level]
    C --> D[Customize Rules]
    D --> E[Test in Detection Mode]
    E --> F[Monitor Logs]
    F --> G{False Positives?}
    G -->|Yes| H[Tune Rules]
    H --> E
    G -->|No| I[Enable Blocking Mode]
    I --> J[Monitor Production]
    J --> K[Regular Updates]
    K --> J

The OWASP Core Rule Set provides organizations with a powerful, community-driven security solution that can significantly enhance web application security while remaining cost-effective and customizable.