C、C++和Java安全编码实践提示与技巧

现在，LoadTypeFromStream 执行，并将 256 个字节写入所提供的地址，也就是在我们调用函数之前堆栈指针（SP）的值。这会覆盖应该使用的 128 个字节（本例中位于地址 0x1000 处），加上随后的 128 个字节，包括传入的参数指针、返回地址以及堆栈中随后 128 个字节内存储的其他任何信息。

那么攻击者怎样利用这样的漏洞呢？并不简单，需要经过反复的试错。实际上，攻击者要安排攻击，使覆盖的返回地址将控制权移交给攻击者，而非预期调用方函数。因而，攻击者需要准确了解要利用哪些数据结构，这样的数据结构在要攻击的任意版本的操作系统或应用程序上有多大、周边有哪些内容（以便正确设定伪造的返回地址）、如何有意义地插入足够的信息以使返回地址和其他效果能够实现某种恶意操作。

这一切做起来并不简单，但多种多样的攻击表明，总是有人有太多的空闲时间。

应如何防范此类攻击？这是一次攻击还是多重攻击？所写入的代码是否真的像这里所显示的这样笨拙？现代编译器是否会对堆栈帧布局做一些特殊处理，以避免此类问题？

总而言之，模糊处理就等于没有防御。我们都认识到，程序员将攻击预想得越简单，攻击出现的可能性就越高。然而，即便是复杂的代码，若未进行合理防御，也迟早会受到攻击。这种利用被污染的数据流和非常基本的缓冲溢出漏洞的攻击，多年以来这一直是热门的研究课题，但每年仍然会出现大量此类攻击。

防范此类攻击的效果甚微，因为攻击形式复杂——注意您的数据假设。只要在示例1（a）中添加一行简单的代码，就会使其更加安全，参见示例1（c）。显然，随着流交互变得更加复杂，保护的要求也随之复杂化，但基本上说代码注入是编码中“不可饶恕”的过失，因为防范它的方法是那样普及和简单。

SQL 注入

此外还存在其他一些类型的 SQL 注入，可能会给以数据库为中心的应用程序造成严重的问题。在某些情况下，攻击者只是尝试访问更多的内容。在另一些情况下，攻击者关注的则是在数据库中存储新信息，以便使应用程序此后在不知情的前提下使用此类信息，入侵最终用户的会话。

基于查询的攻击关注的是一种普遍应用的反模式，使用字符串串联构建查询。这种类型的漏洞常常出现在面向 Web 的应用程序中，在所有常用页面产品——包括 PHP、ASP、JSP 等及其后备控制器逻辑中同样常见。

这种漏洞的核心是开发人员使用直接查询执行，而非利用查询准备来运行数据库交互。考虑以下登录验证查询示例：

SELECT ID FROM USERS WHERE NAME= ''user'' AND PWD=''password''

用户将看到一个简单的 HTML 表单，该表单包含两个输入框并使用了这种反模式。从表单传入的参数（无论所讨论的页面产品是怎样接收到这些参数的）都将通过串联直接代入查询的字符串形式。

考虑攻击者提供的一组参数：

NAME:　　 x

PWD:　　　 x'' OR ''1'' = ''1

运行串联，结果将得到被利用的查询：

SELECT ID FROM USERS WHERE NAME=

''x'' AND PWD=''x'' OR ''1'' = ''1''

如果登录仅检查该语句执行成功与否（而未考虑结果行），攻击者即可迅速获得该应用程序所处理的任意用户记录可提供的任意访问权限。很多应用程序的用户表的第一行都是为超级用户保留的，攻击此类应用程序轻而易举。

利用未谨慎处理数据库语句内代入字符串的应用程序，攻击者可实现多种其他形式的攻击。这种反模式极为常见（参见最近的 Microsoft 公告和其他内容了解其普遍性），缓解方法也同样简单，并可置于基本数据库 API 之中：使用准备好的语句而非字符串串联。

例如，考虑示

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!