SQL注入 - 存储过程 [英] SQL Injection - Stored Procedures
问题描述
我已经在这个特定的项目上工作了两个多星期了。该产品包含700-900个存储过程，可以处理产品中您能想到的所有内容。我亲自重写/重新格式化了我自己的近150个。没有什么太花哨，大多数格式化。我们在Q / A和修复他们发现的任何错误之间有一点停机时间，因此我决定使用跨站点脚本和SQL注入来测试站点的安全性。因为SP'几乎用在网站的每个方面，所以网站不能用于简单的注入内容，比如'
OR 1 = 1。相反，我必须尝试一些我将在一分钟内完成的事情。由于我可以访问所有这些SP和它们所在的dB，我可以轻松查看代码并确定
需要传递哪些变量。我去过试图打破网站放弃数据库名称，以便我可以继续检查系统表等等 - 就像一个普通的黑客一样（意思是不是通过查看代码来欺骗
）。所以，我已经通过下载本地版本的登录页面来开始我的攻击，更改了一些变量并注入了类似的东西：
''SELECT * FROM INFORMATION_SCHEMA.TABLES
最初，语句被传递到表单字段中，除了JS弹出错误之外不会返回任何内容。我有意改变了声明以打破页面
SELECT * FROM INFORMATION_SCHEMA.TA''
它会产生错误，给我查询的名称和它的位置
当我在网址中插入查询的名称，即 http://theurl.com/query_folder/query_name/ 它将我发送到包含某种包含文件的另一个文件夹。
当我运行包含它时，它给了我这个名字一个非常重要的变量。它是一个确定我应该指向什么dB的变量。
现在，我遇到的一个问题是一切都是存储过程所以试图破解它有点困难。但是因为我有SP名称和其需要的变量之一（通过
大量测试找到）我一直在尝试构造一些会产生错误以产生dB或表名的东西。攻击看起来像这样：
''SET @ var2Exec ='DECLARE @ var1 VARCHAR（2000）; DECLARE @ var2 INT SET @ var1 =''SELECT * FROM INFORMATION_SCHEMA.TABLES''SET @ var2 = 12345; EXEC（@ var1）''
''EXEC（@ var2Exec）''
我总是会返回一个错误，说@ var2是错误的基本上这意味着我将2个变量传递给需要2个以上的SP。所以我的问题是，有没有人知道
如何利用存储过程的本质？它可以完成，但我对SQL注入的知识非常有限，但是想知道是否有人以这种方式测试自己的网站。任何
建议将不胜感激。
I have been working on this particular project for a little over 2 weeks now. This product contains between 700-900 stored procedures to handle just about all you can imagine within the product. I
just personally rewrote/reformatted close to 150 of them myself. Nothing too fancy, mostly a lot of formatting. We have a little down time between Q/A and fixing any bugs they find so I decided to
test the security of the site with Cross-Site Scripting and SQL injection. Because SP''s are used in pretty much every aspect of the site, the site isnt vunerable to the simple Injection stuff like ''
OR 1 = 1 . Instead I''ve had to try several things which I will get to in a minute. As I have access to all of these SP''s and the dB in which they reside, I could easly look at the code and determine
what variables are neede to pass in. I''ve been trying to break the site to give up a database name so I can proceed to check the system tables etc etc - much like a regular hacker would (meaning not
cheating by looking at the code). So, I''ve started my attack by downloading a local version of the login page, changing a few variables and injected somthing like:
''SELECT * FROM INFORMATION_SCHEMA.TABLES
Initially, the statement is passed into the form fields and wont return anything other than a JS popup error. I altered the statement intentionally to break the page
SELECT * FROM INFORMATION_SCHEMA.TA''
and it produces an error giving me the name of the query and its location
when I plug the name of the query in the url i.e http://theurl.com/query_folder/query_name/ it fires me off to another folder containing an include file of some sort.
When I run that include it gives me the name of a pretty important variable. Apparetly its a variable that determins what dB I should point to.
Now, one of the issues I have is that everything is a stored procedure so trying to hack it is a little more difficult. But because I have the SP name and one of the variables its needs (found through
lots of testing) I''ve been trying to construct something that will throw an error to produce a dB or table name. The attack looks something like this:
''SET @var2Exec = 'DECLARE @var1 VARCHAR(2000); DECLARE @var2 INT SET @var1 = ''SELECT * FROM INFORMATION_SCHEMA.TABLES'' SET @var2 = 12345 ; EXEC(@var1)''
''EXEC(@var2Exec)''
I will always return an error saying that @var2 is of the wrong type etc. Essentially this means that I am passing in 2 variables to a SP that requires more than 2. So my question is, does anyone know
of a way to exploit the nature of Stored Procedures? It can be done, but my knowledge of SQL Injection is pretty limited but was wondering if anyone tests their own sites in this manner. Any
suggestions would be greatly appreciated.
推荐答案
另一方面，我读了一些其他人的帖子处理SQL注入。老实说，有两件事你应该被置之不理。 SQL注入和跨站点脚本。通常它们是彼此组合使用的。
SQL注入最容易被使用正则表达式来验证所有数据。虽然JavaScript很快，但服务器端更好，特别是在验证敏感数据时。您可以使用
去除大多数使SQL注入更容易的字符。你永远不会有一个或密码字段中的''，为什么要允许它？正则表达式可以轻松地关闭攻击。另一种方法是
设置自定义错误页面。为什么要向攻击者提供超出需要的信息。如果检测到错误 - 将它们关闭到一个自定义错误页面，说明抱歉我们不能....不要给他们访问
到列出表名等的ODBC错误。它不是万无一失的但它关闭了攻击者的另一扇敞开的大门。
跨站点脚本或CSS是一个人下载表单本地副本甚至cookie的能力，改变其内容，然后将其从浏览器提交到实际网站。这可能是一个问题（特别是在购物车中），攻击者可以向表单处理器提交错误值。数据有效但其值有误。我通过检查
推介页面的位置来解决这个问题。特别是在处理购物车时，第1页将被检查，以查看信息是来自第1页还是来自其他地方。
这些是非常简单的我做的事情，以帮助我的网站更安全。你应该学会破解你自己的网站。它最终让你成为一个更好的编码器。
P.S.有可能利用存储过程 - 但它需要花费很长时间来完成它。
~Bastard
On another note I''ve read a few posts that others have had dealing with SQL Injection. Honestly there are 2 things you should be concerend about. SQL Injection and Cross Site Scripting. Often they are
used in combination with one another.
SQL Injection is most easily defeated using regular expressions to validate all of your data. While JavaScript is fast, Server Side is better, especially when validating for sensative data. You can
strip out most characters that make SQL injection easier. You wouldnt ever have a " or a '' in a password field, so why allow it? Regular Expressions can easly shut down an attack. Another way is to
set up a custom error page. Why give the attacker any more information than needed. If an error is detected - fire them off to a custom error page that says sorry we cannot .... dont give them access
to the ODBC errors that list the table names etc. Its not fool proof but it closes another open door to an attacker.
Cross Site Scripting or CSS is the ability for a person to download a local copy of the form or even a cookie, alter its contents, and then submit it from their browser to the live site. This can be
an issue (especially in shopping carts) where an attacker can submit a false value to your form processor. The data will be valid but its value is wrong. I deal with this by checking where the
referral page is. Especially when dealing with shopping carts Page 1 will be sent to Page 2 - Page 2 checks to see if the info came from Page 1 or originated somewhere else.
These are a few really simple things I do to help keep my sites safer. You should really learn to hack your own sites. It makes you a better coder in the end.
P.S. it is possible to exploit Stored Procs - but it takes a hell of a long to time to do it.
~Bastard
B？§T？RD写道：
B?§T?RD wrote:
需要2个以上。所以我的问题是，有没有人知道利用存储过程的本质的方法？它可以完成，但是我对SQL注入的了解非常有限，但是想知道是否有人以这种方式测试自己的网站。任何建议都会非常感激。
that requires more than 2. So my question is, does anyone know of a
way to exploit the nature of Stored Procedures? It can be done, but
my knowledge of SQL Injection is pretty limited but was wondering if
anyone tests their own sites in this manner. Any suggestions would be
greatly appreciated.
从存储过程中获得的一个值是对SQL
注入的抵制。我说拒绝保护而不是保护，因为你仍然可以承担风险，如果你做了这样的蠢事：
EXEC @DynamicSQLBuiltInMyProcedure
如果没有动态执行，参数会使您免于注入。一件事
我注意到你没有提供你的界面的详细信息。你如何构建你的SP呼叫是一个潜在的漏洞点，例如：
CN.Execute（" MySP" + ParameterList）
此外，一些错误处理对于保护脚本和数据库的详细信息还有很长的路要走：
try {
RS = CN.Execute（...）
} catch（e）{
SendErrorEmail（e）
Page.Message ="访问数据时出错
}
显然，JScript中的所有示例都是。
-
戴夫安德森
未经请求的商业电子邮件将以每封邮件
One of the values you get from stored procedures is resistence to SQL
injection. I say resistence instead of protection because you can still
expose yourself to risk if you do something dumb like this:
EXEC @DynamicSQLBuiltInMyProcedure
Without dynamic execution, parameters insulate you from injection. One thing
I note is that you have not provided details on your interface. How you
construct your SP call is a potential point of vulnerability, such as:
CN.Execute("MySP " + ParameterList)
Also, a bit of error handling goes a long way toward protecting the details
of your scripts and your DB:
try {
RS = CN.Execute( ... )
} catch(e) {
SendErrorEmail(e)
Page.Message = "Error accessing data"
}
All examples in JScript, obviously.
--
Dave Anderson
Unsolicited commercial email will be read at a cost of
500的费用阅读。使用
此电子邮件地址即表示同意这些条款。请不要直接联系
我或要求我直接与您联系以获取帮助。如果您的
问题值得询问，那就值得发帖。
500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it''s worth posting.
这篇关于SQL注入 - 存储过程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
