views:

4175

answers:

7

What is a strong way to protect against sql injection for a classic asp app?

FYI I am using it with an access DB. (I didnt write the app)

A: 

stored procedures.

dont use access... That is not a real database and will only cause you trouble. SQL Express editions are free and will help you avoid many of the performance, transactional, locking, and corruption problems inherent with MSAccess

StingyJack
can't using access.
Daniel A. White
Modded down because this is untrue. Stored procedures have absolutely nothing to do with preventing SQL injection.
Cowan
you are kidding me right? if you are using a proc call, then you are parameterizing the SQL and avoiding the attack (unless you are lame enough to make DSQL in the proc - but thats just stupid).
StingyJack
i use access, its fine for budget websites (i use sql server when required)
louism
+11  A: 

Stored Procedures and/or prepared statements:

http://stackoverflow.com/questions/1973/what-is-the-best-way-to-avoid-sql-injection-attacks

http://stackoverflow.com/questions/139199/can-i-protect-against-sql-injection-by-escaping-single-quote-and-surrounding-us

http://stackoverflow.com/questions/1284/catching-sql-injection-and-other-malicious-web-requests

With Access DB, you can still do it, but if you're already worried about SQL Injection, I think you need to get off Access anyway.

Here's a link to the technique in Access:

http://www.asp101.com/samples/storedqueries.asp

Note that what typically protects from injection is not the stored procedure itself, but that fact that it is parameterized and not dynamic. Remember that even SPs which build dynamic code can be vulnerable to injection if they use parameters in certain ways to build the dynamic code. Overall, I prefer SPs because they form an interface layer which the applications get to the database, so the apps aren't even allowed to execute arbitrary code in the first place.

In addition, the execution point of the stored procedure can be vulnerable if you don't use command and parameters, e.g. this is still vulnerable because it's dynamically built and can be an injection target:

Conn.Execute("EXEC usp_ImOnlySafeIfYouCallMeRight '" + param1 + "', '" + param2 + "'") ;

Remember that your database needs to defend its own perimeter, and if various logins have rights to INSERT/UPDATE/DELETE in tables, any code in those applications (or compromised applications) can be a potential problem. If the logins only have rights to execute stored procedures, this forms a funnel through which you can much more easily ensure correct behavior. (Similar to OO concepts where objects are responsible for their interfaces and don't expose all their inner workings.)

Cade Roux
+2  A: 

Using parametrized querys, you need to create a command object, assign it parameters with a name and a value, if you do so you wouldn't need to worry about anything else (refering to sql injection of course ;))

http://prepared-statement.blogspot.com/2006/02/asp-prepared-statements.html

And don't trust stored procedures, they can became a attack vector too if you don't use prepared statements.

AlbertEin
Stored procedures are not the answer (even if he was not using Access) because you can still write injectible code using SP's (I have seen it). It is parameterized queries that protect you.
Flory
@Flory, isn't that exactly what he says?
Abel
@Abel, it sure does. I don't know what I was smoking two years ago.
Flory
A: 

if stored procedures are not an option - and even if they are - validate all inputs thoroughly

Steven A. Lowe
A: 

Switching to SQL Express at the very least is a great option. It will make things much more secure. Even though using parameters and Stored Procedures can help greatly. I also recommend that you validate the inputs carefully to be sure they match what you're expecting.

For values like numbers it is fairly easy to extract the number to verify that it is indeed just a number. Escape all special characters for SQL. Doing this will prevent the attempted attack from working.

Brendan Enrick
+3  A: 

"A strong way to protect against sql injection for a classic asp app" is to ruthlessly validate all input. Period.

Stored procedures alone and/or a different database system do not necessarily equal good security.

MS recently put out a SQL Injection Inspection tool that looks for unvalidated input that is used in a query. THAT is what you should be looking for.

Here's the link: The Microsoft Source Code Analyzer for SQL Injection tool is available to find SQL injection vulnerabilities in ASP code

AnonJr
A: 

The Microsoft Source Code Analyzer for SQL Injection tool is available to find SQL injection vulnerabilities in ASP code

Macka