How to Obfuscate SQL Sprocs?

六月ゝ 毕业季﹏ 提交于 2019-12-04 03:55:46

I can vaguely understand obfuscating code if it's extremely advanced in what it does, but I think obfuscating your SQL may not be worth the hassle.

Anyway, a lot of the SQL I've seen around here comes obfuscated as standard.

See the ENCRYPTION option for the CREATE PROCEDURE statement.

http://msdn.microsoft.com/en-us/library/ms187926.aspx

Matt Rogish

No. At least, not in a way that is irreversible. SQL Server 2000's "WITH ENCRYPTION" can be reversed to get the original plaintext. The pseudo-code and a T-SQL script that illustrates this is here: http://education.sqlfarms.com/education/ShowPost.aspx?PostID=783

Note: I haven't tried it with SQL 2005 or above, but my guess is it is just as vulnerable.. As the MSDN docs state:

ENCRYPTION Indicates that SQL Server will convert the original text of the CREATE PROCEDURE statement to an obfuscated format.

Emphasis is mine.

One option would be to place just the sensitive portions of the stored procedure in a CLR stored procedure, and obfuscate that assembly using a professional obfuscation product.

http://msdn.microsoft.com/en-us/library/ms131094.aspx

jason saldo

Easily reversible if you know but intimidating to to most people poking around code. hex encode you sproc logic and then execute with EXEC(@hexEncodedString).
see this post.

Old post, I know. But I got here from searching 'Why should I obfuscate SQL?' I just installed a free product called ApexSQL Refactor (no affiliation) which offers an obfuscation component.

It offers several different options for making your code hard to read. I wasn't sure why I'd want such a feature given, as others noted the ability to encrypt your stored procedures. Anyway, this is an example of the output it can return from it's obfuscation function.

CrEAtE Procedure spInsertOrUpdateProduct @ProductNumber nVarChar(25),
@ListPrice Money aS IF exIsTS(selECt * FROm Production.Product WHere
ProductNumber=@ProductNumber AnD ListPrice>1000) uPdatE Production.
Product sET ListPrice=(ListPrice-100) where ProductNumber=
@ProductNumber elsE INSerT intO Production.Product(ProductNumber,
ListPrice) SelECT @ProductNumber,@ListPrice GO SElEct * fRoM
Production.Product gO iNsERT iNTo Production.UnitMeasure(
UnitMeasureCode,Name,ModifiedDate) vAlUeS(N'FT2',N'Square Feet',
'20080923'); Go

You could use the ENCRYPTION clause when creating the stored procedure.

This would rely on not leaving the source SQL on the customer machine though.

See here for more info:

http://msdn.microsoft.com/en-us/library/ms187926(SQL.90).aspx

You can always write ordinary code in C# (or VB) and store it outside the database in a DLL.

Then you don't have to worry about obfuscating your SQL.

If you're really worried about someone getting into the DB and seeing the source for the procedure, then as S. Lott said, you can port the procedure to C#. I would recommend LINQ.

However, the database itself should probably be protected from people accessing the code for procedures that shouldn't be. You can restrict a user or group's rights to only have EXECUTE access to a proc if needed.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!