猫宁！！！

参考链接：http://www.ituring.com.cn/book/885

随书答案。

1. 通过客户端传送的数据如何阻止破坏性攻击？

可以使用保存在服务器上的密钥对数据进行加密或散列处理，就像选择性地使用
ASP.NET ViewState 一样。除非攻击者以某种方式获得密钥，否则他们将无法加
密任意数据，或计算出任意数据的有效散列。但是，攻击者仍然能够将一种情形
中的数据用于另一种情形——例如，可以用廉价商品的加密价格替代昂贵商品的
加密价格。为防止这种攻击，应用程序应在受保护的数据中包含足够的上下文信
息，以便于确认所采用的数据源自同一情形——例如，可以将产品代码和价格组
合在一个加密对象中。

2. 应用程序开发者希望阻止攻击者对登录功能发动蛮力攻击。由于攻击者可能
以多个用户名为目标，开发者决定将登录尝试失败次数保存在一个加密 cookie
中，阻止任何失败次数超过 5 次的请求。有什么办法能够避开这种防御？

这种防御很容易突破。攻击者不需要提交跟踪登录尝试失败次数的 cookie。他
们可以在浏览器中禁用cookie，或使用自动化脚本不通过相关cookie 提交请求。
其他防御措施包括使用 CAPTCHA 控件暂时阻止攻击者，或在登录失败次数达到五
次后阻止源 IP 地址，但是，这样做可能会对使用代理或 NAT 防火墙的多个用户
造成负面影响。

3. 某应用程序包含一个执行严格访问控件的管理页面。该页面上有一个连接到
另一台 Web 服务器的诊断功能链接。只有管理员才能够访问这些功能。不执行另
一种验证机制，下列哪一种（如果有）客户端机制可用于为诊断功能提供安全的
访问控件？要选择一个解决方案，是否还需要了解其他信息？

(1) 诊断功能能够检查 HTTP Referer 消息头，证实请求由主管理页面提交。
(2) 诊断功能能够验证收到的 cookie，证实其中包含访问主应用程序所需的有
效会话令牌。
(3) 主应用程序可在请求的一个隐藏字段中设置一个身份验证令牌。诊断功能能
够确认这一点，证实用户在主应用程序中有一个会话。

(1) 攻击者可以将 Referer 消息头设置为任意值，因此它不是执行任何访问控制
检查的安全方法。
(2) 这种方法仅在包含诊断功能的 Web 服务器为源 Web 服务器的父域或子域，且
对会话 cookie 进行了相应地审查时有效，否则 cookie 将不会被提交到诊断服务
器。将需要为诊断服务器实施后端机制，以确认随源服务器一起提交的令牌。
(3) 无论诊断服务器的域名是什么，这种方法都有效。只要身份验证令牌不可预
测，并且以安全方式传输（请参阅第 7 章），这种方法就是安全的。此外，还需
要实施用于验证令牌的后端机制。

4. 如果一个表单字段的属性为 disabled=true，那么它就不会和表单的其他内
容一起提交。如何才能改变这种情况呢？

有两种基本的方法：
(1) 可以拦截提交表单的请求，并添加被禁用的参数。
(2) 可以拦截包含表单的响应，并删除 disabled=true 属性。

5. 应用程序可采取什么方法确保客户端执行了输入确认？

应用程序没有办法可以确保客户端执行了输入确认。在客户端上执行的各种操作
完全由用户控制。