- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
What language is this or how can you make this work? Why would you prefer it?
Admin
It's (most likely) C# using the Microsoft.VisualBasic library. You would use this if you were a VB programmer who is using C# and not familiar with .Net String methods.
Admin
Haha, we have a nearly identical method in one of our shopping cart applications.
Admin
Jaime,
I like the way you say that for your sql injection attack of a stored procedure to work, you first have to do some sql injection. Ever heard of circular logic?
I call BS - yet again.....
Admin
Here is an extremely naive block of C# that both uses stored procedures and is vulnerable to SQL injection:
To attack it, first put "1 SELECT * FROM sysobjects" into the text box. This will list all of the procedures in the database. Then choose a juicy procedure and type "1 SELECT * FROM syscolumns WHERE id = OBJECT_ID('<procedurename>')" into the text box. You will now have all of the parameters for the procedure.
I do realize that this code is horrible. But it does use stored procedures and using stored procedures is not enough to get over the fact that is doesn't parameterize the call. Parameterization is the only effective way to prevent SQL injection. Once you parameterize, it is not necessary to use procedures to protect from SQL injection, because you are already protected.
Admin
Jaime,
I see what you're driving at, but that will fail to inject a stored procedure. Since (in your example) the procedure will have the passed in value defined as an ID, anything else will fail to run. That's the beauty of stored procedures, you can only pass in valid values, anything else fails.
I work in oracle, and would gladly post an example, if you would like (although it's similar to sql server).
Admin
... was purposely coded as "the last Table" instead of "Table 0" so that the result of the injected SQL would display on the screen. This is not hypothetical code, this is an excerpt from an application that I built and ran specifically to prove that it is possible to inject SQL into a stored procedure call. Would you like screen shots?
Admin
2=2 works equally well... just saying.
Admin
Jaime,
in my stored-procedures-only world, the count of tables would be derived from a stored procedure. Bear in mind that nobody would have access to the data schema itself, and would be unable to count anything. ALL access would be via a different account, which would only be able to execute stored procedures.
I neglected to mention that without such protection (which I had assumed was implicit) the stored procedures can always be by-passed.
I therefore amend my assertion to be that
"Provided no alternative means of access is possible, a stored procedure interface can't be SQL injected, because there's no SQL to inject"
T
Admin
As for the account access, injection happens via the application, so it has all the rights of the application account. This means any injected code can run any stored procedure. In an application where all data modification are done via stored procedures, it naturally follows that there are stored procedure to perform any reasonably conceivable data modification. The injected SQL can therefore effectively modify all data.
Addendum (2010-03-11 08:57): Also... There is SQL, stored procedures are executed with the "EXECUTE" SQL statement. In any context that SELECT is valid, EXECUTE is also valid.
Admin
UNION ALL is another one they missed at a quick glance, haha... either way, badly coded way to 'sanitize' queries against injection.
Admin
what's so hard - use prepared Statements and you can forget about SQL-injections alltogether, because then: