We have installed a new Juniper SRX firewall with IDP, so the firewall is inspecting the traffic for suspicious activity.
I've encountered 3 "false-positive" reports for SQL injection attacks that are just genuine usage:
- Using mDaemon's webmail, trying to forward a message was considered a SQL injection attempt
- In a .NET web-application, entering a load of text into a textarea and clicking submit triggered a SQL injection. It was 1 sentence that seemed to trip it - about an engineer travelling to Basingstoke all the way from South Wales. Remove that sentence it worked fine.
- In a classic-ASP application, trying to save a report (behind the scenes the page reads all the checkboxes selected and inserts this into a database table). The keyword that is causing the incorrect alert is "Goodmans"
With the 2nd problem above, if I pasted the text content into a different web-application (I simply copied the content into a different, unrelated classic-asp form with different objects) there were no problems at all. With the 3rd problem, the application works just fine - it's just this particular set of options that we've found causes the firewall to drop the connection.
The only way I can solve the mDaemon issue is to take the server out of the IDP policy.
I am going to submit a support request to Juniper to help find a fix, but how does everyone else handle false-positives? Is there anything else that can be done? I am worried that there are other conditions that will trigger more and this will be an endless exercise. Except we may not know about many false-positives because users assume the website went down and just give up (or don't report what they did/can't replicate it a second time).
Additional Information In the case of the third problem, it's not just "goodmans" that is causing the problem - it's much more widespread!