避开客户端控件

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) 无论诊断服务器的域名是什么，这种方法都有效。只要身份验证令牌不可预测，并且以安全方式传输，这种方法就是安全的。
此外，还需要实施用于验证令牌的后端机制。

4.如果一个表单字段的属性为disabled=true，那么它就不会和表单的其他内容一起提交。如何才能改变这种情况呢？
有两种基本的方法：
(1) 可以拦截提交表单的请求，并添加被禁用的参数。
(2) 可以拦截包含表单的响应，并删除disabled=true属性。

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