简介
客户端和服务器通信发送报文进行通讯,但这些报文可以被截获修改进行一些攻击。对于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代码都会被人破译查看,所以加密算法应该为非对称加密,这样抓包者无法模拟成功报文,只能利用历史成功报文攻击,但因为有序列号所以无法验证通过。
以上只是初步一个想法,并未实践,做一个简要记录。