加密技术
大多数应用程序利用加密技术来保护数据，确保它的私密性并不被更改。围绕应用程序使用加密技术的主要威胁包括：
•
糟糕的密钥生成或者密钥管理机制
•
脆弱的或者自定义的加密技术
•
校验和欺骗
糟糕的密钥生成或者密钥管理机制
如果攻击者得到密钥或者可以推导出密钥，他们就可以解密加密的数据。如果不妥善管理密钥或者不以随机的方式产生密钥，攻击者就可以找出密钥。
应对糟糕的密钥生成和密钥管理机制的威胁的对策包括：
•
使用内置的加密例程，这种例程包含安全密钥管理。数据保护应用程序编程接口 (DPAPI) 就是一个加密服务示例，它由 Windows 2000 及其以后的操作系统提供，其中操作系统管理密钥。
•
使用强随机密钥生成函数，并将密钥存储在一个受限制的地方 — 例如，存储在用受限制的 ACL 保护的注册表密钥中 — 如果使用需要生成或管理密钥的加密机制。
•
用 DPAPI 加密密钥，增加安全性。
•
定期使密钥过期。
脆弱的或者自定义的加密技术
如果加密技术被破解或者很容易被强力破解，加密算法就不具有安全性。如果没有经过测试，自定义的算法特别容易受到攻击。相反，要使用公布的、著名的加密算法，它们都经受住了多年的苛刻攻击和审查。
针对脆弱的或者自定义的加密技术容易受到攻击的对策包括：
•
不开发自己自定义的算法。
•
使用由平台提供、经受考验的加密服务。
•
了解被破解的算法和用来破解算法的技术。
校验和欺骗
不要依靠通过散列来提供网络上发送的消息的数据完整性。散列，例如安全散列算法 (SHA1) 和消息摘要压缩算法 (MD5) 可能被拦截和更改。考虑下面的 base 64 编码并附加消息身份验证代码 (MAC) 的 UTF-8 消息：
Plaintext: Place 10 orders.
Hash: T0mUNdEQh13IO9oTcaP4FYDX6pU=
如果通过监视网络，攻击者拦截了消息，攻击者就可以修改该消息并重新计算散列值（猜测您使用的算法）。例如，该消息可能被更改为：
Plaintext: Place 100 orders.
Hash: oEDuJpv/ZtIU7BXDDNv17EAHeAU=
当接收者处理该消息时，它们通过散列算法运行明文 (“Place 100 orders”)，然后重新计算散列值，他们计算的散列值将会等于攻击者计算的散列值。
为了对抗这种攻击，可以使用 MAC 或者 HMAC。用消息身份验证代码三倍数据加密标准 (MACTripleDES) 算法计算 MAC，而用 HMACSHA1 计算 HMAC。两种算法都使用一个密钥来产生校验和。对于这些算法，攻击者需要知道产生校验和的密钥，接收者将会正确计算校验和。
参数操作
操作参数攻击是一种依靠更改在客户端和 Web 应用程序之间发送的参数数据的攻击。这包括查询字符串、窗体字段、cookie 和 HTTP 标头。主要的操作参数威胁包括：
•
操作查询字符串
•
操作窗体字段
•
操作 cookie
•
操作 HTTP 标头
操作查询字符串
用户很容易就可以操作由 HTTP GET 传递的从客户端到服务器的查询字符串值，因为它们显示在浏览器的 URL 地址栏中。如果您的应用程序依靠查询字符串值来进行安全决策，或者如果该值代表的是诸如资金数量的敏感数据，那么该应用程序就很容易受到攻击。
应对操作查询字符串威胁的对策包括：
•
避免使用包含敏感数据或者影响服务器安全逻辑的查询字符串参数。相反，要使用会话标识符来标识客户端，并将敏感项存储在服务器上的会话存储区中。
•
选用 HTTP POST 来代替 GET 提交窗体。
•
加密查询字符串参数。
操作窗体字段
HTML 窗体的字段值是以明文形式利用 HTTP POST 协议发送到服务器的。这可能包括可见的和隐藏的窗体字段。任何类型的窗体字段都可以轻松地被更改，并可以绕过客户端的验证例程。结果，服务器上依靠窗体字段输入值来进行安全决策的应用程序很容易受到攻击。
对抗操作窗体字段的威胁要使用会话标识符来引用服务器状态存储区中维护的状态，而不是使用隐藏的窗体字段。
操作 cookie
Cookie 很容易被客户端更改。这对于持久 cookie 和驻留内存的 cookie 都是如此。有许多工具可以帮助攻击者更改驻留在内存的 cookie 的内容。操作 cookie 攻击是指更改 cookie,通常是为了访问未授权的 Web 站点。
虽然 SSL 可以保护网络上的 cookie，但它不能阻止在客户端计算机上更改 cookie。为了对抗操作 cookie 威胁，使用加密或者 HMAC cookie。
操作 HTTP 标头
HTTP 标头在客户端和服务器之间传递信息。客户端构造请求标头，而服务器构造响应标头。如果您的应用程序依靠请求标头来进行决策，您的应用程序就很容易受到攻击。
不要根据 HTTP 标头进行安全决策。例如，不要信任 HTTP Referer 来确定客户来自何处，因为它很容易被篡改。
异常管理
允许传播给客户端的异常可以泄漏内部实现的详细资料，它对最终用户没有意义，但对攻击者却非常有用。不使用异常处理或者异常处理实现得非常糟糕的应用程序，也会遭受拒绝服务攻击。主要的异常处理威胁包括：
•
攻击者发现实现的详细资料
•
拒绝服务
攻击者发现实现的详细资料
.NET Framework 的一个重要特点就是提供丰富的异常详细资料，这些资料对于开发人员具有极大价值。如果这同样的信息落到攻击者的手中，它将会大大帮助攻击者利用潜在的缺陷以及规划将来的攻击。可以被返回的信息类型包括平台版本、服务器名称、SQL 命令字符串以及数据库连接字符串。
帮助防止内部实现详细资料泄漏给客户端的对策包括：
•
在整个应用程序代码库中使用异常处理。
•
处理和记录允许传播到应用程序边界的异常。
•
返回给客户端一般的无害错误消息。
拒绝服务
攻击者通常通过故意传递格式错误的输入来探测 Web 应用程序。在他们的脑海中经常有两个目标。第一个是引起异常的发生，以泄漏有用的信息。第二个是破解 Web 应用程序进程。如果异常没有被正确地捕捉到和处理，就会发生这种情况。
帮助防止应用程序级拒绝服务的对策包括：
•
彻底验证服务器的所有输入数据。
•
在整个应用程序代码库中使用异常处理。
审核和日志记录
应当使用审核和日志记录来帮助发现可疑的活动，例如足迹或者真正攻击之前的可能破解密码企图。它还有助于处理否认威胁。如果多个服务器上的一系列同步日志条目表明用户执行过某项交易，那么用户就很难否认执行过这项操作。
与审核和日志记录有关的主要威胁包括：
•
用户否认执行过某项操作
•
攻击者攻击某应用程序而没有留下踪迹
•
攻击者掩饰他们的踪迹
用户否认执行过某项操作
否认问题就是用户否认他或她执行过某个操作或者发起过某项交易。需要适当的防护机制来确保可以追踪和记录所有的用户活动。
帮助防止否认威胁的对策包括：
•
审核和记录 Web 服务器与数据库服务器以及应用程序服务器（如果使用的话）上的活动。
•
记录主要事件，如交易、登录和注销事件。
•
不要使用共享帐户，因为这样不能确定最初的源。
攻击者攻击某应用程序而没有留下踪迹
需要进行系统和应用程序级审核，以确保未漏掉可疑的活动。
发现可疑活动的对策包括：
•
记录重要的应用程序级操作。
•
利用平台级审核来审核登录和注销事件、访问文件系统以及失败的对象访问尝试。
•
备份日志文件，并定期分析可疑活动的征兆。
攻击者掩饰他们的踪迹
要很好地保护好您的日志文件，以确保攻击者不能掩饰他们的踪迹。
帮助防止攻击者掩饰他们踪迹的对策包括：
•
使用受限制的 ACL 来保护日志文件。
•
将系统日志文件从默认的位置重新定位。
小结
了解了攻击者使用的典型方法和它们的目标，您在采用对策时就可以更加有效。这还有助于在考虑和识别威胁时使用基于目标的方法，并有助于使用 STRIDE 模型来根据攻击者的目标对威胁进行分类，例如，盗用身份、篡改数据、拒绝服务、提高特权等等。这就使您可以将精力更多地集中在用来降低风险的一般方法上，而不是将精力集中在识别每一种可能的攻击上，那可能是一项耗时但很可能无收效的做法。
本单元已经为您介绍了主要的威胁，它们可能会危及您的网络、主机基础结构和应用程序的安全。这些威胁还有适当的对策知识为威胁建模过程提供基本的信息。它使您能够识别特殊场合下特有的威胁，并且能够根据它们对系统造成的风险程度区分优先次序。这种识别和区分威胁优先次序的结构化过程被称为威胁建模。有关更多信息，请参阅“威胁建模。”
