Core Security Technologies公司的研究员开发了一种新的自动黑客技术，能让攻击者轻易地找到和攻击SQL注入漏洞，还有攻击者常用的代码错误。以下就是对防御SQL注入攻击的详细内容的描述。
由Core reSearcher Sebastian Cufre组织的研究可以帮助漏洞查找者提高发现SQL注入漏洞的效率，这样以来可以在攻击者利用它们之前就将漏洞修复好。Cufre不能参加这一会议，所以CoreLabs的研究员Fernando Federico Russ在2010年的CanSecWest应用安全会议上演示了这一黑盒技术。
Russ说：“这有助于自动查找和攻击SQL注入漏洞，最棒的是有一个SQL提取功能，能让你在后端数据库上直接执行SQL语句。”
SQL注入一直是种流行的攻击技术，因为代码错误会让攻击者获取Web应用程序的访问权，这在许多网站中都很常见。攻击者能够在Web表格中添加结构化的查询语言（SQL）来测试数据库，以检查结果数据库的调试错误并获取访问权限。
黑客工具包让攻击者能更容易地攻击和危害网站，并将网站上建立的恶意代码传播给网站访问者。企业已采取措施，减少Web应用程序中的SQL注入代码错误。
Russ的技术研究显示了黑客测试技术如何被应用来高效查找SQL注入错误。黑盒测试为获取黑客动向采取了外部方式来测试软件。它让软件测试员理解黑客在受危害的机器上可能采取的攻击类别。
Russ说：“我们正努力掌握漏洞知识和推断串注入点的标准测试。”
这一技术消除了自动SQL注入漏洞评估过程中的误报情况。这一方法还可自动生成攻击代码。Core计划在它的网站上发布相应的研究论文。
目前，网站站长们有很多方法来测试他们网站上的代码错误。很多静态和动态代码分析工具能够用来查找可导致SQL注入的代码错误，尽管专家们称这些工具越来越先进，但其中的大多数工具还是存在很大的误差和很高的误报率。2008年的时候，SQL注入攻击非常严重，微软曾在公告中指出了几款可消除开发过程中错误的工具。
另外，组织机构可以限制用户的访问权限，在应用程序全面投入运营之前，通过应用静态代码分析来检测错误，以改进软件开发过程。而且可在SQL串导致底层数据库崩溃时，减少显示给用户的调试错误。
【编辑推荐】
java拼接sql怎么防止注入
使用Hibernate框架的SQL注入防范 Hibernate是目前使用最多的ORM框架，在Java Web开发中，很多时候不直接使用JDBC，而使用Hibernate来提高开发效率。 在Hibernate中，仍然不应该通过拼接HQL的方式，而应使用参数化的方式来防范SQL注入。 有两种方式，一种仍然是使用JDBC一样的占位符“?”，但更好的方式是使用Hibernate的命名参数，例如检测用户名和密码是否正确，使用Hibernate可以写成：String queryStr = “from user where username=:username ”+”passWORD=:password”;List result = (queryStr)(username, username)(password, password)();
MyBatis怎么防止SQL注入
SQL注入是一种代码注入技术，用于攻击数据驱动的应用，恶意的SQL语句被插入到执行的实体字段中（例如，为了转储数据库内容给攻击者）。 [摘自] SQL injection - WikipediaSQL注入，大家都不陌生，是一种常见的攻击方式。 攻击者在界面的表单信息或URL上输入一些奇怪的SQL片段（例如“or ‘1’=’1’”这样的语句），有可能入侵参数检验不足的应用程序。 所以，在我们的应用中需要做一些工作，来防备这样的攻击方式。 在一些安全性要求很高的应用中（比如银行软件），经常使用将SQL语句全部替换为存储过程这样的方式，来防止SQL注入。 这当然是一种很安全的方式，但我们平时开发中，可能不需要这种死板的方式。 MyBatis框架作为一款半自动化的持久层框架，其SQL语句都要我们自己手动编写，这个时候当然需要防止SQL注入。 其实，MyBatis的SQL是一个具有“输入+输出”的功能，类似于函数的结构，如下：SELECT id,title,author,content FROM blogWHERE id=#{id}这里，parameterType表示了输入的参数类型，resultType表示了输出的参数类型。 回应上文，如果我们想防止SQL注入，理所当然地要在输入参数上下功夫。 上面代码中黄色高亮即输入参数在SQL中拼接的部分，传入参数后，打印出执行的SQL语句，会看到SQL是这样的：SELECT id,title,author,content FROM blog WHERE id = ?不管输入什么参数，打印出的SQL都是这样的。 这是因为MyBatis启用了预编译功能，在SQL执行前，会先将上面的SQL发送给数据库进行编译；执行时，直接使用编译好的SQL，替换占位符“?”就可以了。 因为SQL注入只能对编译过程起作用，所以这样的方式就很好地避免了SQL注入的问题。 【底层实现原理】MyBatis是如何做到SQL预编译的呢？其实在框架底层，是JDBC中的PreparedStatement类在起作用，PreparedStatement是我们很熟悉的Statement的子类，它的对象包含了编译好的SQL语句。 这种“准备好”的方式不仅能提高安全性，而且在多次执行同一个SQL时，能够提高效率。 原因是SQL已编译好，再次执行时无需再编译。 话说回来，是否我们使用MyBatis就一定可以防止SQL注入呢？当然不是，请看下面的代码：SELECT id,title,author,content FROM blogWHERE id=${id}仔细观察，内联参数的格式由“#{xxx}”变为了“${xxx}”。 如果我们给参数“id”赋值为“3”，将SQL打印出来是这样的：SELECT id,title,author,content FROM blog WHERE id = 3（上面的对比示例是我自己添加的，为了与前面的示例形成鲜明的对比。 ）SELECT id,title,author,content FROM blogORDER BY ${orderParam}仔细观察，内联参数的格式由“#{xxx}”变为了“${xxx}”。 如果我们给参数“orderParam”赋值为“id”，将SQL打印出来是这样的：SELECT id,title,author,content FROM blog ORDER BY id显然，这样是无法阻止SQL注入的。 在MyBatis中，“${xxx}”这样格式的参数会直接参与SQL编译，从而不能避免注入攻击。 但涉及到动态表名和列名时，只能使用“${xxx}”这样的参数格式。 所以，这样的参数需要我们在代码中手工进行处理来防止注入。 【结论】在编写MyBatis的映射语句时，尽量采用“#{xxx}”这样的格式。 若不得不使用“${xxx}”这样的参数，要手工地做好过滤工作，来防止SQL注入攻击。 [摘自] mybatis的#{}和${}的区别以及order by注入问题#{}：相当于JDBC中的PreparedStatement${}：是输出变量的值简单说，#{}是经过预编译的，是安全的；${}是未经过预编译的，仅仅是取变量的值，是非安全的，存在SQL注入。 如果我们order by语句后用了${}，那么不做任何处理的时候是存在SQL注入危险的。 你说怎么防止，那我只能悲惨的告诉你，你得手动处理过滤一下输入的内容。 如判断一下输入的参数的长度是否正常（注入语句一般很长），更精确的过滤则可以查询一下输入的参数是否在预期的参数集合中。
如何从根本上防止 SQL 注入
SQL注入并不是一个在SQL内不可解决的问题，这种攻击方式的存在也不能完全归咎于SQL这种语言，因为注入的问题而放弃SQL这种方式也是因噎废食。 首先先说一个我在其他回答中也曾提到过的观点：没有（运行时）编译，就没有注入。 SQL注入产生的原因，和栈溢出、XSS等很多其他的攻击方法类似，就是未经检查或者未经充分检查的用户输入数据，意外变成了代码被执行。 针对于SQL注入，则是用户提交的数据，被数据库系统编译而产生了开发者预期之外的动作。 也就是，SQL注入是用户输入的数据，在拼接SQL语句的过程中，超越了数据本身，成为了SQL语句查询逻辑的一部分，然后这样被拼接出来的SQL语句被数据库执行，产生了开发者预期之外的动作。 所以从根本上防止上述类型攻击的手段，还是避免数据变成代码被执行，时刻分清代码和数据的界限。 而具体到SQL注入来说，被执行的恶意代码是通过数据库的SQL解释引擎编译得到的，所以只要避免用户输入的数据被数据库系统编译就可以了。 现在的数据库系统都提供SQL语句的预编译（prepare）和查询参数绑定功能，在SQL语句中放置占位符?，然后将带有占位符的SQL语句传给数据库编译，执行的时候才将用户输入的数据作为执行的参数传给用户。 这样的操作不仅使得SQL语句在书写的时候不再需要拼接，看起来也更直接，而且用户输入的数据也没有机会被送到数据库的SQL解释器被编译执行，也不会越权变成代码。 至于为什么这种参数化的查询方式没有作为默认的使用方式，我想除了兼容老系统以外，直接使用SQL确实方便并且也有确定的使用场合。
发表评论