Any need of this SQLi filtering rules?

[oz11]

I use PDO so not sure if this is a good idea. Anyway, maybe it won't hurt?

 

if (str_contains($_GET['q'], 'SELECT')) {
    exit();
}
if (str_contains($_GET['q'], 'UPDATE')) {
    exit();
}
if (str_contains($_GET['q'], 'DELETE')) {
    exit();
}
if (str_contains($_GET['q'], '||')) {
    exit();
}
if (str_contains($_GET['q'], 'WHERE')) {
    exit();
}
if (str_contains($_GET['q'], 'SLEEP')) {
    exit();
}
if (str_contains($_GET['q'], 'DROP')) {
    exit();
}
if (str_contains($_GET['q'], 'FROM users')) {
    exit();
}
if (str_contains($_GET['q'], 'FROM links')) {
    exit();
}
if (str_contains($_GET['q'], '1=1')) {
    exit();
}
if (str_contains($_GET['q'], '1 = 1')) {
    exit();
}

Pontless?

[Barand]

If you use prepared queries correctly, with placeholders for user-supplied data, you don't need that code - the values will not be embedded in the SQL code.

[oz11]

For some reason it kills my page. :/ All white.

[oz11]

Thanks btw!

[Barand]

6 minutes ago, oz11 said:

For some reason it kills my page. 😕 All white.

Because you exit before anything can be output?

[oz11]

It's doing it for results that don't contain.. anyway. Nevermind its unnecessary since my PDO's are fine.  Thanks. 

[Barand]

2 hours ago, oz11 said:

It's doing it for results that don't contain..

Have you got "display_startup_errors" turned on in your php.ini file?

[Phi11W]

20 hours ago, oz11 said:

maybe it won't hurt?

Does your application know what to do with raw SQL passed as a QueryString argument? 

(If it does then I'd suggest that's a pretty poor design). 

if it doesn't then I see no point in defending against this.  
Hackers can throw this (and lots of other) stuff at your application, but it won't get them anywhere if your code doesn't try to do anything with it.

 

Of course, you should vigorously validate and clean any inputs you do receive and that you do intend to do things with. 

Regards, 
   Phill W. 

 

[mac_gyver]

45 minutes ago, Phi11W said:

clean any inputs

you should not modify data, then use the modified value, as this changes the meaning of the data (ask the author's of this forum software about the email 'cleaning' they did a number of years ago that allowed hackers to create a real and valid email addresses that was similar to an administrator's, that after 'cleaning' allowed it to be used to do a password recovery for that administrator, and allowed the hackers to log in as that administrator.) you should only trim user submitted data, mainly so that you can detect if it was all white-space characters, then validate that the trimmed value meets the 'business' needs of your application. if the data is valid, use it securely in whatever context it is being used in. if the data is not valid, tell the user what was wrong with the data and let them correct and resubmit it.