有没有办法隐藏/保护/混淆 MS SQL 存储过程？
问问题
9343 次
10 回答
10
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.
于 2009-01-07T16:06:57.977 回答
10
If you must hide it, how about the "WITH ENCRYPTION" clause?
于 2009-01-07T16:09:45.770 回答
6
See the ENCRYPTION option for the CREATE PROCEDURE statement.
于 2009-01-07T16:10:32.523 回答
4
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.
于 2009-01-07T16:20:21.287 回答
2
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.
于 2009-01-07T16:27:20.447 回答
2
如果你知道的话很容易可逆，但对大多数浏览代码的人来说是可怕的。十六进制编码你的存储逻辑，然后用 EXEC(@hexEncodedString) 执行。
看到这个帖子。
于 2009-01-07T16:46:43.433 回答
2
老帖子，我知道。但我是通过搜索“我为什么要混淆 SQL？”来到这里的。我刚刚安装了一个名为 ApexSQL Refactor（无从属关系）的免费产品，它提供了一个混淆组件。
它提供了几种不同的选项来使您的代码难以阅读。我不确定为什么要提供这样的功能，因为其他人注意到加密存储过程的能力。无论如何，这是它可以从其混淆功能返回的输出示例。
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
于 2016-03-18T14:24:15.997 回答
1
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
于 2009-01-07T16:12:05.827 回答
0
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.
于 2009-01-07T16:08:26.303 回答
0
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.
于 2009-01-07T16:11:25.940 回答