0%

分析校内体育场馆预约系统的运行机制

通过抓包流量,逆向分析校园体育场馆预约系统的运行机制,发现系统运行的漏洞,实现自动预约运动场地。

使用工具:Wireshark、Python3

声明:本文仅作为科研和学习使用。

体育场馆预约系统为某APP内的一个内嵌功能,很明显是一个内嵌网页,但不需要单独登陆。

1. 流量包分析

首先将手机连接到电脑共享的网络,在手机上进行一次正常的预约操作,使用Wireshark抓取手机产生的流量。

下面将从后往前分析预约操作中产生的流量:

1.1 提交预定

通过过滤HTTP数据包,发现了最终提交预定时,手机向服务器发送了如下图所示的POST请求。

图片无法显示

通过简单的分析,该请求中的URL中参数id=103表示了某一个具体的场地,Cookie中的JSESSIONID区分了某一个具体的用户,POST的请求中携带的param参数中使用了两个id来表示具体要预约的场地和时间段。

通过浏览器Set Cookie工具,模拟发送该Post请求,发现Cookie已经过期了,通过简单的调研,知道了JSESSIONID的原理,如下图所示。那接下来的工作就是找到带有SetCookie的HTTP响应和场地的编码方式。

图片无法显示

1.2 查询可预约的时间和场地信息

在提交预定之前,手机发送了一个Get请求,通过观察Get请求的URL,很容易看出这是在查询可预约的时间和场地信息。请求如下图所示,URL中携带了s_date和serviceid信息,分别用来表示预约的日期和场地。同样的,这个请求也带有Cookie:JSESSIONID信息。

图片无法显示

再向上观察,发现了一个可疑的Get请求,该请求直接访问了系统的index.html页面,一般来说,该页面是用来处理用户认证的。通过跟踪该HTTP流,如下图所示,很容易地发现了该Get请求得到了一个HTTP响应,响应包中包含了Set-Cookie:JSESSIONID的信息,并且该信息与上述数据包中的Cookie:JSESSIONID信息一致。

图片无法显示

该Get请求的URL中携带了userType、code、employeeNo、state和ticket参数:

  1. userType:猜测是用来表示用户类型的,为一个不变量;
  2. code:猜测是用来区分用户的一个值,可能是一个变量;
  3. employeeNo:是当前用户的学号;
  4. state:猜测用来表示用户或系统状态的,为一个不变量;
  5. ticket:为单点登陆的一个常用方法,猜测是一个变量。

1.4 寻找code

通过观察流量,很明显,114结尾的IP地址为预约系统的IP,202结尾的IP地址为主系统的IP。

如下图所示,在第一次访问预约系统前,手机发送了一个Get请求,通过域名,猜测是一个获取code的请求。

图片无法显示

通过追踪该HTTP流,发现确实返回包中携带了code信息,但是Get请求中携带了personToken等其他信息。

图片无法显示

1.5 寻找ticket

发现了一个generateTicket的Get请求,该请求需要personToken参数,返回的数据包中携带了ticket信息。

图片无法显示

1.6 寻找personToken

在本次预定过程中,并没有看到服务器返回personToken的相关信息,猜测可能是在APP登陆时产生的personToken。退出APP的登陆状态,重新登陆抓包,发现了登陆APP时服务器返回了personToken和其他一些后续可能需要使用的字段。

至此,流量分析部分已经完成。

2. 使用Python模拟预约

主要分为以下过程:

  1. 登陆系统,得到personToken、memberId等信息;
  2. 请求生成ticket;
  3. 请求生成code;
  4. 请求Set Cookie:JSESSIONID;
  5. 发送预定请求;
  6. 检查预定是否成功;

该工具还包含以下功能:

  1. 定时启动预约任务;
  2. 查看可预约的场馆;
  3. 根据配置的优先级策略,选择最优的场馆和时间段;
  4. 预定成功后,发送邮件通知。

具体代码暂不开源。

3. 一个发现

在测试中,切换用户测试时,忘记修改学号,只修改了用户名和密码,但仍然预定成功了,并且是给当前学号预定。发现该系统登陆后可以给任何学号预约,因此系统的安全认证存在问题,并且看起来这个系统还是复用了某个商业订单系统,如下图所示,登陆页面显示为商户。

并且存在某些场馆是需要付费的,并且校园卡的付费系统在金额小于30元时不需要提供支付密码,因此存在着金融安全隐患。

图片无法显示

4. 总结

面对一个陌生的系统分析,过程比上述写出来的总结要复杂,比如直接访问预约系统的网页,他跳转到了一个误导性的登陆页面,但尝试多次也无法登陆;预约系统分为/和/web/两个子系统,前者看起来是一个网页版,但实际上无法正常使用,能够正常使用的是/web/的移动端。某些HTTP请求头中的信息如Cookie是可以省略的,而某些不可以。等等许多问题需要在实验中发现,这个工具从开始到实现,大概花了2个半天的时间。

这算是我第一次动手深入分析一个Web系统,系统采用的是HTTP协议而不是HTTPS协议,这给分析带来了巨大的方便,在这过程中也更加深入地了解到了Web系统,特别是用户认证功能。

感谢合作者qj大佬,在这个过程中学到了很多。