我可以使用哪些常见的 SQL 注入检查?
我正在运行我的网络应用程序,并尝试测试系统的各个部分,以确保它们不易受到 SQL 注入的影响。
我可以在文本框/文本区域等上执行哪些常见的 SQL 注入检查,这些检查可以很好地检查漏洞?
我并不担心会损坏我的数据,因为我在测试台上运行它,所以如果它杀死我的服务器或数据库也没关系。
我专门寻找可以使用的示例。我并不是真的在寻找整体技术,尽管我希望通过我希望获得的示例来涵盖各种不同的技术。
I'm running through my web app and I'm trying to test various parts of the system to make sure they aren't succeptible to SQL injection.
What are some common sql injection checks I can perform on textboxes/textareas, etc that would be good checks for vulnerability?
I'm not worried about damaging my data as I'm running this on a test bench so it's ok if it kills my server or database.
I'm specifically looking for examples I can use. I'm not really looking for overall techniques, although I hope to cover a variety of different techniques with the examples that I hope to get.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
您可能会发现此网站很有帮助
You might find this site helpful
如果您始终使用参数化查询或存储过程,则无需执行任何检查。
切勿使用动态 SQL,因为动态 SQL 部分基于用户的输入来构建 SQL 命令。这就是需要您清理输入的原因。
If you always use parameterized queries or stored procedures, then you don't have to do any checks.
Never use dynamic SQL, where you build the SQL command based in part on input from the user. That's what requires you to sanitize the input.
1) 如果您只使用不包含动态 SQL 的存储过程(并以参数化方式调用它们),那么您就可以开始了。
2) 如果您只在应用程序语言中使用准备好的语句,那么您就可以开始了。
3)如果以上都不是,您必须执行联盟语言特定命令来扫描您的文本,但您没有说出哪种应用程序语言。
编辑
故事的士气。如果字符串中包含用户提供给您的任何文本,则切勿在字符串中构建和执行 SQL 命令。将用户给定的文本作为参数传递给 sql 命令。 SQL 注入是指用户通过提供给您的文本来更改您的 SQL 命令。
例如:
您认为查询将是:
但如果给定的用户名是
查询,则最终将是:
1) if you only use stored procedures (and call them in a paramatized manner) that contain no dynamic SQL you are good to go.
2) if you only use prepared statements in your application language you are good to go.
3) if none of the above, you must do alliciation langauge specific commands to scan your text, but you don't say which application language.
EDIT
morale of the story. never build and execute a SQL sommand in a string if it contains any text given to you by the user. pass the user given text to the sql command as a parameter. SQL injection is the user changing your SQL command by the text they give you.
example:
you think Query will be:
but it if givenUserName is
Query will end up being:
只要确保您在任何地方都使用
SqlParameter
对象(假设是 .net),并且不连接 sql 查询,那么您将完全免受 SQL 注入的影响。-- 编辑
有些人说使用“存储过程”会有所不同。事实并非如此。如果您仍然构建查询来动态执行存储过程,那么您将面临风险:
在现代语言(特别是 .net)中,使用参数执行查询的唯一方法是使用 < code>SqlParameter 类,并指定适当的数据类型。
Just make sure you are using
SqlParameter
objects everywhere (assuming .net), and not concatinating sql queries, and you will be completely safe from SQL Injection.-- Edit
Some people are saying that using 'Stored Procedures' makes a difference. It doesn't. If you still build the query to execute the stored procedure dynamically, you are at risk:
The only way to execute a query, with parameters, in a modern language (and specifically .net) is by using
SqlParameter
class, and specifying the appropriate data types.SQL注入检查?比如,你应该害怕的字符串?
从长远来看,
SQL injection checks? As in, strings you should be scared of?
Much better in the long run to
参数的使用很方便,但这并不是保护自己免受 SQL 注入的唯一方法,也不是万无一失的。
如果存储过程在内部动态创建并在SQL 代码上执行EXEC(),您将失去全部该保护。如果您的应用程序中有一个包含这些字段但不使用参数或转义的单个查询,您也会失去这种保护。
参数并不神奇,您可以在构建 SQL 时通过简单地使用转义函数来保护自己:
用法:
Boom。简单如馅饼。甚至还负责 nvarchar 引用。
您可以将日期、数字、GUID 等转换为字符串并将它们传递给上面的函数,但最好为您使用的每种数据类型创建单独的函数。
有一个警告:每次构建查询时都必须使用它 - 每个包含此数据的 CRUD,无论是在应用程序层生成还是在存储过程中动态生成。
但您必须做同样的事情才能从参数中受益!所以无论哪种方式,你都必须改变你的习惯并审查你的代码。这是无法逃避的(蹩脚的双关语)。
The use of parameters is handy, but it is not the only way to protect oneself against SQL injection, nor is it foolproof.
If the stored procedure internally dynamically creates and performs an EXEC() on SQL code, you lose all of that protection. You also lose that protection if you have a single query in your application that includes those fields without using parameters or escaping.
Parameters aren't magic, and you can protect yourself by simply using an escape function when building your SQL:
Usage:
Boom. Easy as pie. Even takes care of the nvarchar quoting.
You can convert dates, numbers, GUIDs, etc to strings and pass them to the function above, but you're better off creating separate functions for each data type you use.
There is one caveat: you have to use it every single time you build a query-- every CRUD that includes this data, whether produced at the application layer or generated dynamically inside a stored procedure.
But you have to do the same thing to benefit from parameters! So either way, you have to change your habits and review your code. There is no escaping that (lame pun intended).
您也可以使用 ASP ADO 对象在经典 ASP 中使用参数。
这是一个小例子:
我已经很长时间没有编写任何经典的 ASP 了,所以这段代码可能无法按原样运行。然而,它提供了如何在经典 ASP 中使用参数来防止 SQL 注入的想法。
You can use parameters in classic ASP as well, using the ASP ADO objects.
Here's a small example:
It's been a long time since I wrote any classic ASP, so this code will probably not work as is. However, it gives an idea of how parameters can be used in classic ASP as well to prevent SQL injections.
任何带有 ' 的东西。
Anything with a ' in it.