Timeline for Is it possible to detect 100% of SQLi with a simple regex?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 1, 2019 at 10:02 | review | Suggested edits | |||
| Dec 1, 2019 at 11:13 | |||||
| Feb 23, 2019 at 11:44 | comment | added | user1067003 |
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.
|
|
| Feb 21, 2019 at 22:57 | comment | added | corsiKa | 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. | |
| Feb 21, 2019 at 14:41 | comment | added | Ismael Miguel | @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. | |
| Feb 21, 2019 at 14:38 | comment | added | Mateusz | 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. | |
| Feb 20, 2019 at 15:35 | comment | added | Ismael Miguel |
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="<known value>"; --.
|
|
| Feb 20, 2019 at 8:11 | comment | added | O. R. Mapper | @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. | |
| Feb 20, 2019 at 5:52 | comment | added | jpmc26 | @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. | |
| Feb 20, 2019 at 5:25 | comment | added | Nelson | @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. | |
| Feb 20, 2019 at 4:54 | comment | added | jpmc26 | "proper design" It would greatly improve the answer to mention what that proper design is, the parameterized queries part in particular. | |
| Feb 19, 2019 at 23:37 | comment | added | JAB | @alex.forencich And sometimes the set of valid data may overlap with the set of malicious inputs. xkcd.com/327 | |
| Feb 19, 2019 at 21:07 | comment | added | Jan Hudec | 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. | |
| Feb 19, 2019 at 20:32 | comment | added | schroeder♦ | @alex.forencich ... hence needing to know what's normal for input ... | |
| Feb 19, 2019 at 20:30 | comment | added | alex.forencich | 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 [email protected] or something along those lines. | |
| Feb 19, 2019 at 17:06 | comment | added | reed | 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. | |
| Feb 19, 2019 at 17:00 | vote | accept | reed | ||
| Feb 19, 2019 at 15:50 | history | answered | schroeder♦ | CC BY-SA 4.0 |