sql注入攻击仅对具有表单的页面构成威胁吗?
我知道这是一个简单的问题,但在我读过的所有内容中,我从未见过具体阐明的内容。
如果在页面上进行查询,是否需要担心SQL注入攻击?或者只是当您要求用户输入时才会出现问题?
谢谢!
I know it's a simple question, but in everything I've read, I've never seen this spelled out specifically.
If you do a query on a page, do you need to worry about SQL injection attacks? Or is it only a problem when you ask the user for input?
Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(13)
您不必拥有用户输入即可遭受 SQL 注入攻击。
假设您有一个使用如下 URL 调用的产品页面:
在您的代码中,您构建了如下查询:
有人可以使用此 url 调用您的页面:
嘭,您已经被骗了。
除了可以通过用户、查询字符串、帖子、cookie、浏览器变量等传递的任何内容之外,我认为始终使用参数是一个很好的做法,即使您的代码中有文字。例如:
这可能是注入安全的,但您的 RDBMS 会将它们缓存为两个不同的查询。
如果您将其修改为:
您将获得相同的结果,但 RDBMS 只会将其缓存为一个查询,并在运行时替换参数。我将其用作始终使用参数化查询的经验法则,只是为了保持一致,更不用说稍微改进缓存了。
You don't have to have user input to suffer a SQL injection attack.
Let's say you have a product page that is called using a URL such as this:
And in your code you have a query constructed such as this:
Someone could call your page with this url:
And bam, you've just been had.
In addition to ANYTHING that can be passed in via a user, querystring, post, cookie, browser variable, etc. I think it is just good practice to always use parameters, even if you have the literals in your code. For example:
this may be injection safe, but your RDBMS will cache them as two different queries.
if you modiy it to this:
You achieve the same result but the RDBMS will only cache it as one query, substituting the parameter at runtime. I use it as a rule of thumb to ALWAYS use parameterized queries, just to keep things consistent, not to mention a slight cache improvement.
SQL注入是由未经净化的数据引起的。您应该始终清理进入数据库的数据。不仅可以用于 SQL 注入,还可以使您的应用程序正常运行。
例如,某些系统不会使用我的名字,因为其中包含 ' 字符,并且它们的数据库未经过清理。我没有输入我的名字,我的名字是从另一个数据库中获取的。没关系——数据应该被清理。
SQL injection is caused by unsanitized data. You should always always always sanitize data going into a database. Not just for SQL injection, but also for making your app just work.
For example, some systems won't use my name because it has a ' character in it, and their database is not sanitized. I did not enter my name, my name was taken from another database. Doesn't matter -- the data should be sanitized.
SQL 注入片段也可以来自通过 GET 方法传入的查询字符串(也称为“URL 参数”)。
正如 Billy O'Neal [单引号的意思;-)] 所暗示的,任何不是程序(或其非常值得信赖的后端)固有的数据都应该被“清理”。 消毒一词似乎暗示着一个复杂的过程,但实际上它通常意味着:
[可能因您的特定 SQL 服务器品牌而异]
这种想法的可能原因是HTTP 表单将成为 SQL 注入片段的唯一来源,因为一项有效的建议是确保仅从请求表单中获取用户提供的提交文本。一些 Web 应用程序框架将 HTTP 请求公开为一个对象,默认情况下,该对象公开来自 QueryString、表单甚至 cookie 的所有键值对,可通过单个哈希进行访问。虽然这对于有时从表单获取信息有时从查询字符串获取信息的应用程序来说很实用,但这可以促进潜在注入者的工作,因为制作 URL 比制作表单更容易。 (但是使用适当的工具,也可以伪造 POST 请求......)
SQL Injection snippets can also come in from the QueryString (aka "URL arguments") passed in with the GET method instead.
As hinted by Billy O'Neal [single quote intended ;-) ], any piece of data that is not intrinsic to the program (or to its very trusted back-end), should be "sanitized". The Sanitizing term seems to imply to be a sophisticated process, but in effect it typically means little more than:
[may vary with your specific SQL server make]
A possible reason for the idea that HTTP Forms would be the only source of SQL injection snippets is that a -valid- recommendation is to ensure that one gets the user-supplied submitted text from the Request's form exclusively. Several Web Application frameworks expose the HTTP request as an object which exposes, by default, all key-values pairs from either the QueryString, from a Form, or even from cookies, accessible as from a single hash. While this can be practical for applications that sometimes get the info from a form an sometimes from the querystring, this can facilitate the work of would-be-injectors, because it is easier to craft a URL than a Form. (But with the proper tool, one can also fake a POST request as well...)
不,还有其他几种情况。例如,您可能将一些变量作为查询字符串传递到 php 页面。 “用户”可以修改该字符串以包含一些狡猾的脚本。
http://en.wikipedia .org/wiki/SQL_injection 包含大量有关漏洞类型以及如何有效应对这些漏洞的章节。
No, there are several other cases. For example, you may have some of the variables as a querystring passed into a php page. The 'user' could modify that string to include some dodgy scripting.
http://en.wikipedia.org/wiki/SQL_injection includes a large section on the types of vulnerabilities and how to combat them effectively.
总结一下 - SQL 查询中使用的任何类型的用户输入都是 SQL 注入的潜在目标
To summarize - any type of input from the user that is used in SQL queries is a potential target of sql injection
另请考虑防止跨站点脚本攻击 (" XSS”)。
Also consider preventing against cross-site-scripting ("XSS").
如果您使用来自浏览器的任何类型的数据,则 SQL 注入是可能的。它可以是表单数据、查询字符串数据、cookie 值,甚至是请求标头中的数据。
最明显且简单的方法是表单数据和查询字符串数据,但来自浏览器的任何内容都可能被欺骗。
SQL Injections is possible if you use any kind of data that comes from the browser. It could be form data, querystring data, cookie values, or even data from the request header.
The obvious and easy ways in is the form data and querystring data, but anything that comes from the browser could be spoofed.
代码从 HTTP 请求中获取的任何内容都可以是 SQL 注入向量:
在更高级别上,这些显示为 $_REQUEST 或 Page.Request 值、会话变量,这一切都取决于无数的因素。但最终,不仅仅是 POST 表单。尽管最流行的向量可能是表单 POST 内容和 GET URL 变量。
Anything that the code takes as input from the HTTP request can be a SQL injection vector:
At a higher level these show up as $_REQUEST or Page.Request values, session variable, it all depends on a miriad of factors. but ultimately, is not just POST forms. Although probably the most prvalent vector is form POST content and GET URL variables.
当用户可以修改查询参数的值时,它就可能成为威胁。
When the user can modify the values of the parameters of a query, then it can become a threat.
在这种情况下,如果数据您在页面上显示的数据来自用户提交的数据。
转义输入,过滤输出
You need to worry about cross site scripting (XSS) attacks in this case if the data you are displaying on the page came from user submitted data.
ESCAPE INPUT, FILTER OUTPUT
正如我所担心的,你永远不应该相信这些变量:$_POST、$_GET、$_REQUEST、$_COOKIE 甚至 $_SERVER 都可能包含恶意代码。因此,请务必确保插入的数据符合您的期望。
例如,作为验证电子邮件地址的额外偏执措施,您可以使用 md5 加密电子邮件地址,如下所示:
As I concern you should never trust this variables: $_POST, $_GET, $_REQUEST, $_COOKIE even $_SERVER can contain malicious code. So ALWAYS make sure that inserted data match your expectation.
For example as an extra paranoid measure on validation email address you can encrypt email address with md5 like this:
作为一般规则,应始终使用参数化查询。
在我的用例中,我总是生成基于参数的查询。我有一个包装器,它总是会编译它们,这样如果在同一请求路径中执行第二个查询,它将在同一连接上运行得更快。这需要相当多的工作来设置,但在任何中型到企业级系统中的性能提升都是值得的。
As a general rule parameterized queries should always be used.
In my use case I always generate parameter based queries. I have a wrapper that will always compile them so that if a second query gets executed in the same request path, it will run that much faster on the same connection. This takes a fair bit of work to setup, but is worth the performance gain in any medium to enterprise level system.
我同意参数化是最好的方法。
作为替代方案(至少在最初可能更容易重新适应您的代码),在字符串中加倍单引号将防止 SQL 注入。
以 Neil N 的例子为例:
将变量包装在双引号的函数中,并用单引号包装变量。
该函数类似于(VBscript 示例):
I agree that parameterisation is the best approach.
As an alternative (which might be easier to retro fit into your code, at least initially) doubling the single quotes in a string will prevent SQL Injection.
To take Neil N's example:
wrap the variable in a function that doubles the quotes, and wrap the varible with single quotes too.
The function would be something like (VBscript example):