怎 样 寻 找 安 全 漏 洞

怎 样 寻 找 安 全 漏 洞 (转贴自安络科技)
    
描述：
怎 样 寻 找 安 全 漏 洞
  
详细：
备注：我没有找到任何安全漏洞，因此拿这篇文章当作小菜一碟。对于这篇文章有更好的组织和语法建议，我张开双手欢迎。任何错误的报告都是紧急必需的。

如果一个有漏洞的程序在极端的情况下表现出来，那么，正常地，它只是一个小问题。通常，你只须避免这种极端的出现，那么臭虫不是个问题。如果你愿意，通过自己编程，你能复制引起这个臭虫的效果。

但是，有时候，程序处于安全的边缘。它们从某些没有同样权限的程序中读入操作。有些例子：你的邮件阅读器从你的发信人之处读入，这种信通常只对你有权而对其它人不开放。任何连上互联网的电脑的TCP/IP堆栈读取网上所有人的资源。对此而言，网上大部分人都无权如此。

做这此事情的程序必须小心设计。若有任何漏洞，它就有潜在的可能允许其他人（末授权用户）做他们权限之外的事。有这种特征的臭虫、称“漏洞”或更正式一点――“脆弱性”。

下面是一些通常漏洞的分类。

结构方面：
当你写一个软件，你的目标是使用者正确操作时，某事成为可能。当你写一个安全敏感的软件时，你也必须使某事不可能而不管不信任用户如何做。这意味着你的程序的某些部分必须在一个十分广阔的环境中运行正确。

漏洞的改变：
大量的漏洞来自于运行于不同环境下的程序。首先是一个小小的问题，甚至是一个便利，最终变成了一个漏洞。

例如：假设你有一个脚本解释器，它本设计成让你在打印之前预览文档。这不是个安全敏感漏洞。脚本解释器无任何你本身不具有的权力。但是，如果你使用它浏览其它你不认识的甚至是不可信任人的文档。突然，这个脚本解释器变成了一个线程。某些人就能够寄一篇摧毁你文档的东西给你，或者将你方件拷贝于他们能得到的地方。

在大多数UNIX系统的TCP/IP堆栈中，这是问题的根源。它们发展于一个人们相互信任的网络之上，但是现在它们被网上不该信任的用户所得用。

这也是SENDMAIL的问题。在进行审计之前，它一直是个漏洞。

在一个更微妙的层次：当函数不跃过信任边界时，它们十分安全，但稍一越轨，灾难便开始了。函数GETS（）是个极好的例子。你使用GETS（）控制输入，你只是提供了一个比你预料大一点的缓存。但若偶然地提供过大的输入，这个模式便不会运作它或可能溢出缓存进行编译。

但当数据来自于一个不可信任源时，GETS（）能溢出缓存并能导致程序做任何事。冲突是最普遍的结果，但你通常能小心地架构数据使程序以可执行代码运行。

这就给我们带来了――缓冲区溢出漏洞

当你往数组中写入一个字符串并继续写过剩下的数组，重写了那个数组的缓冲区溢出便发生了。

缓冲溢出安全问题在下列环境中能出现：
＊ 当直接往缓冲直接读入时
＊ 当从一个大的缓存拷贝入小的缓存时
＊ 当将其它进程的输入放入一个字符串缓存

记住，当输入是被信任的时候，它不是个安全