full-disclosure - Antitoxin for "SQL Injection" (?)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <43BA96F7.2030604@nruns.com>
Date: Tue Jan  3 15:23:45 2006
From: jan.muenther at nruns.com (Jan Muenther)
Subject: Antitoxin for "SQL Injection" (?)

Hello,

>Do STORED PROCEDURES really protect against any kind of SQL Injection? I
>have read many articles about, some say they are and some say they are
>NOT!
>
>Isn't there any way to do code injection into a SP or are they
>fully-secure against Injections?
>
>  
>
just to quickly sum things up: Using stored procedures does not protect 
you from SQL injection - you may decrease the amount of points where 
things can be altered, but that's about it. In general, you end up with 
a faster SQL injection :P 
What you want to use a parameterized prepared statements, which take 
over the task of escaping special characters for you, so e.g. the single 
tick does not get processed as an active component of the SQL statement.

As a general rule - if you find yourself concatenating strings 
containing user input to create your SQL query, you're doing something 
substantially wrong.
I'd still advise you to filter input generically using a whitelist 
(blacklisting is fairly dangerous with databases, see e.g. the 
CHAR(0xXX) thingy), and also to use stored procedures, simply since it's 
best practice and may help to prevent clusterf**cks deriving from 
combinations of smaller issues.

Hope that helps,
Cheers, j.