目录
2.5、Referer消息头
简介：
浏览器在大多数HTTP请求中使用Referer消息头。浏览器使用这个消息头指示提出当前请求的页面的URL，或者是因为用户单击了一个超链接或提交了一个表单， 或者是因为该页面引用了其他资源。
可以利用消息头通过客户端传送数据，应用程序处理的URL受其控制，Referer消息头可用于判断某个特殊的请求由哪个URL生成
（Referer是可选的，大多数浏览器执行它，但不由它控制）
示例：
重置密码：
按顺序执行几步---->重置密码
应用程序可以使用Referer消息头证实这个请求是在正确的阶段(Admin.ashx)提出的，然后才允许用户访问请求的功能
用户控制着每一个请求，包括HTTP消息头． 他可以直接进入CreateUser.ashx，并使用拦截代理服务器将Referer消息头的值修改为应用程序需要的值，通过检测
2.6、模糊数据
简介：
通过客户端传送的数据被加密或进行了某种形式的模糊处理， 变得很难直接看懂
如产品价格并不是我们能编辑的，也可能并不保存在隐藏字段中， 而是以特定的处理后的隐含值的形式传递
示例：
value="NJIBNj760213254362413150265C989229">
可以据此推断， 提交表单后， 服务器端应用程序将检查模糊字符串的完整性， 或对其进行解密或去模糊处理， 然后处理它的明文值。这种深层次处理可能易于造成各种漏洞， 要探查或利用这种漏洞，首先必须对有效载荷进行适当的处理
客户端篡改的潜在目标：
会话处理机制通常通过客户端传递模糊数据，在HTTP cookie中传送的会话今牌、在隐藏字段中传送的反CSRF今牌， 以及用于访问应用程序资源的一次性URL令牌
模糊数据处理：
1、破解：模糊字符串的明文值， 可以尝试破译模糊处理所使用的模糊算法
2、试探：应用程序的其他地方包含已知功能的地方， 利用它们返回由控制一段明文生成的模糊字符串。可以向目标功能直接提交任意一个有效载荷， 获得所需要的字符串
3、狸猫换太子：即使模糊字符串完全无法理解，可以在其他情况下替换传送它的值，实现价格变低等效果
eg：表单的pricing_token参数中可能包含一个加密的产品价格。尽管攻击者无法对选择的任意价格以相同的算法进行加密， 但是， 他们可以把另一个更加便宜的产品的加密价格复制过来， 放在这里提交
4、提交畸形字符串一一如包含超长值、不同字符集等错误的字符串，尝试攻击负责对模糊数据进行解密或去模糊处理的服务器端逻辑。
2.7、ASP.NET ViewState
简介：
ASP.NET ViewState是一种通过客户瑞传送模糊数据的常用机制。它是一个由所有ASP.NET Web应用程序默认创建的隐藏字段， 其中包含关于当前页面状态的序列化信息。ASP.NET平台使用ViewState提高服务器的性能，服务器通过它在连续提交请求的过程中保存用户界面中的元素， 而不需要在服务器端维护所有相关的状态信息
1、服务器会根据用户提交的参数填充下拉列表
2、用户提交请求时，浏览器并不向服务器提交列表的内容
3、而是提交隐藏的ViewState字段，其中包含该列表的序列化格式
4、服务器对ViewState进行去序列化处理， 并重新建立相同的列表， 再将其返回给用户
除这种核心功能外， 还可使用Viewscate保存任意信息
示例：
应用程序可以不将产品价格保存在隐藏表单字段中， 而是将其保存在ViewState中
string price = getPrice(prodno);
ViewState.Add("price",pmce1);
返回用户表单（部分）
value="/BHBflhGYLnjtfJKGUUKLBYlfguLYGhnybk"/>
ViewState=%VGICFGBycryienwvdl%bak%bctwjkb%Kbceal%
quantity=11、请求中并不包含产品价格，只有订购的数量和模糊处理后的ViewState参数
2、随意更改这个参数会导致应用程序显示错误消息，并终止购买交易。
3、分析出ViewState编码方法，再进行修改
注：在对一个可能为base64编码的字符串进行解码时，常见的错误错误
即从字符串的错误位置开始解码，Base64编码的特点，如果从错误的位置开始解码，解码后的字符串中会出现乱码。Basc64采用基于数据块的格式， 每4字节的编码数据解码后会变为3个字节。因此，如果解码后的base64字符串并无意义
尝试从编码字符串中的4个相邻的偏移值位置开始解码（偏移1-4个）
分析：
（默认）ASP.NET平台通过在ViewState中加入一个密钥散列（称为MAC保护）来防止篡改。但一些应用程序禁用了这项默认启用的保护，若禁用则可以修改ViewState的值， 以确定其是否会对应用程序的服务器端处理产生影响。
Bp提供一个检测ViewState是否受MAC保护的ViewState解析器，如果ViewState未受到保护， 则攻击人员可以使用ViewState树下的十六进制编码器在bp中编辑ViewState的内容。在向服务器或客户端发送消息时bp中将发送经过更新的ViewState（如更改价格）
1、分析：攻击ASP.NET应用程序，确定是否对ViewState启用了MAC保护。如果ViewState结构末尾存在一个20字节的散列，即表示应用程序启用了MAC保护。可以使用bp suite中的解析器确定上述散列是否存在
2、寻找：不同应用程序页面中的Viewscace参数，了解应用程序是否使用ViewState通过客户端传送任何敏感数据
3、试错：尝试修改ViewState中某个特殊参数的值， 但不破坏它的结构，看看是否会导致错误消息
4、参数：如果修改Viewscace而不会造成错误， 则应该分析ViewState中每个参数的功能，以及应用程序是否使用这些参数保存任何定制数据。尝试用专门设计的值代替每一个参数，探查常见的漏洞
5、寻找：不同页面可能启用或禁用MAC保护， 因此有必要测试应用程序的每一个重要页面，了解其中是否存在Viewscace攻击漏洞。如果在启用被动扫描的情况下使用bp自动报告任何使用ViewState但未启用MAC保护的页面