Wednesday, 16 January 2008

Stored Proceedures and SQL injection

When the database server supports them, use stored procedures for performing access on the application's behalf. This will not eliminate SQL injection attacks, but it will reduce them.

It is feasible to write a stored procedure that constructs a query dynamically. This will not provide any fortification against SQL Injection. The process of correctly binding data input through prepare/execute or direct SQL statements using bound variables is the only way to grant this defence.

Encapsulating the restrictions for a definite action (including query, update, delete, and other calls) into an atomic stored procedure allows it to be documented and hardened. Doing this on a standalone basis lets you implement the agreed business rules to the database in a manner that can be trusted. The difficulty comes where a stored procedure calls another process or procedure. This adds complexity.

Using an atomic procedure makes the individual stored procedure larger, but does not mitigate reusing code. When implementing atomic stored procedures for an operation, you make them more robust and simplify the maintenance.

Remember...
SQL injection is still possible if the dynamic SQL inside the stored procedure is not handled correctly.

See the following site for more - or just google it...
http://h71028.www7.hp.com/ERC/cache/571032-0-0-0-121.html&ERL=true

No comments: