第二周任务汇报——星期三

今天做的是第五章的笔记，关于如何避开客户端组件。

因为客户端可以提交任意输入给Web应用，这给程序的核心造成威胁。我们可通过使用HTML表单功能、客户端脚本、浏览器扩展技术实现限制用户输入。

下面是一些客户端控件和避开方法：

1、通过客户端传递数据传递敏感数据并不安全，比如隐藏表单字段、HTTP cookie、URL参数、referer消息头，这些可应用拦截代理服务器解除，然后模糊数据、ASP.NET ViewState，可以先观察再解密分析。

2、收集用户数据——HTML表单，拦截表单之后即可修改字段长度、修改脚本、确定禁用元素及字段。

3、收集用户数据——浏览器扩展，技术主要是java applet、flash、silverlight，前两者在相应虚拟机中运行，后一种类似于flash用于启动桌面应用。攻击方法有两种，一种拦截并修改请求和响应，一种是直接攻击组件进行反编译看源代码或通过调试器动态交互（费时），可以将二者相结合。拦截流量，可发现服务器通信中的程序漏洞。反编译浏览器扩展——反编译字节码，通过下载字节码分析源代码。可对字节码模糊处理来预防，用无意义表达式替代或直接使用模糊处理工具处理项目名。本地客户端组件一般通过activex控件传送。

4、安全处理客户端数据，确认客户端生成的数据唯一安全方法是在服务器端进行保护。

5、日志和警报，可通过记录异常将其反映给管理员及时进行防御。

问题：

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

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

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

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

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