我的一位 Microsoft 同事的经验是：如果在用于比较的表达式中执行数学运算，那么就有可能上溢或下溢数据。如果将计算用于确定缓冲区大小，情况会更加糟糕，尤其是，如果一个或多个缓冲区大小计算元素已经被攻击者破坏。
任何语言中的数据库访问代码
作为一般规则，开发人员以高级语言（如 C#、scripting 语言以及类似的语言）编写数据库应用程序。相对而言，很少以 C 和 C++ 编写数据库代码，但是有些人使用各种 C/C++ 类库，例如 MFC 中的 CDatabase 类。
其中可以检测到两个问题。第一个是连接字符串，包括硬编码的密码或者使用管理员帐户的连接。可以检测到的第二个问题是 SQL 注入式攻击漏洞。
当我查看托管代码时，首要的事情就是搜索 System.Data 命名空间的所有代码，尤其是System.Data.SqlClient。当我看到这些时，就要格外谨慎了！接下来，我在代码中查找如“connect”这样的单词（它通常出现在连接字符串旁）。该连接字符串有两个需要关注的属性：连接 id（通常写为 uid）和密码（通常写为 pwd）。这些都是潜在的安全漏洞：
DRIVER={SQL Server};SERVER=hrserver;UID=sa;PWD=$esame
事实上，在上面的示例中有两个错误。第一，以系统管理员帐户 sa 进行连接；这违背了授予最低权限这一必要原则。代码永远不应该以系统管理员帐户连接到数据库，因为当该帐户被恶意用户使用时，它会给数据库带来灾难性后果。第二，密码是硬编码的。有两个理由可以说明这是错误的：第一个理由，密码会被发现；其次，如果更改密码，又该如何处理？（您将必须更新所有客户端。）
接下来的主题是 SQL 注入式攻击。SQL 注入的症结在于使用字符串连接来构建 SQL 语句。当扫描代码时，我将查看 SQL 语句的创建位置。一般而言，这涉及搜索诸如“update”、“select”、“insert”、“exec”以及任意我知道使用的表名或数据库名之类的单词。为了帮助解决问题，我使用下面的 ildasm.exe 来审查托管程序集：
ildasm /adv /metadata /out:file test.exe
然后，在生成的输出中分析“User Strings”部分。如果发现任何使用字符串连接的数据库查询，那么这就是一个潜在的安全缺陷，必须使用参数化查询来对其进行修复。
使用字符串连接构建存储过程也不能防止 SQL 注入。简而言之，字符串连接加上 SQL 语句会使情况变糟，而字符串连接加上 SQL 语句再加上系统管理员帐户就无异于一场灾难。
任意语言中的 Web 页代码
基于 Web 页的应用程序中最常见的错误是跨站点脚本 (XSS) 问题。尽管我也会查找其他问题（例如 SQL 注入和拙劣的加密），但是 XSS 错误相当普遍。核心 XSS 漏洞可能会在受害者的浏览器中显示不受信任的用户输入，所以我首先搜索所有将数据发送给用户的代码构造。例如，在 ASP 中查找 Response.Write 和 <%= %> 标记。接下来，分析被写入的数据从而查看它的来源。如果该数据来自 HTTP 实体（例如，窗体或查询字符串），并且没有检查有效性就将它发送到用户的浏览器，那么就会存在 XSS 错误。下面是一个非常简单，但又最为常见的 XSS 示例：
Hello,
<% Response.Write(Request.QueryString("Name")) %>
正如您看到的那样，“Name”参数被发送回用户，而没有首先检查它是否有效及格式规范。
任意一种语言中的机密与加密
一些开发人员喜欢在代码中存储机密数据（例如，密码和加密密钥），并创建自己的不可思议的密码算法。请不要这么做！
我首先寻找变量名和名称中包含“key”、“password”、“pwd”、“secret”、“cipher”以及“crypt”的函数。任何内容都需要加以分析。您可能经常获得貌似正确但实际错误的“密钥”，但是要注意其他几项，它们也许会产生嵌入式的机密数据或“不可思议的”加码系统。搜索密码算法的同时，我也寻找 XOR 运算符，因为它们经常用于加密。最糟糕的代码是使用嵌入式密钥来 XOR 数据流的代码！
Visual Basic 和 C++ 中的 ActiveX 控件
当我检查新的 ActiveX® 控件时，我始终想问一个问题：为什么不使用托管代码来编写？我问这个问题的原因在于，托管代码允许部分信任方案，而 ActiveX 却不是。
接下来，我分析控件的所有方法和属性（.IDL 文件是进行该操作最好的切入点），并且将自己设想为一个进行恶意攻击的人。我能利用这些方法或者属性来做一些什么样的危险事情呢？通常，很多方法以“VerbNoun”格式（动词 + 名词）进行命名，例如 ReadRegistry、WriteFile、GetUserName 和NukeKey，所以我寻找发音复杂的动词和属于敏感资源的名词（资源）。
例如，如果攻击者可以访问用户硬盘上的任何文件，并且可以将它发送到任意位置（例如，攻击者控制下的 Web 站点），那么 SendFile 方法就存在潜在的危险！任何访问用户计算机上的资源的操作都需要进一步的审查。
如果该控件被标记为可安全编写脚本 (SFS)，我会进行额外的检查工作，因为该控件可能会在 Web 浏览器中在不警告用户的情况下被调用。如果该控件在安装时执行 ATL IobjectSafetyImpl 接口或设置下面的“可安全编写脚本”或“可安全激活”实现类别，则您可以确定它是否为 SFS：
[HKEY_CLASSES_ROOT\CLSID\<GUID>\Implemented Categories\{7DD95801-9882-11CF-9FA9-00AA006C42C4}][HKEY_CLASSES_ROOT\CLSID\<GUID>\Implemented Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]
我之前曾提到，通过 SendFile 方法访问和发送用户文件不是好的做法。实际上，如果我能够访问 SendFile 方法，并可以基于该方法返回的错误代码来确定用户硬盘驱动器中是否存在文件，那么它就是一个隐私错误。
小结
这是我检查代码时通过的第一个非常高级别的审查。这些错误中的大多数都非常简单，有人可能会争辩说开发人员不应该犯这样的错误，但他们确实会犯这样的错误。然而，了解到有人会对您代码的进行安全性检查这一点，通常会使您将编写更为安全的代码放在第一位。
您可能还注意到，在包含某些缺陷类型的常见问题中，多数是由不受信任的输入造成的。当在检查代码时，您应该始终询问数据从何而来、是否值得信任。
|
