参数真的足以防止 Sql 注入吗? [英] Are Parameters really enough to prevent Sql injections?

查看:38
本文介绍了参数真的足以防止 Sql 注入吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我一直在向我的同事和这里宣讲在 SQL 查询中使用参数的好处,尤其是在 .NET 应用程序中.我什至向他们保证对 SQL 注入攻击具有免疫力.

I've been preaching both to my colleagues and here on SO about the goodness of using parameters in SQL queries, especially in .NET applications. I've even gone so far as to promise them as giving immunity against SQL injection attacks.

但我开始怀疑这是否真的如此.是否有任何已知的 SQL 注入攻击可以成功针对参数化查询?例如,您能否发送一个导致服务器缓冲区溢出的字符串?

But I'm starting to wonder if this really is true. Are there any known SQL injection attacks that will be successfull against a parameterized query? Can you for example send a string that causes a buffer overflow on the server?

当然还有其他考虑因素要确保 Web 应用程序是安全的(例如清理用户输入和所有这些东西),但现在我正在考虑 SQL 注入.我对针对 MsSQL 2005 和 2008 的攻击特别感兴趣,因为它们是我的主要数据库,但所有数据库都很有趣.

There are of course other considerations to make to ensure that a web application is safe (like sanitizing user input and all that stuff) but now I am thinking of SQL injections. I'm especially interested in attacks against MsSQL 2005 and 2008 since they are my primary databases, but all databases are interesting.

澄清我所说的参数和参数化查询的含义.通过使用参数,我的意思是使用变量"而不是在字符串中构建 sql 查询.
所以不要这样做:

To clarify what I mean by parameters and parameterized queries. By using parameters I mean using "variables" instead of building the sql query in a string.
So instead of doing this:

SELECT * FROM Table WHERE Name = 'a name'

我们这样做:

SELECT * FROM Table WHERE Name = @Name

然后在查询/命令对象上设置@Name参数的值.

and then set the value of the @Name parameter on the query / command object.

推荐答案

Placeholders 足以防止注入.您可能仍然对缓冲区溢出持开放态度,但这是一种与 SQL 注入完全不同的攻击方式(攻击向量不是 SQL 语法而是二进制).由于传递的参数都将被正确转义,因此攻击者无法传递将被视为实时"SQL 的数据.

Placeholders are enough to prevent injections. You might still be open to buffer overflows, but that is a completely different flavor of attack from an SQL injection (the attack vector would not be SQL syntax but binary). Since the parameters passed will all be escaped properly, there isn't any way for an attacker to pass data that will be treated like "live" SQL.

不能在占位符内使用函数,也不能将占位符用作列名或表名,因为它们被转义并引用为字符串文字.

You can't use functions inside placeholders, and you can't use placeholders as column or table names, because they are escaped and quoted as string literals.

但是,如果您在动态查询中使用参数作为字符串连接的一部分,您仍然容易受到注入,因为您的字符串不会被转义,但会字面意思.使用其他类型的参数(如整数)是安全的.

However, if you use parameters as part of a string concatenation inside your dynamic query, you are still vulnerable to injection, because your strings will not be escaped but will be literal. Using other types for parameters (such as integer) is safe.

也就是说,如果您使用 use input 来设置诸如 security_level 之类的值,那么有人可以让自己成为您系统中的管理员,并且可以免费使用.但这只是基本的输入验证,与 SQL 注入无关.

That said, if you're using use input to set the value of something like security_level, then someone could just make themselves administrators in your system and have a free-for-all. But that's just basic input validation, and has nothing to do with SQL injection.

这篇关于参数真的足以防止 Sql 注入吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆