Is it possible to detect 100% of SQLi with a simple regex?

Question

I'm wondering if it is possible to detect 100% of the possible SQLi attacks using a simple regex.

In other words, using very simple PHP code as an example:

if (preg_match("/select/i", $input)) {
    attack_log("Possible SELECT SQLi detected.")
}

The questions are:

Will that regex catch all possible SQLi attacks that use SELECT? If not, is it possible to change that regex so that it is going to detect all injections that rely on SELECT?
Is it possible to change that regex to so that it will catch all possible SQLi, so not only SELECT statements but also all the rest? I'm afraid that to achieve this I would need to add every possible SQL keyword to the regex, including "AND" and "OR".
Supposing it's not possible or feasible to detect all SQLi by trying to match all the possible SQL keywords, is there a limited subset of keywords that would allow me to detect the vast majority of possible attacks?

@reed The problem is that StackExchange isn't an open forum for discussing ideas. It's a Q&A site with restrictions on the types of questions that can be asked, in order to promote content that is useful to both those asking the questions *and* future readers. Questions like this, where the goal (intended or otherwise) is to ruminate over ideas rather than get a single concrete answer, aren't considered to be on-topic here. Since any correct answer would need to start with "don't do this, use parameters instead" it doesn't seem like there's much value that can come of it. — Polynomial, Feb 19 '19 at 15:03
@Polynomial, the questions I asked are specific. Does it catch all SQLi that use SELECT? Yes, no, why? I believe these kinds of question are what is behind most IDS. — reed, Feb 19 '19 at 15:08
Unless it is some sort of learning/academic exercise, I would discourage that approach. Instead of detecting/parsing user input, use the database mechanisms that avoid sqli [PHP prepared statements](http://php.net/manual/en/pdo.prepared-statements.php) — bradbury9, Feb 19 '19 at 15:13
No, a simple `preg_match("/select/i", $input)` will NOT detect all sqli. The `SELECT` keyword would be one strong warning indeed, but it would give you false positives (for example a password containing SELECT) and would fail when the sqli is ofuscated. — bradbury9, Feb 19 '19 at 15:19
I was sure there was a duplicate that I could point you towards, but I never found one. There should be one. — schroeder, Feb 19 '19 at 15:53
Can you show how `$input` is going to be used in the query, please? — Bergi, Feb 19 '19 at 19:18
@schroeder https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags seems like a good candidate — aaaaa says reinstate Monica, Feb 19 '19 at 19:30
@bradbury9 For intrusion detection (one of the tags on the question) I could see a basic SQLi check (regex or otherwise) being used as a flag for suspicious activity that leads to an account/ip ban instead of ignoring it because you're SQLi proof (via prepared statements) and risking some other attack vector the adversary uses will work before they trigger a ban. Something like that would be separate from protecting the application against SQLi where the approach is, as you said, completely inappropriate. — Dan Is Fiddling By Firelight, Feb 19 '19 at 20:57
Attempting to parse semantic information out of a recursive language with regular expressions? [What are you trying to do, summon Codethulu or something?!?](https://stackoverflow.com/a/1732454/32914) — Mason Wheeler, Feb 19 '19 at 21:13
@reed Imagine the frustration of your pour users being frustrated they can't submit a post/comment/biography/whatever saying _"I recommend you select the best tool for the job."_ ;) — marcelm, Feb 19 '19 at 22:01
Although there's no simple regex that can do this - and no regex can do it completely reliably - there's still a multi-billion dollar industry based on this idea: web application firewalls — paj28, Feb 20 '19 at 15:53
If you're okay with some false positives, then this one will always catch all SQL injection: `.*` — Dessa Simpson, Feb 20 '19 at 18:11
You don't even need a regex, just `return true`. Pretty high false-positive rate though. — Kevin, Feb 20 '19 at 23:15
Just convert strings from your users to hex. Instead of `select 'yeet'`, send it as `select x'79656574'` — Brian Leishman, Feb 21 '19 at 13:47
`I'm afraid that to achieve this I would need to add every possible SQL keyword to the regex` yup, and then some — J.A.K., Feb 21 '19 at 22:51
Does "SQLi" mean "SQL injection attacks"? If so, why don't you just say that? — David Conrad, Feb 22 '19 at 18:46
"He defeated all SQL Injection attacks with one simple trick! Penetration Testers hate him!" — el.pescado - нет войне, Feb 24 '19 at 20:26

score 174 · Accepted Answer · answered Feb 19 '19 at 15:50

174

Keyword filtering for SQLi is not a good technique. There are too many ways to bypass it.

Crazy things like sel/**/ect might work, for instance. Or playing games with substr(). And then there's EXEC('SEL' + 'ECT 1').

There are many guides on how to bypass common filtering techniques.

But then you might ask if there is a superset of things to filter for (like select and /**/ and substr and EXEC), but then the list gets very, very long, and you still might not get a comprehensive list.

The better approach is to understand the range of acceptable inputs and protect those or to make it ineffective to use SQLi through proper design.

answered Feb 19 '19 at 15:50

schroeder

123,438
55
284
319

1

I guess this is exactly the kind of answer I needed, and that link is especially helpful to understand how complex all this can get. Thanks. – reed Feb 19 '19 at 17:06
78

Not to mention the false positive rate. The more things in your list, the more likely you'll match something in the query data - name, user name, email address, etc. Imagine if someone tried to register as bob@executiveselect.com or something along those lines. – alex.forencich Feb 19 '19 at 20:30
@alex.forencich ... hence needing to know what's normal for input ... – schroeder Feb 19 '19 at 20:32
1

Also even if you managed to catch all injection attempts using select, injection of SQL *fragments* that modify existing queries to do something else then they were supposed to is probably even more important class of attacks—and these don't have characteristic keyword. – Jan Hudec Feb 19 '19 at 21:07
16

@alex.forencich And sometimes the set of valid data may overlap with the set of malicious inputs. https://xkcd.com/327/ – JAB Feb 19 '19 at 23:37
8

"proper design" It would *greatly* improve the answer to mention what that proper design is, the parameterized queries part in particular. – jpmc26 Feb 20 '19 at 04:54
@jpmc26 Proper design, IMO, is not appropriate as a SE question. It's so broad with such a huge amount of already published material that anyone who can't figure it out really shouldn't be doing it at all. – Nelson Feb 20 '19 at 05:25
11

@Nelson All that of "published material" mostly boils down to, "Use parameterized queries for any value that can't be hard coded directly into the query text, especially user input." (Literally. The only thing beyond this is the question of what to do if you need to have some kind of dynamic value for an identifier, and that isn't necessary in the vast majority of cases.) No harm would come from including a brief summary of that nature. It's really not as big a topic as you seem to think. – jpmc26 Feb 20 '19 at 05:52
2

@jpmc26: While using parametrized queries is the *procedure of implementation* you should definitely follow, I think it is worthwhile to understand *why* it is inherently better than the proposed method. The proposed method attempts to spot anything that could become dangerous when it gets parsed and evaluated by the DB engine, whereas with parametrized queries, user input is presumably rendered unparseable in the first place (by getting converted into e.g. a plain string literal), while taking into account the specific syntax quirks of the very DB engine used to run the query. – O. R. Mapper Feb 20 '19 at 08:11
5

Also, this doesn't catch attacks that may disrupt the service, such as `"; drop table users; --` which, simply, deletes the (hypothetical) users' table. This is far more devastating. Or, just a simple `"; update users set password=""; --`. – Ismael Miguel Feb 20 '19 at 15:35
1

I would add to response that "if you have a problem and use regex, you have two problems now". Basically he wants to trade SQL injection for Regex injection.... With that approach he might make application vulnerable for both issues at the same time, and god knows what could be possible with combination of those two. – Mateusz Feb 21 '19 at 14:38
2

@Mateusz I heavily disagree with your statement. The idea is to test is a certain string matches the regular expression. There's nothing coming from the user side, in the regular expression. Just the value to check. But, yes, it is still 2 problems. – Ismael Miguel Feb 21 '19 at 14:41
Also consider how much simpler it is to just use standard libraries to secure your queries with proper parameterization. Not to mention they've thought of a heck of a lot more edge cases than we have, even the best of us. – corsiKa Feb 21 '19 at 22:57
`but then the list gets very, very long` - no, the list would be literally *INFINITELY LARGE*, lest you consider the max query length, which in MySQL is 67 megabytes __BY DEFAULT__, but even considering a max query length of 67 MEGABYTES, the list will be *EXTREMELY* large indeed. – user1067003 Feb 23 '19 at 11:44

score 109 · Answer 2 · edited Jun 16 '20 at 09:49

109

NO

Since every SQL injection is (by definition) valid SQL and since SQL is a context-free language (source), there is (again, by definition) no regex capable of matching an SQL injection, and trying to do so would probably give result similar to this.

As said by pretty much every comment, use the right tool for the job. In this case it's a prepared statement.

edited Jun 16 '20 at 09:49

Community

1

answered Feb 19 '19 at 15:50

Sefa

1,744
1
9
16

19

To be pedantic, this means that a regex that matches *only* SQL injections (and all of them) is impossible, which is true but not of much value - if it were ever to exist, a solution that also matched invalid SQL would be okay, which reopens the question. This is of course only a theoretical nitpick, in practice regexes are not the right tool or approach for the job. – Giulio Muscarello Feb 19 '19 at 22:49
5

Another theoretical nitpick is that modern regexes are strictly more powerful than the original definition of "regular expression", due to lookarounds and backreferences and such. I wouldn't be surprised if more modern regexes are even Turing complete. – Pedro A Feb 20 '19 at 00:09
15

That is does not follow. Every string of 1s is a valid mathematical expression, and mathematical expressions are a context-free language, but that doesn't mean I can't write a regex to match strings of 1s. – user253751 Feb 20 '19 at 03:23
1

Thats not correct, to detect SQLi you do not detect valid SQL syntax, you just need to detect quote busting constructs. (However it is still a very brittle approach) – eckes Feb 20 '19 at 08:33
@PedroA even if theoretically possible with modern regex, would be too complex to be practical. – Jared Smith Feb 20 '19 at 13:37
7

@GiulioMuscarello /.*/ matches all valid SQL (and also some invalid SQL), but would presumably not be ok :) – mbrig Feb 20 '19 at 22:01
@immibis is right. Lets for the sake of simplicity say we define "overlong SQL" as Ä SQL statement of more than 1000 characters". It is obvious that every "overlong SQL" is by definition valid SQL, and it's obvious that you can detect overlong SQL by a trivial regex. By the logic in this answer, that would be impossible. The flaw here is that it's acceptable to give false positives on invalid SQL. – MSalters Feb 21 '19 at 12:03
@MSalters So, how would you use your "trivial" regex to correctly parse any possible SQL statement? Regular languages do not allow arbitrary nesting and/or recursion, but any SQL statement can be arbitrarily nested (e.g. `select this from there where (select that from overthere where ( ... )) left join (select ...) ... ;`). I think the comments and some of the examples that people are posting here are missing the general point being made by the answer, which is actually correct. – code_dredd Feb 21 '19 at 19:55
@MSalters, there are two parts to your definition of "overlong SQL": it must be an SQL statement, and it must be more than 1000 characters long. Detecting that the statement is more than 1000 characters long is trivial for a regular expression to do, but detecting that it's SQL is impossible. The letter "Q" repeated 1001 times is overlong, but it's not "overlong SQL". – Mark Feb 21 '19 at 21:48
1

@Mark Actually you wouldn't care that it's SQL, just that it's overlong. The SQL engine can detect whether it's SQL. – user253751 Feb 22 '19 at 00:29
1

@immibis Then your regex isn't detecting "overlong SQL", just overlong strings. The answer could perhaps be rephrased as "its impossible for regex to determine if a given input is SQL or not" (and therefore impossible to exclude SQL injection while allowing anything else) – mbrig Feb 22 '19 at 04:40
1

@mbrig: This is typical of an incorrect theoretical model. The question is how you protect yourself against SQL injection. Those strings which aren't SQL by definition cannot be SQL injection, so you don't care about misclassifications in that subset. Now that we have 3 groups (definitely SQL injection, definitely not, don't care) you no longer can use the results about binary classification (belongs/doesn't belong to a context-free language) – MSalters Feb 22 '19 at 08:14
1

@MSalters I disagree that you don't care about non-SQL misclassification. You clearly need to allow non-SQL to have a useful filter, otherwise /.*/ and you're done. I do agree there's a bit of a logical gap, in that SQL-injection is a subset of SQL and to be proper you'd need to demonstrate some kind of equivalence in difficulty of parsing. – mbrig Feb 22 '19 at 16:25
My understanding is that context-free languages are a superset of regular expressions. So all regular expressions are context-free languages, and some but not all context-free languages are (can be recognised by) regular expressions. So, it's possible for SQL to be both context-free and recognisable by the right regular expression, although it might not be. – CJ Dennis Feb 23 '19 at 23:57
@CJDennis Context-free (CF) languages are a _proper_ superset of regular languages, i.e. there're elements in the context-free languages set that are not members of the regular languages (RL) set. The RL set is a _proper_ subset of CF. – code_dredd Mar 22 '19 at 20:07

Fake Name · Answer 3 · 2019-02-21T00:31:59.790

59

Technically, this is completely possible (though doing so also renders the database useless):

.+ Will indeed detect any possible SQLi.

However, it will also detect any attempt to do normal queries(or any text at all), rendering the database completely useless.

You could equally say that turning the database off protects from SQLi. It's true, but it also renders the database useless for it's intended purpose.

Use prepared statements or parameterized queries. They exist to solve this issue.

edited Feb 21 '19 at 00:31

answered Feb 19 '19 at 22:16

Fake Name

907
1
6
11

19

Technically correct is the best kind of correct.. but not in this scenario :P – Dan Feb 19 '19 at 22:23
29

@DanPantry - Nothing in the question specified that it had to *allow* anything. – Fake Name Feb 19 '19 at 22:31
3

This should maybe have been a comment instead of an answer, but it has a good point within it. Instead of focusing on how to block all attacks, OP should focus on what legitimate strings need to be allowed. – Nate Eldredge Feb 20 '19 at 01:26
1

This answer could be improved by mentioning how even the "select" regexp will cause a lot of false matches, for any text containing the word 'select'. – jpa Feb 20 '19 at 13:10
2

@FakeName please see the question's edit history. False positives were originally not a concern but became a concern after much discussion in the comments. – schroeder Feb 20 '19 at 13:16
While I completely see what you're doing, the first message is just plain wrong (and the bolded partis not visibly irony without reading on). I have met developers in my life that see something like this and do not read on, crafting a beautiful regex for said matter because the Internet says so... – AnoE Feb 20 '19 at 13:32
1

@AnoE - I can't prevent dumb people from being dumb. That way lies madness. If someone can't be bothered to read past the header they're probably already a lost cause. Besides, it's not plain wrong, it's literally correct (though not in the way you might think). Turning off a database *is* a completely functional way to prevent SQLi, for example. Sure, it also renders the database useless, but any possible SQLi is going to be prevented. – Fake Name Feb 21 '19 at 00:27
I like this answer for its essence: don't try to blacklist possible attack queries, instead use a whitelist of acceptable queries. You are in control of what can be requested from the DB, make sure you enforce that control by using best practices as well as validating and sanitizing input. – Kevin Feb 21 '19 at 10:01
1

This answer is a very good object lesson in how blacklists don't work: the regex `.+` misses plenty of SQL injections! `.` doesn't match newlines by default. – Gilles 'SO- stop being evil' Feb 22 '19 at 13:18
On the flip side, if a system is properly designed, a query which matches nothing would block all possible SQLi attack strings, because there wouldn't be any. – supercat Feb 22 '19 at 16:21
@Gilles: I was half tempted to try and come up with something which I could call "an SQLi attack" involving the empty string, but that's a good point. – Kevin Feb 22 '19 at 22:33
@Gilles - If you can produce a injection that relies *only* on newlines, I'll be impressed. Note that injections =/= a whitespace string that gets past this. – Fake Name Feb 23 '19 at 09:50
Oh, `preg_match` is a search, not an anchored match, I guess? (I'm not familiar with PHP.) With a search, this does block all SQLi that only contain printable characters. Other things to worry about include proper support for null bytes, for invalid Unicode points and for invalid UTF-8 encodings: if the regex engine chokes on one of those but the SQL engine and the communication pipeline pass them through, there's a risk. – Gilles 'SO- stop being evil' Feb 23 '19 at 09:56
@Gilles - The answer was assuming it was a general regex search function, not a specific implementation. The syntax isn't correct for `preg_match` anyways. The question was "can you use regexes to detect SQLi", not "Can you use `preg_match` to detect SQLi", so I answered the former. – Fake Name Feb 23 '19 at 10:02

score 24 · Answer 4 · answered Feb 21 '19 at 14:21

I'm wondering if it is possible to detect 100% of the possible SQLi attacks using a simple regex.

The very fact that you're asking the question this way shows you're thinking about the problem incorrectly.

SQL injection is not a vulnerability in data. It's a vulnerability in application code that handles that data.

For example: right now I'm typing a "SQL Injection" into a textarea on a website! And I can type something like ' -- DROP TABLE Users; right here! Is my answer a SQL injection attack? Of course not.

Now, you could argue that what you're trying to do is to detect attempted SQL injection attacks. But now you need to determine the intent of some input. If I type a bare apostrophe into a field, is that a typo or a an attempted SQL injection attack? Can you detect 100% of my intentions? Of course not.

Fundamentally, attempting to identify possible attacks means that your detect rate can never be 100%.

Since a SQL injection vulnerability only exists in code, and not data, any analysis which only considers data is subject to at best a very large false positive rate. Any solution you devise which could possibly match all actual attack traffic would also interpret a very large quantity of legitimate traffic to this website, and many others, as "attacks" when no such attack was intended.

@ypercube: Well, maybe it's a matter of semantics. I would say: it *could* trigger a SQL injection *effect*, but to be a SQL injection *attack*, the effect would have to be maliciously motivated. And that's somewhat my point: if you look only at the data, you can't know for certain -- at best you can apply a heuristic, and a heuristic cannot have 100% accuracy, by definition. — Daniel Pryden, Feb 21 '19 at 15:07

Philipp · Answer 5 · 2019-02-20T15:39:42.877

11

No. First of all, there are several evil things you can do with SQL injections which don't require the use of the SELECT keyword, like the infamous universal password ' OR '1' = '1 or the common username Robert'); DROP TABLE Students;--. Also, "select" is a very common word in the English language which might appear in completely benign ways in all kinds of different contexts. So if you filter any input which matches /select/i you are going to get a ton of false positives (16 false positives and counting just on the website your are reading right now, for example).

If you want to sanitize inputs before sending data to your database, then PHP has a handy function for that purpose (these are those for mySQL, any other database APIs should provide a similar function tailored for that specific database syntax).

But when you are trying to protect yourself against SQL Injections by blocking certain inputs, then you are fighting the battle at the wrong frontline. It would be much smarter to defend yourself against SQL injections by stopping to create SQL statements by string concatenation. Common alternative ways to interact with databases in a way which makes SQL injections difficult to write unintentionally are:

Use an ORM wrapper which writes SQL queries for you
Use parameterized queries (also known as prepared statements)
Use a programming language where SQL is part of the language syntax
Use stored procedures

edited Feb 20 '19 at 15:39

answered Feb 20 '19 at 15:21

Philipp

48,867
8
127
157

5

Parameterized queries are not "also known as" prepared statements. Parameterized queries are one form of a prepared statement, but not the only form. The two should not be conflated. – dotancohen Feb 21 '19 at 12:20
3

ORM wrappers are notoriously bad at creating well-formed, efficient SQL. I'd put that at the *end* of your recommendations, if I'd even add it to the list. – Hannah Vernon Feb 21 '19 at 15:00
2

@MaxVernon - ORMs make for clear and concise code, which 90+% of the time is more important than squeezing extra performance out of the DB. – paj28 Feb 22 '19 at 08:17
@paj28 - that may be, however when you use an ORM to write SQL for you, you're making it almost impossible to troubleshoot performance later on, when it *does* matter. ORMs are a shortcut that have a tendency to shoot you in the foot when you least expect it. If you're at all concerned about writing great code, you write the SQL yourself. – Hannah Vernon Feb 22 '19 at 16:04
2

Actually, @paj28, I disagree that ORMs make for clean and concise code. What they actually do is obscure arguably the most important code in the entire project. That is, if you believe the data is the raison d'être for the project in the first place. – Hannah Vernon Feb 22 '19 at 16:12
2

Whether you like or dislike ORMs is a software engineering question, not a security question. – Philipp Feb 22 '19 at 16:25

score -1 · Answer 6 · answered Feb 20 '19 at 13:13

-1

No. A regexp implementation is typically a regular language (or an extension thereof that allows parsing of some non-regular grammars.)

SQL on the other hand, it is firmly a non-regular context free language. Ergo, it cannot be parsed by a regular-language regexp.

If you were to use a regexp extension that uses grouping, you might be able to parse valid SQL, but also invalid SQL or things that might look like SQL but aren't.

The best thing to be sure is to use a context-free grammar that expresses the SQL dialect you are looking for, if you really were keen to detect a SQL injection attack.

ps. My personal opinion is that one of the best ways to avoid or minimize sql injection attacks is to never invoke plain SQL from the application (relying instead on stored procedures, which themselves sanitize their arguments.)

A lot more elbow grease, and not necessarily 100% iron-clad injection-proof. But it does work very well. Caveat emptor obviously, for other developers might have different experiences with such an approach.

answered Feb 20 '19 at 13:13

luis.espinal

117
4

SQL is a "non-regular context free language". That's going to need some explanation because that appears false on its face. – schroeder Feb 20 '19 at 13:20
Uh, no. For starters, SQL has been described multiple times in BNF, ergo, it is a context-free language. Here's an example: https://docs.oracle.com/cd/B28359_01/server.111/b28286/ap_syntx002.htm – luis.espinal Feb 20 '19 at 13:40
Additionally, SQL is neither a right regular grammar nor a left regular grammar. In fact, there's no regular grammar than can capture `SELECT x from y` where either `x` or `y` are SQL SELECT statements themselves. – luis.espinal Feb 20 '19 at 13:42
Since we have established that SQL is context-free (because it can be represented in BNF) and it is not regular (since a regular grammar cannot capture recursion), then we can conclude that SQL is a non-regular context free language. After all, all regular grammars are context-free, but not all context-free grammars are regular. – luis.espinal Feb 20 '19 at 13:44
1

You appear to be jumping ahead in some concepts. How do we get to "context-free" from "can be described in BNF"? I think you are bringing in volumes of other concepts without explaining them (or assuming they are true). While I am not trying to assert something else to be true, it is not clear from your answer how your assertions are true. Can you connect some dots? – schroeder Feb 20 '19 at 14:03
1

I'm using textbook definitions: a grammar (in this case SQL) described in BNF is a context-free grammar. And because it contains recursion (see previous example I mentioned), it cannot be accepted by a non-deterministic finite automaton or NFA. And that by definition is a non-regular language. – luis.espinal Feb 20 '19 at 15:25
That's me connecting the dots using standard formal grammar definitions. If I'm wrong,point it out. Anything beyond this will require us to visit a textbook or do some sort of formal proof. – luis.espinal Feb 20 '19 at 15:26
6

Big difference between being right and being useful. This answer is not useful without the reader delving into several computer science concepts to begin to understand the point you are making. I'm asking you to edit the answer to connect some dots to make this answer more useful. – schroeder Feb 20 '19 at 15:39
2

To be fair, SQL injection attacks aren't necessarily valid SQL. (Once they are put into the rest of the query they are.) Because of that it isn't an issue if we can or cannot detect valid SQL with regex. – Captain Man Feb 20 '19 at 16:18
1

A non-CF language may have a regular lexical grammar, so you don't need to match the whole SQL grammar. Just identify strings that might break token boundaries when interpolated into an existing sequence of tokens. That said, I agree with all the posters who have pointed out that filters have a poor track record compared to safety-by-construction. – Mike Samuel Feb 20 '19 at 20:37
"Big difference between being right and being useful." That's a different argument than the one you originally said (that what I said appeared false on its face.) This is disingenuous and dishonest. I'm not interested in engaging in an argument started out with dishonesty. Furthermore, my answer is not the only one delving on the subject of context-free grammars. So screw this. Down vote the whole thing or ask someone else to edit or delete the answer entirely. I'm OK with either. – luis.espinal Feb 21 '19 at 16:37
@luis.espinal your response is irrational and emotion-driven. There has been no dishonesty. Please understand that you have "the curse of knowledge" and you need to be able to explain concepts to people who have not heard the definitions or concepts you are using. This is not a site for people to show off the "right answers". This is a Q&A site, which by its very nature means that answers need to not just be as correct as they can be, but understood by the people who might barely understand their own questions. – schroeder Feb 22 '19 at 09:33
4

@luis.espinal I have no idea why you are getting both emotional and resistent to simply ***editing your answer to explain what you mean***. If you see needing to explain yourself as a challenge to your ability to know the correct answer, then you need to rethink your motivations for answering at all. – schroeder Feb 22 '19 at 09:39
Considering the other side of the concept, "of course it is not recommended", also I can create a regex able to block 100% of query variety, so this answer cannot be "No". I had a case that one manager was able to store new queries as a varchar, so then the clients was able to fill part of them, which "params" ORM method will never allow this kind o process. – Lucas Rodrigues Sena Sep 11 '19 at 15:00

score -1 · Answer 7 · answered Dec 31 '19 at 06:05

No, Your application will not be 100% secured if you use some pattern matching or regex to identify SQL Injection attack. You will face miss detection of SQLI if you use such kind of approach. The best way to achieve 100% protection is using Runtime Application Self-protection (RASP) in your application. In case of Web application Firewall(WAF), you will get false negative results.

Is it possible to detect 100% of SQLi with a simple regex?

7 Answers7

NO

Technically, this is completely possible (though doing so also renders the database useless):