If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to Register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

WHILE (@TableName IS NOT NULL) AND (@tColumnName IS NOT NULL)
BEGIN
SET @tColumnName =
(
SELECT MIN(QUOTENAME(COLUMN_NAME))
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = PARSENAME(@TableName, 2)
AND TABLE_NAME = PARSENAME(@TableName, 1)
AND DATA_TYPE IN ('ntext', 'text')
AND QUOTENAME(COLUMN_NAME) > @tColumnName
)

The use of stored procedures is to combat injection of ad-hoc SQL statements. And the additional suggestion of using ‘execute only’ permissions on procedures is because I want to make sure that the stored procedures that I have cannot be replaced or altered by the SQL Injection attack. I do not want an attacker using SQL Injection to read my existing code, but this is a secondary consideration. The attacks I see could usually care less what logic you have, but really want to introduce their own functionality, either by introducing an ad-hoc query or by introducing a stored procedure. Use of stored procedures mitigates the first issue, and ‘execute only’ stops the alteration of the code. I am adding that you want to periodically check that the database user does not have create procedures permissions in their role in addition to the existing stored procedures being execute only. This combats the ‘Injection’ of new stored procedures to launch additional attacks.

But database administration and database platform security is oft left out of the conversation, and it should not be, as there are other simple tips that have similar benefits to helping reduce the possibility of SQL Injection. I have made some comments to several of the OWASP & WASC members here in San Jose, and that given the symbiotic relationship between database platforms and web application, may want to include some additional database platform security discussions with the application security discussions that they have today.

My final suggestion on the topic of stored procedures has to do with external stored procedures. Most relational databases have the option of using external links and stored procedures to reference OS level code. This is in essence a program outside the database that can either run OS level functions, and often can use database functionality as well. I do not want to go into a long discussion here about the types of attacks that can be conducted through external code, or the dozens of issues pertaining to permissions, but simply comment that in using stored procedures for web applications, resist the urge to use external stored procedures or links. They can be very dangerous, and I typically advocate checking that the user rights do not include use of these external resources.