Atomicorp WAF Rule 345490

Rule Summary

• Rule ID: 345490
• Status: Active
• Alert message: CSRF Attack Detected - High Confidence Browser Provenance Mismatch
• Observed CWEs: CWE-352 (9)
• Reviewed CWE mapping: CWE-352 (Cross-Site Request Forgery (CSRF))
• Rule severity: Critical (2)
• Phase: 1 (request headers)
• Rule action: deny
• HTTP status: 403
• Public tags: ASL/CSRF
• Logging: log, auditlog

Description

Rule 345490 is the enforcement event for Atomicorp’s scored Cross-Site Request Forgery (CSRF) detector. It is generated only when CSRF enforcement has explicitly been enabled and the transaction score reaches 10 or greater. Multiple browser-provenance, source-authority, cookie, or ambient-credential signals indicate a high-confidence cross-site state-changing request. This rule denies the transaction with HTTP 403.

CSRF detection is detection-only in the production ruleset unless an earlier local phase-1 rule sets TX:ASL_CSRF_ENFORCE=1. The request method only enables evaluation; POST, PUT, PATCH, and DELETE are not attacks merely because of the method.

Troubleshooting

Review the request URI and method and the score, fetch_site, origin, origin_authority, referer, referer_authority, cookies, and credentials fields in the event. Determine whether the endpoint intentionally accepts a cross-origin browser request and whether the reported Origin or Referer is authorized for that endpoint. Also verify the expected session behavior and whether the application operation succeeded.

Legitimate cross-origin workflows can include SAML Assertion Consumer Service endpoints, OIDC form_post callbacks, payment-provider browser returns, and intentionally cross-origin browser APIs. These endpoints remain responsible for their own protocol-specific security validation.

False Positives

Legitimate application flows can intentionally produce the same browser-provenance characteristics used to detect CSRF. If the transaction is expected, configure a narrowly scoped local exemption. If the traffic should not meet the documented scoring conditions, report the event to Atomicorp Support as a possible false positive. Unexpected sources should be investigated as likely hostile or abnormal browser activity.

Tuning Guidance

Do not edit 70_asl_csrf_experimental_v2.conf or any other Atomicorp-managed rule file. Atomicorp rule files are update-managed. Put application-specific tuning in customer-owned local ModSecurity configuration. Customer rules must use an unused local ID in the 1-99999 range and must not reuse an Atomicorp 300000-399999 rule ID.

For a legitimate endpoint, prefer an earlier phase-1 rule that sets TX:ASL_CSRF_EXEMPT=1 and scope it as narrowly as practical by Host and path:

SecRule REQUEST_HEADERS:Host "@streq login.example.com" \
    "id:91002,phase:1,pass,nolog,noauditlog,t:none,t:lowercase,chain"
    SecRule REQUEST_URI "@beginsWith /saml/acs" \
        "t:none,setvar:tx.asl_csrf_exempt=1"

The local transaction-variable rule must execute before the CSRF ruleset. This is distinct from standard rule removal using SecRuleRemoveById, which follows the normal Atomicorp tuning process. Globally removing 345490 while leaving enforcement enabled is dangerous: rule 345491 is not a fallback because it matches only when enforcement is not enabled. A narrow transaction exemption is preferred.

Configuration Notes

• Effective condition: TX:ASL_CSRF_ENFORCE == 1 and TX:ASL_CSRF_SCORE >= 10.
• Action: deny with HTTP 403; phase 1; logged and audit logged.
• Production operation is detection-only until an earlier local rule enables enforcement.
• Safe methods are skipped unless an earlier local rule sets TX:ASL_CSRF_UNSAFE_METHOD=1 for a known state-changing endpoint. Correcting an application that changes state through GET is preferable when feasible.
• A custom session can be recognized by an earlier local rule setting TX:ASL_CSRF_AUTHENTICATED=1 and a descriptive TX:ASL_CSRF_CREDENTIAL_STATUS. This improves scoring accuracy and is not an exemption.

Additional Information

Score model

Scores 0-4 produce no event, 5-7 produce rule 345493, 8-9 produce rule 345492, and 10 or greater produce rule 345491 in detection-only mode or rule 345490 when enforcement is enabled. Origin takes precedence over Referer. Authority comparisons ignore scheme and normalize default ports. Bearer tokens are not built-in ambient browser authentication, and the presence of a CSRF token or header is not treated as proof that it is valid.

Event fields

score is the final risk score; method is the HTTP method; host is the routed target authority; fetch_site is the validated Fetch Metadata value; provenance reports whether usable provenance was available; origin and referer report values such as multiple, null, invalid, or mismatch; their _authority fields contain normalized parsed authorities; cookies reports cookie presence; and credentials reports recognized ambient credential state such as session-cookie or http-auth.

Worked example

Sec-Fetch-Site: cross-site                 +5
Origin authority mismatch                 +3
cookies present                            +1
recognized session/ambient authentication +2
                                          ---
score                                      11

The browser reports a cross-site request, its Origin differs from the target Host, and authenticated browser state is present. Rule 345490 denied it because enforcement was enabled.

Similar Rules

345491 is the critical detection-only event. 345492 records scores 8-9. 345493 records scores 5-7.

Outside References

• Atomicorp ModSecurity guidance
• Atomicorp rule tuning guidance
• W3C Fetch Metadata (opens in a new tab)
• OWASP CSRF Prevention Cheat Sheet (opens in a new tab)

Selected Related CVEs

This is a selected list of documented research observations, not an exhaustive coverage matrix. Absence of a CVE does not imply absence of protection.

Observed CWEs

These CWEs are recorded on published CVEs in the selected observations associated with this rule. They are observational relationships, not a claim that the rule universally blocks every vulnerability assigned to a CWE.

Reviewed CWE Mapping

These are explicit, human-reviewed mappings of this rule’s documented detection purpose. They are distinct from Observed CWEs derived from published CVE test evidence.