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)
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)
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
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/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.)
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.
if stored procedures are not an option - and even if they are - validate all inputs thoroughly
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.
"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
The Microsoft Source Code Analyzer for SQL Injection tool is available to find SQL injection vulnerabilities in ASP code