I recently built a brand new development server in order to experiment with Modsecurity. However I am getting lots of false-positives generated by a .NET 4 application using SignalR for client-server communications.
How can I prevent false-positives without compromizing Modsecurity's efficiency?
The hits seems pretty generic so I do not want to disable the rules altogether and I would like to avoid disabling hits on /signalr/ uri which would forfeit protection on SignalR.
Here is how I proceeded with my setup:
Here are the three common false positives I get:
SQL Authentication bypass:
> [client 192.168.0.104:59945] ModSecurity: Warning. Pattern match
> "(?i:(?:in\\s*?\\(+\\s*?select)|(?:(?:n?and|x?x?or|div|like|between|and|not
> |\\|\\||\\&\\&)\\s+[\\s\\w+]+(?:regexp\\s*?\\(|sounds\\s+like\\s*?[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98]|[=\\d]+x))|([\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98]\\s*?\\d\\s*?(?:--|#))
> ..." at ARGS:connectionData. [file "C:\/Program Files/ModSecurity
> IIS/owasp_crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf"]
> [line "239"] [id "981246"] [msg "Detects basic SQL authentication
> bypass attempts 3/3"] [data "Matched Data: \x22name\x22:\x22 found
> within ARGS:connectionData: [{\x22name\x22:\x22*****serverhub\x22}]"]
> [severity "CRITICAL"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"]
> [hostname "*********"] [uri
> "/signalr/start?transport=webSockets&clientProtocol=1.4&connectionToken=iIxfXzLxKm9twEhHdomj4DI95so0QmpmqeTXD4Qe0VsQoJO47CHuEIuv2z7M%2B1TYx44PK5ko18t2aoaLb4WztjR1c8g0VP8MUaGkSO9KDftOzsGektSIDl%2FI1RPMQdTd&connectionData=%5B%7B%22name%22%3A%22*****serverhub%22%7D%5D&_=1461637088340"]
> [unique_id "17798225729515683844"]
Restricted SQL characters:
> [client 192.168.0.104:59945] ModSecurity: Warning. Pattern match
> "([\\~\\!\\@\\#\\$\\%\\^\\&\\*\\(\\)\\-\\+\\=\\{\\}\\[\\]\\|\\:\\;\"\\'\\\xc2\xb4\\\xe2\x80\x99\\\xe2\x80\x98\\`\\<\\>].*?){4,}"
> at ARGS:connectionData. [file "C:\/Program Files/ModSecurity
> IIS/owasp_crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf"]
> [line "159"] [id "981173"] [rev "2"] [msg "Restricted SQL Character
> Anomaly Detection Alert - Total # of special characters exceeded"]
> [data "Matched Data: \x22 found within ARGS:connectionData:
> [{\x22name\x22:\x22*****serverhub\x22}]"] [ver "OWASP_CRS/2.2.9"]
> [maturity "9"] [accuracy "8"] [tag
> "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [hostname "*********"] [uri
> "/signalr/start?transport=webSockets&clientProtocol=1.4&connectionToken=iIxfXzLxKm9twEhHdomj4DI95so0QmpmqeTXD4Qe0VsQoJO47CHuEIuv2z7M%2B1TYx44PK5ko18t2aoaLb4WztjR1c8g0VP8MUaGkSO9KDftOzsGektSIDl%2FI1RPMQdTd&connectionData=%5B%7B%22name%22%3A%22*****serverhub%22%7D%5D&_=1461637088340"]
> [unique_id "17798225729515683844"]
Missing Accept Header:
> [client 192.168.0.104:59949] ModSecurity: Warning. Operator EQ matched
> 0 at REQUEST_HEADERS. [file "C:\/Program Files/ModSecurity
> IIS/owasp_crs/base_rules/modsecurity_crs_21_protocol_anomalies.conf"]
> [line "47"] [id "960015"] [rev "1"] [msg "Request Missing an Accept
> Header"] [severity "NOTICE"] [ver "OWASP_CRS/2.2.9"] [maturity "9"]
> [accuracy "9"] [tag
> "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag
> "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname
> "*********"] [uri
> "/signalr/connect?transport=webSockets&clientProtocol=1.4&connectionToken=iIxfXzLxKm9twEhHdomj4DI95so0QmpmqeTXD4Qe0VsQoJO47CHuEIuv2z7M%2B1TYx44PK5ko18t2aoaLb4WztjR1c8g0VP8MUaGkSO9KDftOzsGektSIDl%2FI1RPMQdTd&connectionData=%5B%7B%22name%22%3A%22*****serverhub%22%7D%5D&tid=6"]
> [unique_id "17726168135477755906"]
PS: I am not using any SQL technology in that particular application.
For the first two I would suggest you add the following rules to ignore this ConnectionData parameter for those rules:
SecRuleUpdateTargetById 981246 !ARGS:'ConnectionData'
SecRuleUpdateTargetById 981173 !ARGS:'ConnectionData'
For the last I suggest removing that rule completely. I don't find it that useful as there are some browsers (on Android from memory) that don't send that header:
SecRuleRemoveById 960015
You might want to read this answer to understand how to tune ModSecurity: Extra sensitive Mod Security rules giving 403 forbidden error