抓包工具Fiddler篡改请求响应报文

简介

客户端和服务器通信发送报文进行通讯，但这些报文可以被截获修改进行一些攻击。对于web端和app都可以查看源码判断解密算法，并且大部分情况下都可以伪造响应报文，尤其是未加密和签名的报文。对于RSA加密报文可以利用之前获取成功报文，直接返回给特殊功能进行绕过攻击。例如截获新增用户成功响应的报文【可以是加密后的报文】，在验证短信界面直接截获返回成功响应的报文给验证短信界面。如果客户端未采取包顺序标记验证等措施，就会判断成功直接跳到下一级界面。

尝试抓包截获

• 安装fiddler工具，百度下载。

• 打开工具并设置如下
  

• 随便找一个网页开始发送报文到后台，正常返回界面如下
  

• 点击网页提交表单，会发现fiddler截获了报文，双击左边的记录如下图。
  

• 点击截获响应报文 上图箭头所示 break on response，并且修改响应报文如下图。
  

• 网页获得的报文是被篡改的报文
  

拓展解读

HTTP传输

通过抓包软件可以发现请求头和响应头最终会按ASCII编码转换为16进制，最终转换为2进制在网络上传输。请求body会根据content-type编写的字符集编码进行转换，例如UTF-8。而GET请求tomcat默认是ISO-8859-1传输，所以中文需要encodeURL编码再进行传输，服务端Decoder解码。

APP短信绕过攻击

例如一个app有普通字典功能，可以通过抓包工具抓取成功返回的报文加入为 {succ:true}亦或是加密后的 {OFBSSDFFDDDF}。这个时候短信认证界面随意输入验证码，通过抓包工具截获，将刚刚截获成功的报文返回给app即可让应用认为验证通过。这个是利用软件所有成功返回的报文一致来进行模拟攻击。解决这个问题就必须要求响应报文具备两个条件：

1、成功报文要是动态
2、旧的成功报文不可通过校验

当然也可以后端自己做业务的时候判断用户是否真的短信验证通过，但是如果前端不能避免抓包攻击的话，很多查询接口都会暴露出来。

解决思路：

1、成功报文加时间戳，并且前端需要传递序列号到后端，后端原封不动返回。
2、前端解密后验证序列号是否与请求一致。防止历史成功报文验证通过。
3、因为前端代码和app代码都会被人破译查看，所以加密算法应该为非对称加密，这样抓包者无法模拟成功报文，只能利用历史成功报文攻击，但因为有序列号所以无法验证通过。

以上只是初步一个想法，并未实践，做一个简要记录。