Web via app安全研究

目录

一，背景概述

二，web via app审计

三，将来的工作

一，背景概述

1.1 第三方应用综述

现在的互联网厂商往往希望将自己的业务迁移到移动端，方便客户使用，这些应用一般被称作第三方app，他们的特点是：“多网络通信，少本地逻辑”，用户在界面点击，使app向server服务器发送特定的数据包，通过这样的一种过程的重复，实现第三方app的功能。

1.1.1应用分类

下面我根据暑假的观察，将app分为这样三类：

信息提供类应用

这种app一般是传统web行业的扩展，例如网易新闻客户端，大智慧股票手机端，app的作用是将基于web平台的服务复制（延伸）到手机上，便于 客户使用。这种app的特点是：输入得少，点击得多，与使用者关联小，不需要注册，也不需要个人信息往往就能使用。其背后的server架构是这样的。

实例： 墨迹天气，网易新闻，大智慧手机客户端等

移动金融类应用

这类app的主要作用是代替网页端进行商品购买，产品的选购。由于这类app涉及金融，所以需要用户输入极其详细的个人信息（手机号最低要求）。 此类app的架构往往是独立的api服务器为app客户端提供数据返回。 实例：饿了么，中国平安手机端，美团外卖等

社交活动类应用

这类app主要供客户做社交用途，比如社区交友，提供跳蚤平台等。

从用户角度来讲，这类app的特点是需要大量的个人信息（生日，名字，身份证，手机号等）以完成注册。从server端角度来讲，这类app提供了更多的输入功能（图/文）

实例：58同城，陌陌等

1.1.2 应用与传统web业务的异同

传统web业务与app最终提供到用户手中的服务是相同的，所以他们大体相同：

传统web与安卓app比较时，我们可以列出这样一个等价表格：

web服务器 <=> api服务器

浏览器 <=> 客户端app

但是他们之间依然存在差异：

一个web服务器，大多以index页面作为主要入口，可以通过index调转各个分页面。所以我们能够借助传统安全扫描工具对整个网站进行扫描，挨个页面进行测试。

但是api服务器却不同，由于入口位于客户端，我们想要访问api服务器并返回需要的信息，往往需要借助app构造特定的请求，而不借助app对api的访问，往往只会返回一个错误提示。所以通过安全扫描器去扫描的时候，无论是基于爬虫的wvs，还是基于字典的目录爆破，都不能正常工作。

web服务器的逻辑判断往往全部放在服务器，通过php/.net/java等语言对收到的数据进行处理，判断。只有极少的输入处理逻辑，可能通过浏览器语言进行判断（javascript）。

api服务器则不同，开发者往往会将一部分他认为不会影响到安全的逻辑放在本地进行判断，将中间结果放到服务器上再处理，然而，有时候这些看似“无关紧要”的逻辑，可能带来潜在风险。

1.2 安全风险研究点

正是因为现在越来越多的厂商希望把自己的产品开发，移植到移动平台上来（android/ios），然而将业务线延伸到移动端后，原本基于传统业务的安全规则，可能失效或者需要被改写，往往导致一些安全问题。

那么这样的环境下，我们需要考虑的是两个方面的问题：

一，传统安全风险的检查

首先，传统web漏洞在新环境下也是存在的，我们可以通过代理拦截，修改数据包，再次提交数据，来对传统的安全风险进行测试，比如sql注入，上传漏洞，逻辑漏洞等。

二，新安全风险的探索

同时，开发者往往会自己设计一些保护措施，对这个通信进行保护（签名校验，重放检测等）防止使用者恶意使用app。然而这些安全措施一旦被绕过，往往起到长驱直入，直捣黄龙的攻击效果。

接下来我就结合所总结的app种类和安全风险，详细分析下app安全审计中可能出现的问题。

二，web via app审计

2.1 审计优势与攻击面

传统web与app的异同，导致了审计app具有一定的优势：

当web与app结合之后，由于对于app的每一次点击实际上就是一次post/get行为，而这些post/get是完完全全存储在本地的。我们能够通过app（反汇编，动态监听）来更加了解api以及web服务器的结构。 有失偏颇地讲，我们可以完全有能力通过对app的分析，获取api服务器的所有页面以及与这些页面进行交互时的所必须的参数，这类的信息获取在渗透测试中是极其重要的 （传统web渗透可能只能通过爬虫，目录穷举去获取的部分页面）

2.2 审计环境与手段

Burp

burp在这里起到监听通信流量的作用。

在这里我们需要监听8080端口，并且将手机代理服务器设置为8080

2.3 审计思路

2.3.1 环境探测

当一个app拿到手，我们首先应该学会用审计web安全的思路看待。那么首先我们需要做的就是对我们所要检查的api服务器有个大致的了解。

首先通过对返回包的检查，我们了解到服务器中间件的类型： 

比如上面我就能看到这是来自nginx的响应, 而nginx一般搭配php或者java

对结合对请求包的检查和服务器中间件类型，我们能确定api服务器所用的语言：

在所提交的cookies中，如果出现“php_sessionid”等 基本确定为php，如果为”jsessionid”则为jsp

对于中间件来说：apache/nginx往往搭配php，而tomcat往往配合javaweb。

这样我们就能确定后端数据库的语言了，因为他们的搭配往往也是固定的：

php – mysql

java- oracle

.net – mssql

只有确定了后端中间件类型，数据库类型，我们才能采用对应的payload进行攻击。

我们在上面提到了两种审计方向：传统风险的检查和新安全风险的发掘。

2.3.2 传统风险的检查

针对传统风险，我们需要关注这样几个方面：

一，sql注入

sql注入是当代码层将用户输入的数据进行拼接后，没有对数据检查就传入数据库层而出现的安全问题，由于这一连串的过程web via app也同样存在，这些app背后的api服务器同样可能遭受sql注入攻击。

测试过程： 通过上文提到的burp，我们得知了api服务器有关信息

后端服务器情况：php-mysql

api服务器域名 api.liduoduo.com

在某个类内找到大量url连接 

阅读反汇编代码，按照要求拼接出请求包中的字符串。

由于后端是mysql，我们可以通过逐个对参数添加单引号进行注入检测。当然我们也能够通过上文提到的sqlmapwrapper对sql注入进行详尽地自动化检测。 当然也能够手工测试 payload如下

对于未开启数据库错误提示的，会返回空，我们也可以通过盲注来检测。

二，越权风险

越权风险一般出现在app的个人信息，订单详情等activity中。

每个请求信息的数据包中，都会具有相应的id，那么一旦这个id作为获取数据的唯一凭据（不比较cookies与id是否匹配，或者cookies可伪造）就能导致任意资料查看，任意用户登录。

三，上传漏洞

风险一般发生在测试手段与传统思路同，burp截取数据包，根据apache解析特性（1.php.jpg）以及测试直接改名成php/jsp后缀上传，测试是否能getshell。

四，特殊文件格式的攻击

一些组织制定了一些数据格式，如json，xml，而这些格式往往就能带来攻击。

xml实体注入

当app端向server服务器发送了xml数据并要求客户端解析。由于系统底层c函数，解析xml的时候会识别xml文件中是否出现特定的xml 语法，并执行相应的操作。 而xml提供的语法，能够实现类似print file ,wget类似的功能，所以可能造成任意文件读取，或者是ssrf内网攻击。

可以看到我们的请求中，由app生成了一个特定的xml文件发送到api服务器进行处理。其中有一个字段叫做url 通过猜测和经验，我们觉得这应该是一个能够发现url requrest的xml，所以我们尝试对内网的ip端进行内网扫描。 图中我们请求了10.1.1.172的9090端口 并看到了内网中web的返回。

通过请求的返回信息，我们能够知道所请求页面的情况，这时，app就相当于是渗透内网的代理，通过app能够对内网所有机器进行扫描。

2.3.3 新安全风险的探索

一，防篡改机制

如今很多app厂商为了防止用户恶意篡改app生成的http（https）请求，往往利用自己设计的算法对所提交的数据进行签名，并且在api服 务器验证签名的正确性。 那么破解了算法之后，我们能够任意篡改输入的数据， 那么当app某些流程是在本地进行判断，或者是直接发送数据到服务器进行判断的时候，我们能够抓包然后对数据进行篡改，最终破坏业务逻辑。

程序员设计的签名算法的思路大致是这样：在app内部利用算法，将所要请求的数据与某些特定的字符串做抑或+base64，或者MD5。算法的实现可以放在java层，也有些放在native层，目的都是为了混淆，增大破解难度。

详细的破解流程发布在了我的博客上 http://www.x1aof3i.cn/?p=250

破解后能造成数个危害，比如：

电话轰炸 

撞库攻击 

二，重放检测 对于app某些特殊的功能（调用客服接口拨打电话，领取优惠券等），我们可以进行重放攻击。 比如外卖应用饿了么 饿了么提供了一个电话播放验证码功能，当点击播放验证码按钮之后，按钮变灰，不能使用，后端客服api此时会向指定手机拨打电话，然而这个按钮的重放检测存在于app中，我们拦截请求包，利用burp反复请求，就能起到电话轰炸的效果

2.4 不同设计下app的审计侧重点

不同种类的app因为业务需求不一样，自然有不同的设计，上面我们将app分为了三类，不同的app的薄弱点也是不同的。

信息提供类应用

对于这种类型的app，由于大量的服务和测试的思路和传统web安全审计类似，这是和传统web渗透的相似之处，不同之处在于，当web与app结 合之后，由于对于app的每一次点击实际上就是一次post/get行为，而这些post/get是完完全全存储在本地的。我们能够通过app（反汇编， 动态监听）来更加了解api以及web服务器的结构。 有失偏颇地讲，我们可以完全有能力通过对app的分析，获取api&web服务器的所有页面以及与这些页面进行交互时的所必须的参数，这类的信息 获取在渗透测试中是极其重要的（传统web渗透可能只能通过爬虫，googlehack去了获取web服务器的部分页面）

移动金融类应用

这类的app的攻击方式倾向于对用户数据的侵犯（水平越权），对业务逻辑的篡改。

社交活动类应用

从用户角度来讲，这类app的特点是需要大量的个人信息（生日，名字，身份证，手机号等）以完成注册。从server端角度来讲，这类app提供了更多的输入功能（图/文） 这类的app的攻击方式更也倾向于对用户数据的侵犯（水平越权）。

三，将来的工作

将来的工作我计划依照上述提到的两种安全风险双线进行：

传统安全风险的自动化测试

传统web安全已经有大量的前人分析，也有大量的工具，那么将这些工具移植到app测试平台上来，建立一个规范的app web审计模型是一件能够节省大量劳动力的工作，（前面提到过，传统安全审计工具是无法在基于app的web中使用的）

暑期中所开发的webdroid，sqlmapwrapper就是这方面的努力。

webdriod

设计目标是针对运行时的app进行内存篡改，进一步测试app中存在的逻辑问题（越权）

sqlmapwrapper

设计目标是将所有发起的url 请求进行详细的sql注入检测，自动化地将这些请求送入sqlmap。

新安全风险的继续探究

实际测试中， 除了上述说到的安卓密码学问题，重放问题以外，还在android应用检测到一些可疑的缺陷，（比如有些app对是否是会员的检测比较简单，是否能够简单 地构造一些本地服务，实现会员的免费使用）这些缺陷可能会在大量实例中暴露出来。接下来，希望可以进一步研究，发掘新的安全问题。

【via 肖峰@whu】