Company B runs a booking portal for commercial spaces, protected by a WAF with an OWASP-Top-10-based rule set. After a rule update, the WAF keeps reporting rule 942440 "SQL comment sequence detected", but the trigger turns out to be a regular function, not a vulnerability. Why is this a real dilemma?

Question

Accepted Answer

The rule can only be switched completely on or off. Keeping it on means a flood of false-positive alarms that hides the real threat situation; switching it off removes part of the SQL-injection defence for a database that holds all data on offers, customers and properties.

* Neither switch position is good: one blinds the monitoring, the other drops a protection. *
The setting: registered participants list spaces such as conference venues, workshops and studios, and interested parties browse and book them. The web application is B's own development; because the business grew beyond what B's own data centre could handle, B left it and rented hosting in the cloud, with a WAF in front.
Rule 942440 comes from the OWASP Core Rule Set (CRS), the open rule set many WAFs use. It fires on character sequences that start SQL comments, such as --, /*, */ or #, because attackers use comments to cut off the rest of an SQL statement. But such sequences also appear in perfectly normal input — a description written with -- as a dash, a hashtag, a password — which is why a regular function can trigger it.
A false positive is an alarm on harmless activity. One is a nuisance; a constant stream is a security problem, because analysts stop looking, and a real attack drowns in the noise.
Go deeper:

OWASP CRS — REQUEST-942 SQL injection rules (GitHub) — the actual rule 942440 and the comment patterns it matches.
 CRS — Paranoia Levels — why stricter rule levels catch more attacks and also more legitimate traffic.
 False positives and false negatives — Wikipedia — the two kinds of detection error and their trade-off.