0%

E浙理报表填报流程分析--以健康申报为例

写在前面

特殊时期,学校搞了个每天打卡签到申报健康的玩意,但是由于通过其app打卡速度甚是缓慢,加上我记性差,老是忘记打卡,遂作此文,以分析E浙理的完整报表填报流程。

大一刚来的时候就被强制使用这玩意每日课堂签到,故在之前的摸排中发现使用的是帆软的数据分析这套软件,看过了这套软件的文档,所以有了如下方向。

模拟登陆

直接app端抓包,获取登陆请求的数据包如下,以Json格式将明文用户名和密码传递给服务器。

qq_pic_merged_1583344828358.jpg

要实现模拟登陆我们只要按着上面的格式,POST我们自己的数据包就好了。

burp中构造如下数据包POST过去

4PR3TYL__DMS0F~77KO@I5S.png

在Json格式的response中,找到有用的accessToken保存下来即可。

用户会话

通过正常的app登陆、报表填报分析,得出Cookie中的fine_auth_token被用于分辨用户会话,而fine_auth_token的值正是刚刚我们获取到的Json中的accessToken的值

通过如下格式构造Cookie即可。

1
Cookie: captchaToken=; UM_distinctid=; fine_auth_token=登陆后服务器所返回Json中的accessToken的值

之后设置cookies,即可获取用户会话。

设置好后访问个报表验证下,没问题的。

_8SAL_HDA235I7~__P6ILLS.png

获取当前访问报表

在整个请求头中,最迷惑的就是这个sessionID了,起初我以为这玩意才是用于分辨用户会话的,可后来才发现这玩意是让系统知道当前访问的是哪一个报表的…

那不多说了,根据抓包得到的报表相对路径,设置好token构造get请求获取当前访问报表sessionID就好了。

(相 对 路 径 标 准 拼 音 命 名 法)

9Q@F_NFB@2JQYNNR8___DUY.png

注意,获取sessionID时,如果不带用户token,在接下来模拟填报的过程中虽然返回结果是success,但是是没有真正填报成功的。(这是在封装成app测试的时候踩到的坑)

模拟填报

app端在填报时抓包分析后,可以很清楚的得到如下步骤辽。

设置sessionID

sessionID用于分辨哪个用户访问哪个报表。

设置Cookie

在填报时再次验证用户身份。

发送填报POST请求

设置body如下。

1
op=fr_write&cmd=submit_w_report&reportXML=%253C%253Fxml%2520version%253D%25221.0%2522%2520encoding%253D%2522UTF-8%2522%2520%253F%253E%253CWorkBook%253E%253CVersion%253E6.5%253C%252FVersion%253E%253CReport%2520class%253D%2522com.fr.report.WorkSheet%2522%2520name%253D%25220%2522%253E%253CCellElementList%253E%253CC%2520c%253D%25221%2522%2520r%253D%252240%2522%253E%253CO%2520t%253D%2522A%2522%253E%253C!%255BCDATA%255B%255B%2522%25E6%259C%25AC%25E4%25BA%25BA%25E6%2589%25BF%25E8%25AF%25BA%25E4%25BB%25A5%25E4%25B8%258A%25E5%25A1%25AB%25E6%258A%25A5%25E4%25BF%25A1%25E6%2581%25AF%25E7%259C%259F%25E5%25AE%259E%25E5%258F%25AF%25E9%259D%25A0%25EF%25BC%2581%2522%255D%255D%255D%253E%253C%252FO%253E%253C%252FC%253E%253CC%2520c%253D%25222%2522%2520r%253D%252218%2522%253E%253CO%2520t%253D%2522S%2522%253E%253C!%255BCDATA%255B%25E7%25BB%25BF%25E7%25A0%2581%255D%255D%253E%253C%252FO%253E%253C%252FC%253E%253C%252FCellElementList%253E%253C%252FReport%253E%253C%252FWorkBook%253E&cutPage=

urldecode两次再看看,很明显了,其实就是我们在填报的时候点的那俩按钮,用xml的格式传给了后端服务器。

1
<?xml version="1.0" encoding="UTF-8" ?><WorkBook><Version>6.5</Version><Report class="com.fr.report.WorkSheet" name="0"><CellElementList><C c="2" r="18"><O t="S"><![CDATA[绿码]]></O></C><C c="1" r="40"><O t="A"><![CDATA[["本人承诺以上填报信息真实可靠!"]]]></O></C></CellElementList></Report></WorkBook>

怎么感觉有XXE的…回头试试看

最后完成填报,如下图所示。

`SUK5_`94D_AE_@_XBPK7V2.png

PS.在具体的填报流程中,要先测试数据,然后再发送数据,而测试数据是交给服务器来完成的,这就使得本来就够慢的填报更慢了…所以直接跳过验证数据这一步,直接提交即可。

验证还是提交,是由body中的cmd参数决定的

  • cmd=write_verify

    验证数据

  • submit_w_report

    提交数据

至此分析结束。(回头再更一篇,关于如何用kotlin+okhttp实现E浙理快速填报APP)