黑客攻防技术宝典Web实战篇第2版—第5章 避开客户端控件

5.1 通过客户端传送数据

5.1.1 隐藏表单字段

1、通过对表单中的数据隐藏，暗中更改数值，造成恶意攻击。

 

5.1.2 HTTP cookie

1、HTTPcookie是通过客户端传送数据的另一种常用机制，和隐藏表单类似，

上图是请求头，如果服务器端信任DiscountAgreed的值，那么客户就可以得到优惠折扣。

5.1.3 URL参数

1、应用程序常常使用预先定义的URL参数通过客户端传送数据，例如用户浏览商品目录时，应用程序会向他们提供如下URL超链接。

 

5.1.4 Referer消息头

1、浏览器大多数HTTP请求使用Referer消息头，利用这个消息头提出当前请求的页面的URL，或点击超链接，或提交表单，或该页面引用其他资源。可利用此消息头传送数据。

 

5.1.5 模糊数据

1、表单可能会对重要数据进行隐藏加密或者模糊化处理，例如上例中对商品的单价MD5加密。

 

 

5.1.6 ASP.NET ViewState

1、ASP.NET ViewState是一种通过客户端传送模糊数据的常用机制。

2、客户端和服务器还可以约定一种机制，使得客户端只传送相应数据的代号即可，服务器端就可以知道代表数据。例如，下拉列表，客户端只需传送相应索引，服务器端查询即可。

5.2 收集用户数据：HTML表单

5.2.1 长度限制

1、利用input标签中的maxLength属性限制用户输入的字符数。但攻击者也可以通过拦截工具更改数值，且删除maxLength属性。

 

5.2.2 基于脚本的确认

1、在用户注册或者登录时候，可以通过JS脚本语言对其输入合法性进行确认。

 

5.2.3 禁用的元素

1、通过disabled=true的属性，对一些值进行禁用，减少攻击。但禁用之后，抓包工具无法获取别禁用属性input值，后端PHP也获取不到。

 

5.3 收集用户数据：浏览器扩展

5.3.1 常见的浏览器扩展技术

1、常见的浏览器扩展技术包括：Java applet、Flash、Silverlight。

2、Java applet：在Java虚拟机JVM中运行，并采用由Java安全策略应用的沙盒。

3、Flash：Flash对象在Flash虚拟机中运行，也在主机沙盒上运行。

4、Silverlight：微软开发的与Flash类似的产品，主要用于启动各种桌面应用程序，允许Web应用程序在浏览器内的沙盒环境中提供精简的.NET体验。

5.3.2 攻击浏览器扩展的方法

1、可以拦截并修改浏览器扩展组件提出的请求及服务器的响应。

2、可以直接针对组件实施攻击，并尝试反编译它的字节码，以查看其源代码。或者使用调试器与组件进行动态交互。

5.3.3 拦截浏览器扩展的流量

1、先打开浏览器拦截代理服务器，然后使用浏览器扩展加载客户端组件，这时组件提出的请求经过拦截器，可以通过拦截器对其尽心修改及查询功能。

2、处理扩展组件遇到的障碍

①处理序列化数据：Java applet序列化、Flash序列化、Silverlight序列化。

②拦截服务器扩展流量时遇到的障碍

5.3.4 反编译浏览器扩展

1、对浏览器扩展组件实施攻击时，最彻底的方法就是反编译对象、对源码进行全面分析、修改源代码以及改编对象的行为，然后重新编译源代码。

2、步骤：

①下载字节码：一般从HTML源代码中指定的URL加载到单独的文件中。

②反编译字节码

③分析源代码

④字节码模糊化处理：由于攻击者可以反编译字节码以恢复其源代码，所以需要模糊化。（模糊化处理技巧：A、用没有意义的字符代表有意义的类表方法名等，B、一些模糊化处理工具用new等关键字代替项目名称。后面不再列举….）。

⑤Java applet：可用示例

大致意思：先下载applet字节码，类似一个class的文件。然后把它反编译，分析源码，之后修改其中的doCheck方法，此方法的作用是取消输入确认（使得输入任意值都有效）。然后根据前面拦截的obfpad属性值和任意数字传入doCheck方法中。最后增加一个main方法，把doCheck方法返回的值打印出来，在拦截器中更改这个值，就可以获得服务器的确认了，即成功修改了值，实现攻击。

5.3.5 附加调试器

1、由于代码量较多，需要借助调试工具，通过反编译获得源码运用附加调试器在适当位置设置断点，观察执行过程。

5.3.6 本地客户端组件

1、一些应用程序需要在用户的计算及执行基于浏览器VM沙盒内无法执行的操作，

这些操作需要使用本地代码组件。

5.4 安全处理客户端数据

5.4.1 通过客户端传送数据

1、许多应用程序之所以存在缺陷，是因为他们通过客户端以危险的方式传送重要数据，所以，要尽量避免通过客户端传送重要数据。

2、如果避免不了，应当对数据进行签名或加密处理来防止用户篡改。采取这种措施还可以避免：重传攻击、密码攻击。

5.4.2 确认客户端生成的数据

1、客户端无法安全确认由客户端生成并且向服务区传送的数据。确认客户端生成数据的唯一安全方法是在应用程序的服务器端实施保护。

5.4.3 日志与警报

1、应用程序将异常记录到日志，适当情况下发出警报。

5.5 小结

1、所有客户端组件以及其中发生的处理都不值得信任。

5.6 问题

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、应用程序可采取什么方法确保客户端执行了输入确认？

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