O2O产品质量保障体系(二)安全测试-百糯产品安全测试与质量保障
2016-07-26 {{allComments.length}} 73774 干货分享什么是业务安全测试
传统的安全漏洞主要是针对现有的服务器或系统库等通用技术上的安全策略上存在的缺陷，例如Dos攻击、WebShell提权、XSS利用、ActiveX提权、Sniffer嗅探及缓冲区溢出等方式，而在开发时往往忽略了与具体产品业务相结合时未考虑周到的安全问题。我们的业务安全测试主要是在传统的安全漏洞的基础上进一步考虑与具体业务场景相结合的一种测试方法。这些业务安全漏洞脱离了具体所使用的操作系统平台版本，系统API接口，物理机器性能，网络路由器等传统安全所依赖的一些硬件场景，相反它依赖于所存在的具体业务场景。
详情 ↓
图 1.1 业务安全测试
一、整体概述
典型产品线的业务整体流程大体都是按照从端到服务器，再到数据库的访问机制，在到达服务器的时候进行一次分流，再到达数据库的时候又进行了一次分流，如下图所示：
图2 业务整体流程
从图中我们看到一般产品有三个端，一个是移动端的Native APP应用，一个是手机上的浏览器方式访问，一个是传统电脑的浏览器访问；从端到服务器的时候需要进行授权及分流，也就是允许哪些端访问哪种类型的服务器，通过分布式机制进行网络流量的分流，然后到达图中标红的结点，进行业务处理，再分流进入数据库进行读写操作。
而我们的业务安全测试则是从端上开始来进行业务上的相关测试请求，从而测试是否影响后台数据并且影响别的端上的用户，我们主要是利用从端上到达分流节授权节点前进行请求上的测试，从传统安全上来说，是合法的，但是从业务处理上来说则可能存安全上的隐患。下一章节将详述常规的安全测试技术有哪些，并且是怎样影响从端上到达服务器的。
安全测试技术主要分要五个技术环节，包括分析业务资源接口，提取业务接口，将接口进行篡改尝试，伪造真实用户及进行重放攻击，具体如图所示：
图 3 安全测试技术
2.1.1 TamperIE拦截
我们在浏览器前端或APP端的发送的任何请求都可以通过插件或工具在请求发送出去前进行拦截，针对微软的IE浏览器，我们有TamperIE的插件，如下面的图所示：
图 4 TamperIE拦截糯米搜索请求
此时，我们可以对当前的请求的参数进行修改，再发送出去，这样即可以达到修改端上的请求内容的目的，从而绕过前端js脚本的限制等因素。拦截的请求一般分为两种一种为Get请求，另一种为Post请求，其中Get请求的参数可以直接在URL的参数里修改，但Post的请求需要另外构造数据data部分拼接到post的buffer后面。
2.1.2 Chrome网络拦截
Chrome自带的http抓包的工具界面简洁大方，功能也很强大，唯一的不足就是界面是英文的。打开方式，点击右上角的菜单-工具-开发者工具：
图 5 Chrome抓包
打开之后默认就是监测状态，点击工具左上方的小红点record network log，可以记录下整个访问过程中所有抓包结果，否则只记录当前页面的抓包结果，用于记录存在跳转页面的抓包时该项非常有用，清除抓包结果可以点击红点右边的小圆圈。任一点击一条http请求，在工具右边会列出该请求的详细信息，包括请求头，请求方式，提交的内容，cookie等内容。
2.1.3 tcpdump抓包拦截
手机端的抓包就没PC机上那么方便了，这里我们选择了tcpdump作为其中抓包的一个常用工具，它就是一种免费的网络分析工具，尤其其提供了源代码，公开了接口，因此具备很强的可扩展性，对于网络维护和入侵者都是非常有用的工具。
图 6 tcpdump安装
tcpdump存在于基本的FreeBSD系统中，由于它需要将网络界面设置为混杂模式，普通用户不能正常执行，但具备root权限的用户可以直接执行它来获取网络上的信息。因此系统中存在网络分析工具主要不是对本机安全的威胁，而是对网络上的其他计算机的安全存在威胁。
Cookie是由服务器端生成，发送给User-Agent（一般是浏览器），浏览器会将Cookie的key/value保存到某个目录下的文本文件内，下次请求同一网站时就发送该Cookie给服务器（前提是浏览器设置为启用Cookie）。Cookie名称和值可以由服务器端开发自己定义，服务器可以设置或者读取Cookie中包含信息。
Cookie中常常用来存储服务端需要维护的会话信息，这样服务器可以知道该用户是否合法用户以及是否需要重新登录等。因此Cookie中实际包含了大量的敏感信息，常见的XSS被动式攻击方式最终就是为了获取用户里的用户cookie信息。由于单点登录的出现，造成给用户方便的同时，也给安全带来了隐患，他给cookie原有的限域变为了跨域，使得不同域名的网站可以访问同一用户。
对Cookie的篡改有相关的浏览器插件工具，如EditThisCookie，可以直接在当前网页打开该插件，如图所示：
图 7 Edit This Cookie工具
我们可以直接对该域名下的cookie信息进行任意的修改，如图1中有flag，domainURl 等键值，这些修改后对服务端而言就是不可信认的用户了。
2.3.1 构造认证流程
浏览器在用户端一般以本地存储的方式将用户信息存储在客户端，从请求开始需要带上这样的用户信息到服务端，服务端接收请求进行相应的处理，如下图所示：
图 8 认证流程
从图中我们可以看到服务端收到密码后会对其进行校验，会结合服务端自身的密钥算法进行认证，我们只要按照这个流程就可以完整的构造一个用户的认证过程。
2.4 重放攻击服务接口
有了上面签名的认证构造以后，我们可以对任意的链接进行高频率访问，从而可以检测当前服务器是否对其进行了限制及限制的方式是否恰当，重复大量访问的方式就不能单纯的依赖于浏览器来进行了，我们必须构造四种类型的访问请求API接口，分别为httpGet，httpPost，httpsGet以及httpsPost请求，其中后面两个是https协议，由于糯米帐户中涉及到支付，所以会存在https的加密访问方式：
图 9 请求接口
从图4中我们可以看到，糯米利用了cookie中的bduss帐户信息，这个在后面我们可以看到非常的关键，POST和GET的重放攻击方式取决于服务器的响应方式，这个也尤为重要，不能随意选取，而且要根据其频率做调整。
GET是获取信息，GET请求的参数会跟在url后进行传递，请求的数据会附在URL之后，以?分割URL和传输数据，参数之间以&相连,％XX中的XX为该符号以16进制表示的ASCII，如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密。
GET传输的数据有大小限制，因为GET是通过URL提交数据，那么GET可提交的数据量就跟URL的长度有直接关系了，不同的浏览器对URL的长度的限制是不同的。GET请求的数据会被浏览器缓存起来，用户名和密码将明文出现在URL上，其他人可以查到历史浏览记录，数据不太安全。
POST请求则作为http消息的实际内容发送给web服务器，数据放置在HTML Header内提交，POST没有限制提交的数据。POST比GET安全，当数据是中文或者不敏感的数据，则用GET，因为使用GET，参数会显示在地址，对于敏感数据和不是中文字符的数据，则用POST。POST表示可能修改变服务器上的资源的请求，在服务器端，用POST方式提交的数据只能用Request.Form来获取。
如果你看的意犹未尽，如果你想随时随地充实自己，请扫描以下二维码，关注我们的公众账号，可以获取更多技术类干货，还有精彩活动与你分享~
