缓冲区溢出
缓冲区溢出缺陷可以导致拒绝服务攻击或者代码注入。拒绝服务攻击可以引起进程崩溃；代码注入可以更改程序的执行地址，从而运行攻击者的注入代码。下面的代码片段说明了一种常见的缓冲区溢出缺陷的示例。
void SomeFunction( char *pszInput )
{
char szBuffer[10];
// Input is copied straight into the buffer when no type checking is performed
strcpy(szBuffer, pszInput);
. . .
}
托管 .NET 代码不受此问题的影响，因为当访问数组时会自动检查数组边界。这样就使得缓冲区溢出攻击的威胁对于托管代码就不算什么问题。但是仍然要关注它，特别是在托管代码调用非托管 API 或者 COM 对象的场合。
帮助防止缓冲区溢出的对策包括：
•
执行完全的输入验证。这是防护缓冲区溢出的首要对策。尽管您的应用程序中可能存在一个错误，它允许期望的输入超出容器的边界，但意外的输入仍是引起缺陷的主要原因。通过验证输入的类型、长度、格式和范围，对输入进行约束。
•
如果有可能，限制您的应用程序使用非托管代码，并彻底检查非托管 API，确保输入得到正确验证。
•
检查调用非托管 API 的托管代码，确保只有适当的数值才能作为参数传递给非托管 API。
•
利用 /GS 标志来编译用 Microsoft Visual C++_ 开发系统开发的代码。/GS 标志能使编译器将安全检查插入到被编译的代码中。这不是一种预防失败的解决方案，或者要替代专用的验证代码；但是，它确实可以保护您的代码不受众所周知的缓冲区溢出的攻击。有关更多信息，请参阅 .NET Framework 产品文档：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/vclrfGSBufferSecurity.asp 和 Microsoft 知识库文章 325483“支持 WebCast：编译器安全检查：/GS 编译器开关”，网址为： http://support.microsoft.com/default.aspx?scid=325483。
通过缓冲区溢出注入代码的示例
攻击者可以利用缓冲区溢出缺陷来注入代码。利用这种攻击，恶意的用户通过提供一个精心构建的输入值，以改写程序的堆栈并修改函数的返回地址，从而利用某个进程中未检查的缓冲区。这就使执行跳到了攻击者的注入代码处。
通常，攻击者的代码最终在进程的安全上下文处运行。这就强调了使用最低特权进程帐户的重要性。如果当前的线程正在模拟，攻击者代码最终就会在该线程的模拟标记定义的安全上下文处运行。通常，攻击者做的第一件事就是调用 RevertToSelf API，以恢复攻击者希望具有更高特权的进程级安全上下文。
确信您已验证了输入的类型和长度，特别是在调用非托管代码之前，因为非托管代码特别易受缓冲区溢出的影响。
跨站点脚本编写
当浏览器和某个可信的 Web 站点连接时，XXS 攻击可以引起任意代码在用户的浏览器中运行。攻击的目标为应用程序的用户而非应用程序本身，但是它以您的应用程序作为攻击的工具。
由于是从一个可信的站点用浏览器下载了脚本代码，浏览器无从知道这些代码是非法的。Internet Explorer 的安全区不能提供任何防护。由于攻击者的代码可以访问与可信站点相关的 cookie，这些 cookie 存储在用户的本地计算机上。一般情况下，用户的身份验证 cookie 就成为了攻击的目标。
跨站点脚本编写示例
为发起攻击，攻击者必须说服用户单击某个精心打造的超级链接，例如，在发送给用户的电子邮件中嵌入一个链接，或者将恶意链接添加到某新闻组记录中。应用程序中有缺陷页的链接点将未验证的输入以 HTML 输出流的形式返回到浏览器中。例如，考虑下面的两个链接。
这是一个合法的链接：
www.yourwebapplication.com/logon.aspx?username=bob
这是一个恶意链接：
www.yourwebapplication.com/logon.aspx?username=<script>alert
('hacker code')</script>
如果 Web 应用程序要获取查询字符串，但未能恰当地验证它，然后就将其返回给浏览器，脚本代码就在浏览器中执行。前面的例子会弹出一条无害的消息。利用适当的脚本，攻击者就可以轻易抽取用户的身份验证 cookie，并将它寄回他的站点，随后就以经身份验证用户的身份对目标 Web 站点产生一个请求。
防止 XSS 的对策包括：
•
执行完全的输入验证。您的应用程序必须确保来自查询字符串、窗体字段和 cookie 的输入对于应用程序来说是合法的。将所有的用户输入都认为可能是恶意的，筛选或者清理下游代码的上下文。验证所有的输入是否为已知的有效值，然后拒绝其他所有的输入。用正则表达式验证通过 HTML 窗体字段、cookie 和查询字符串而接收到的输入数据。
•
利用 HTMLEncode 和 URLEncode 函数对包括用户输入在内的任何输出进行编码。这就将可执行脚本转换成无害的 HTML。
SQL 注入
SQL 注入式攻击利用输入验证中的缺陷来运行数据库中的任意命令。当应用程序使用输入来构造访问数据库的动态 SQL 语句时就会发生这种攻击。如果您的代码使用存储过程，传递给该过程的字符串中包含有未筛选的用户输入时，也会发生这种攻击。利用 SQL 注入攻击，攻击者可以执行数据库中的任意命令。如果应用程序使用一个越权帐户来与数据库连接，问题会更严重。在这种情况下，除了能够检索、操作和破坏数据外，利用数据库服务器来运行操作系统命令是可能的，并有可能危及其他服务器的安全。
SQL 注入的示例
当您将未验证的用户输入合并到数据库查询中时，您的应用程序可能受到 SQL 注入攻击。特别容易受到攻击的是利用未筛选用户输入构造动态 SQL 语句的代码。考虑下面的代码：
SqlDataAdapter myCommand = new SqlDataAdapter(
"SELECT * FROM Users
WHERE UserName ='" + txtuid.Text + "'", conn);
通过在单引号字符后跟一个分号字符来开始一条新命令来终止计划中的 SQL 语句，然后执行他们选择的命令，攻击者可以进行 SQL 注入攻击。考虑输入到 txtuid 字段中的下列字符串。
'; DROP TABLE Customers–
这会导致将下面的语句提交给数据库执行。
SELECT * FROM Users WHERE UserName=''; DROP TABLE Customers --'
这将会删除 Customers 表，假设应用程序的登录对数据库有足够的权限（这是使用最低特权登录数据库的另一原因）。双破折号 (--) 表示 SQL 注释，并用来对程序员添加的任何其他字符如结尾引号进行注释。
注 分号实际上不是必需的。SQL Server 将执行由空格分开的两条命令。
可以运用一些其他更微妙的技巧。将下列输入提供给 txtuid 字段：
' OR 1=1–
构建下列命令：
SELECT * FROM Users WHERE UserName='' OR 1=1–
由于 1=1 总为 true，攻击者要检索 Users 表中的每行数据。
防止 SQL 注入的对策包括：
•
执行完全的输入验证。应用程序在将请求发送给数据库之前要对输入进行验证。
•
利用参数化存储过程来访问数据库，确保不会将输入字符串看作是可执行语句。如果不能使用存储过程，在构建 SQL 命令时要利用 SQL 参数。
•
利用最低特权帐户来与数据库连接。
||||||标准化
将不同形式的输入转化成相同的标准名称（规范名称），这被称为标准化。如果代码是根据传递给程序的资源名称（它作为输入）来进行安全决策，这样的代码就特别容易受到标准化问题的影响。文件、路径和 URL 都是容易受标准化影响的资源类型，因为每种情况都有许多表示相同名称的不同方法。文件名称也有这样的问题。例如，可以将一个文件表示为：
c:\temp\somefile.dat
somefile.dat
c:\temp\subdir\..\somefile.dat
c:\ temp\ somefile.dat
..\somefile.dat
理想情况下，代码不予接受文件名输入。如果确实要接受，应当在进行安全决策前将该名称转换成规范形式的名称，例如是否同意或者拒绝访问指定的文件。
针对标准化问题的对策包括：
•
尽可能避免将文件名称作为输入，而是使用最终用户不能更改的绝对文件路径。
•
确信文件名称格式正确（如果必须接受将文件名称作为输入的话），并且要在应用程序上下文内对其进行验证。例如，检查它们是否在您的应用程序的目录层次结构内。
•
确保字符编码设置正确，以限制输入的表示方法。检查您的应用程序的 Web.config 是否已经在 <globalization> 元素中设置了 requestEncoding 与 responseEncoding 属性。
身份验证
根据您的需求，有几种身份验证机制供选择。如果选择和实现不正确，身份验证机制就会暴露出缺陷，攻击者利用这些缺陷可以访问您的系统。利用身份验证缺陷造成的主要威胁包括：
•
网络窃听
•
强力攻击
•
词典攻击
•
Cookie 重放攻击
•
盗窃凭据
网络窃听
如果将身份验证凭据以明文形式从客户端传递到服务器，在同一网络的某台主机上配备有基本网络监控软件的攻击者可以捕获传递的信息并获取用户的名称和密码。
防止网络窃听的对策包括：
•
使用不在网络上传输密码的身份验证机制，例如 Kerberos 协议或者 Windows 身份验证机制。
•
确信密码已加密（如果必须在网络上传输密码的话），或者使用加密的通信通道，例如 SSL。
强力攻击
强力攻击依靠计算能力来破解散列的密码或者破解其他用散列和加密保护的秘密。为降低风险，可以使用强密码。
词典攻击
利用这种攻击可以获得密码。大多数密码系统不存储明文密码或者加密密码。它们避免使用加密密码是因为，危及安全的密钥可以损害数据存储区中的所有密码。丢失了密钥意味着所有的密码都无效。
大多数用户存储含有密码散列值（或者摘要）的实现。根据用户提供的密码值重新计算散列值，并将它与存储在数据库中的散列值进行比较，以此来验证用户的身份。如果攻击者设法获得了散列密码列表，就能够使用强力攻击来破解密码散列值。
利用词典攻击，攻击者利用一个程序循环访问字典中的所有的单词（或多种语言的多个字典）并计算每个单词的散列值。将获得的散列值与数据存储区中的值进行比较。脆弱密码，例如“Yankees”（一个喜爱的团队）或者“Mustang”（一辆喜欢的轿车），将会很快被破解。较强的密码，例如“?You'LlNevaFiNdMeyePasSWerd!”，被破解的可能性要小一些。
注 一旦攻击者获得了散列密码列表，可以离线进行词典攻击，并且不需要与应用程序进行交互。
防止词典攻击的对策包括：
•
使用复杂、非寻常的单词作为强密码，并且是包含大小写、数字和特殊字符的混合体。
•
在用户的存储器中存储非可逆的散列密码。同时散列密码要组合一个有力的数值（一个加密的强随机数）。
有关存储添加有力数值散列密码的更多信息，请参阅 “构建安全的数据访问。”
Cookie 重放攻击
•
利用这类攻击，攻击者可以利用监控软件捕获用户的身份验证 cookie，并且将它重放给应用程序以便能够以假身份进行访问。
•
防止 cookie 重放的对策包括：
•
当传输身份验证 cookie 时，使用 SSL 提供的加密通信通道。
•
利用一个 cookie 超时时间值，强迫在某个相对短的时间间隔后进行身份验证。虽然这种方法不能防止进行重放攻击，但它减小了攻击者重放请求的时间间隔，这期间无需强迫进行再次身份验证，因为会话已经超时。
盗窃凭据
如果应用程序在实现自己的用户存储时包含有用户的帐户名称和密码，将它的安全性与由平台提供的凭据存储（例如，Microsoft Active Directory 的目录服务或者安全帐户管理器 (SAM) 的用户存储）的安全性进行比较。浏览器的历史记录和缓存也存储有将来使用的用户登录信息。如果是除了登录者的其他用户访问该终端，并且点击同一个网页，就可以使用已经保存的登录。
帮助防止盗窃凭据的对策包括：
•
使用和执行强密码。
•
以添加有力的数值的散列值存储密码检验值。
•
在固定次数重试后对最终用户帐户执行帐户锁定。
•
为了杜绝浏览器缓存允许登录访问的可能性，可以创建这样的功能，该功能既可以允许用户选择不保存凭据，又可以将该功能强制成为默认的策略。
授权
根据用户的身份和角色成员身份，对特殊的资源或者服务进行授权，要么允许访问，要么拒绝访问。利用授权缺陷的主要威胁包括：
•
提高特权
•
机密数据泄漏
•
篡改数据
•
引诱攻击
提高特权
在设计授权模型时，必须要考虑攻击者试图提升特权，以成为一个超级帐户如本地管理员组成员或者本地系统帐户的威胁。这样做，攻击者就完全能够控制应用程序和本地计算机。例如，利用传统的 ASP 编程，从一个组件调用 RevertToSelf API 可能会造成正在执行的线程以本地系统帐户身份运行，而该本地系统帐户拥有本地计算机的超级特权。
可以用来防止提升特权的主要对策就是使用最低特权进程、服务和用户帐户。
机密数据泄漏
如果未授权用户可以查看敏感数据，就会发生机密数据泄漏的问题。机密数据包括应用程序专用的数据，例如信用卡号、雇员详细资料、财务记录等，还包括应用程序配置数据，例如服务帐户凭据以及数据库连接字符串。为了防止泄漏机密数据，应在网络上传输时对其进行保护，还应在持久性存储区中进行保护（例如数据库和配置文件）。只有经过身份验证和授权的用户才能访问他们专用的数据。应当限制只有管理员才能访问系统级配置数据。
防止泄漏机密数据的对策包括：
•
在允许访问可能暴露敏感数据的操作之前，进行角色检查。
•
利用强 ACL 来保护 Windows 资源。
•
利用标准的加密技术将敏感数据存储到配置文件和数据库中。
篡改数据
篡改数据是指未经授权就更改数据。
防止篡改数据的对策包括：
•
利用强访问控制以保护在持久性存储区中的数据，确保只有授权的用户才可以访问和更改数据。
•
使用基于角色的安全策略来区分用户，谁可以查看数据，谁可以更改数据。
引诱攻击
当几乎没有特权的实体可以让具有更多特权的实体代表它执行操作时，就会发生引诱攻击。
为了对抗这种威胁，必须通过适当的授权来限制对可信代码的访问。只要访问安全资源或者执行特权操作，都要授权调用代码。.NET Framework 的代码访问安全机制在这方面会有所帮助。
||||||配置管理
许多应用程序支持配置管理界面和功能，以允许操作者和管理员更改配置参数，更新 Web 站点的内容，以及进行日常的维护。主要的配置管理威胁包括：
•
未经授权访问管理界面
•
未经授权访问配置存储区
•
检索明文配置秘密
•
缺乏个人可记帐性
•
越权进程和服务帐户
未经授权访问管理界面
经常通过另外的 Web 页或者单独的 Web 应用程序提供管理界面，它允许管理员、操作者和内容开发人员来管理站点内容和配置。这些管理界面只应当由有限的和授权的用户使用。恶意的用户能够访问配置管理功能可能会破坏 Web 站点、访问下游系统和数据库，或者通过破坏配置数据而使应用程序出现故障。
防止未授权访问管理界面的对策包括：
•
将管理界面的数量减到最少。
•
使用强身份验证，例如，使用证书。
•
使用带有多个网关守卫的强授权。
•
考虑只支持本地管理。如果完全需要远程管理，那么利用加密通道，例如，VPN 技术或者 SSL，这是由于在管理界面上传递的数据的敏感性所导致的。为了进一步降低风险，还要考虑使用 IPSec 策略来限制对 Internet 网络上的计算机进行远程管理。
未经授权访问配置存储区
由于配置存储区中维护的数据的敏感性，应当确保存储区得到了足够的保护。
保护配置存储区的对策包括：
•
配置基于文本的配置文件（例如 Machine.config 与 Web.config）中的受限的 ACL。
•
保持自定义的配置存储区位于 Web 空间之外。这样就消除了下载 Web 服务器配置以利用其缺陷的可能性。
检索明文配置秘密
必须要限制访问配置存储区。作为深层次机制中的一种重要防护措施，应当对诸如密码和连接字符串的敏感数据进行加密。这有助于防止外部攻击者获取敏感配置数据。这还可以防止不道德的管理员和内部员工获得敏感详细资料，例如数据库连接字符串以及帐户凭据，这些可能会允许他们访问其他系统。
缺乏个人可记帐性
缺乏对更改配置信息的审核和日志记录就会威胁识别以下情况的能力：什么时候进行的更改以及谁做的更改。当由诚实操作者的错误或者恶意的更改导致出现中断更改，从而允许特权访问时，首先要采取行动纠正这些修改。然后采取预防措施，防止以同样的方式引入中断更改。要牢记，共享帐户可以躲避审核和日志记录，这对管理帐户与用户/应用程序/服务帐户都适用。不能共享管理帐户。分配用户/应用程序/服务帐户的级别时必须允许使用该帐户标识单一的访问源，并考虑对赋予该帐户的特权的破坏。
越权应用程序和服务帐户
如果允许应用程序和服务帐户更改系统上的配置信息，它们可能会受攻击者的操纵而这样做。通过采取使用最低特权服务和应用程序帐户的策略，可以降低这种威胁带来的风险。要慎重授予帐户更改它们自己配置信息的能力，除非设计有明确的要求。
敏感数据
敏感数据遭受各种威胁。试图查看或者更改敏感数据的攻击目标是持久性存储区和网络。对敏感数据的主要威胁包括：
•
访问存储区的敏感数据
•
网络窃听
•
篡改数据
访问存储区的敏感数据
必须要保护存储区的敏感数据，以防止恶意的或者其他的用户访问和读取这些数据。
保护存储区的敏感数据的对策包括：
•
对包含敏感数据的持久性数据存储区使用受限 ACL。
•
存储加密数据。
•
使用基于身份和角色的授权，确保只有具有适当授权级别的用户才允许访问敏感数据。用基于角色的安全机制来区分用户，谁可以查看数据，谁可以更改数据。
网络窃听
Web 应用程序的 HTTP 数据以明文的形式在网络上传输，并遭受网络窃听攻击，攻击者利用网络监视软件捕获并有可能更改敏感数据。
防止网络窃听并提供私密性的对策包括：
•
加密数据。
•
使用加密通信通道，例如，SSL。
篡改数据
篡改数据指的是未经授权就更改数据，通常发生在数据在网络上传输时。
防止篡改数据的一条对策就是用防篡改协议，如散列消息身份验证代码 (HMAC) 来保护在网络上传输的敏感数据。
HMAC 以下面的方式提供消息完整性：
1.
发送方利用共享的密钥创建基于消息有效负载的散列值。
2.
发送方将散列值和消息有效负载一道传输。
3.
接收方利用共享的密钥重新计算基于接收到的消息有效负载的散列值。然后，接收方将新散列值与传输的散列值进行比较。如果它们一样，消息就没有被篡改。
会话管理
Web 应用程序的会话管理是应用程序层的一项职责。会话的安全性对于应用程序的整体安全性非常重要。
主要的会话管理威胁包括：
•
会话劫持
•
会话重放
•
中间人
会话劫持
当攻击者利用网络监视软件捕获用来表示用户与应用程序进行会话的身份验证标记（通常是一个 cookie）时，就会发生会话劫持攻击。利用捕获的 cookie，攻击者可以欺骗用户会话，访问应用程序。攻击者具有和合法用户同级的特权。
防止会话劫持的对策包括：
•
利用 SSL 创建一条安全的通信通道，并只在 HTTPS 连接上传输身份验证 cookie。
•
实现注销功能，允许用户在启动另一个会话时结束强制身份验证会话。
•
如果不使用 SSL，确保要限制会话 cookie 的有效期。虽然这不能防止会话劫持，但是它减小了攻击者可利用的时间。
会话重放
当用户的会话标记被攻击者中途截取和提交以绕过身份验证机制时，就会发生会话重放。例如，如果会话标记为 cookie 或者 URL 中的明文，攻击者可以探查到它。然后，攻击者利用被劫持的会话标记来发出请求。
帮助解决会话重放威胁的对策包括：
•
当执行关键功能时，重新进行身份验证。例如，在银行应用中传输金融信息之前，让用户再次提供帐户密码。
•
使会话经适当时间后过期，包括所有的 cookie 和会话标记。
•
创建“不要提醒我”选项，不允许客户端存储会话数据。
中间人攻击
当攻击者拦截在您和您期望的接收者之间发送的消息时，就会发生中间人攻击。然后，攻击者更改您的消息并将它发送给原来的接收者。接收者接收到消息而且认为是您发送的，并对之采取行动。当接收者给您发回消息，攻击者拦截它、更改它，再发送给您。您和您的接收者永远不会知道您们已经被攻击。
涉及客户端与服务器间的通信的任何网络请求，包括 Web 请求、分布式组件对象模型 (DCOM) 请求以及调用远程组件和 Web 服务，这些都会遭到中间人攻击。
防止中间人攻击的对策包括：
•
使用加密技术。如果在传输数据之前对数据加密，攻击者虽然还可以拦截它，但却不能阅读或更改它。如果攻击者不能阅读它，他或她就不知道更改哪一部分。如果攻击者盲目地更改加密消息，那么原来的接收者就不能成功地进行解密，这样就知道数据已经被篡改。
•
使用散列消息身份验证代码 (HMAC)。如果攻击者更改这种消息，接收者重新计算 HMAC 就会失败，然后就会拒绝这种无效数据。
