PDA

View Full Version : SQL Stored Procedure - update column/table names via variable



Stripeman
11 Aug 2008, 11:41 AM
I didn't know where else to post this because its not directly related to EXT. But I thought upldating a database column via variable or even updating a table via variable was not a common find. I searched and searched for this solution and found only one. (REF: http://vyaskn.tripod.com/sql_server_search_and_replace.htm) We took this example, simplified it and created our own Stored Procedure.

I hope this is the right spot. Feel free to move it if it don't belong here.




USE [AUTHENTICATION] //DB name
GO
/****** Object: StoredProcedure [dbo].[usp_UpdateOneUserColumn] Script Date: 08/08/2008 16:03:52 ******/
SET ANSI_NULLS ON //all comparisons against a null value evaluate to UNKNOWN
GO
SET QUOTED_IDENTIFIER ON //identifiers can be delimited by double quotation marks, and literals must be delimited by single quotation marks
GO
-- =============================================
-- Author: <Greg M and Terry R>
-- Create date: <08/08/2008 16:03:52>
-- Description: <Update column/table via variable>
-- =============================================
CREATE PROCEDURE [dbo].[usp_UpdateOneUserColumn] /or UPDATE PROCEDURE [USER].[Stored Proceedure Name]
-- Add the parameters for the stored procedure here
@userid nvarchar(20),
@tablename nvarchar(128),
@col nvarchar(128),
@val nvarchar(1000)

AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
DECLARE @SQL NVARCHAR(4000)
BEGIN
SET @SQL = 'UPDATE ' + @tablename + ' SET ' + @col + ' = ''' + @val + ''' WHERE userid = ''' + @userid + ''''
EXEC(@SQL)
END
END




//TO use:
EXEC dbo.usp_UpdateOneUserColumn '0239523622', 'tbl_name', 'col_username', 'Remsikt' //User ID, Table name, Column, and product type (value)
//Please note order: the arguments have to be in order in which is specified by the definitions above
//IE: @userid nvarchar(20),
// @tablename nvarchar(128),
// @col nvarchar(128),
// @val nvarchar(1000)

JanDV
3 Oct 2008, 1:15 AM
Looks very dangerous for SQL injection to me.

Stripeman
3 Oct 2008, 1:23 AM
Well, you as a programmer have to validate that data. I am using this with C# and not building my sql statments. I'm not using any post, get or any request values at all.

djfiii
5 Oct 2008, 9:19 AM
why don't you used prepared statements? you are wide open to sql injection with that stored proc. pawning off the responsibility to another developer when it is within your power to prevent the hole is irresponsible.

Stripeman
5 Oct 2008, 9:53 AM
why don't you used prepared statements? you are wide open to sql injection with that stored proc. pawning off the responsibility to another developer when it is within your power to prevent the hole is irresponsible.

Snippy. Snippy.
Prepared? You mean static statements? No. A few things.
1. The site is an intranet site, on a closed network allows some flexibility
2. There is no way for the the user to enter sql into the statement the way we are doing it. Not to mention we are checking the data is what we expect it to me. (escaped, int or string etc)
3. I never told anyone to use it.. Merely showing a way to do it.
4. Keeping the sql dynamic allows for much greater flexibility and scalability. We are not writing our sql in our programming code IE:

<?php
$getRecord = "SELECT user,password FROM users WHERE user = '" . $_POST['username'] . "'";
?>

We are using c# and NONE of our sql is even in the C# code.

I dont see the risk and me being irresponsible ? And what other developer am i 'pawning off the responsibility ' to? Thats coming off a bit way too arrogant don't you think ? You would think one would pose the question "Why are you doing it like that? YOu should do it like this...". Yea.. ill be the first one to reply to your posts.

jaxian
5 Oct 2008, 3:12 PM
You right Stripeman, you are on the right direction using SP (Stored Procedures), SP also are compiled and if you use C# all is controlled by the strong types variables that may be used on the "code behind", so an object instance and not a POST or REQUEST noob method are involved on this case..........Also, on MS SQL SERVER you can set permissions over SP execution.

Plus this application RUNS on a INTRANET!!

I think that the users that are seeing the possibilitie of SQL INJECTION, use the typical SQL STATEMENT inside a variable and don't have any experience on T-SQL. So they see only a secuential execution of the script, and not a architectural, point of view (OOP + TSQL + SOA).

I'm an PHP OOP Developer and .NET Developer, and TSQL programmer not only on MS SQL SERVER, SYBASE ASE and Db2, also on my lovely MySQL5 that support SP. I see day to day this closed and very limited point of view, developers how work only on PHP that use only the tables object on MySQL and don't use SP and TSQL capacity of MySQL, why?

Experience! They only has one limited a procedural point of view, so if they look and SP like
this case, are not prepared to see the diference about an STATEMENT and SP.


So, i say to this Noobs, try to INJECT a STATMENT on a MS SQLSERVER SP, no way!
The parameters has types, the types has bindings (IN, OUT /IN-OUT), is a high level
of develoment process....not a MYSQL_QUERY("DELETE......, again no way!


So...Use SP guys, change the way that you are intefacing MYSQL for an MYSQLI, be PRO.
Again Stripeman you right! Regards.