Methods of SQL Injections Detection
Detection of SQL injections is somewhat similar to email spam filtration. The problems, developers of such systems to solve, are also similar.
So let’s take a look at the methods of spam filtration used by email servers:
- Analyzing the text of messages with various algorithms (Bayesian filtering for example).
- Content filtering. It includes looking for spam signs such as links, product offers, keywords etc. in the text of messages.
- Filtering based on statistical information about decisions made by other email server users (looking if they marked similar messages as spam).
- Using information on credibility of the mail server received from other services.
Each of these tests is divided into sub-tests. A certain “cost” (in points) is assigned for each sub-test. If the incoming message passes the sub-test, its points are added to the test overall score. The score could be just as positive so to negative. When the testing of a message is completed, the anti-spam system sums the overall score. The higher the score, the higher the possibility that the tested message contains spam.
For example, Spam Assassin spam filter features a customizable threshold. If the test’s overall score exceeds the threshold, the message is considered as spam. Usually, the threshold is configured in such a way that it is not enough for a message to pass one test to exceed the threshold value (to be marked as spam). Operation principles of other filters are similar to Spam Assassin’s.
Any spam filtering method alone guarantees full protection against unwanted messages as well as against false alarms. That’s why in practice a combination of various methods is used. Configuring overall threshold and sub-tests “cost” needs to determine filter’s “level of suspicion”.
SQL injection filtering works almost similar to spam filters. On DAF level, in most cases you encounter valid SQL code, that’s why it’s necessary to use indirect signs when determining if the query is SQL-injected.
DataSunrise can detect SQL injections based on the following signs.
- Number of invalid queries coming from a certain host or issued by a certain client.
- Presence of constant conditions in the query which always return TRUE or FALSE.
- Whether there are commentaries in the query body and do these commentaries (they) contain SQL query parts.
- OR and UNION blocks in the query code.
- Other conditions.
Ability to detect each sign alone is not sufficient for recognition of SQL injection attack, but the capability to spot all these signs in a query enables DataSunrise to establish essential protection, as shown in the demonstrative example of how DataSunrise protects from SQL injections.
And at last, it should be mentioned that full protection against SQL injection attacks could be achieved only by using quality and properly tested application server.
