APP渗透测试：（一）信息收集

APP渗透测试：（⼀）信息收集
⼀、APP渗透和web渗透，没有本质区别，相同点：
都是客户端（浏览器是特殊的客户端），都要和服务器做数据交互
APP发包很多也是⾛http协议，抓包的内容和浏览器发包的内容没区别
SQL注⼊、验证码绕过、越权漏洞、⽀付漏洞、CSRF、变量覆盖、反序列化、⽂件包含、SSRF、XXE、⽂件上传等在web常见的漏洞，APP也可能存在（尤其是中⼩型APP，安全防护肯定不如⼤⼚的全⾯）；
不管是APP，还是web，渗透的核⼼之⼀是通过控制传参，改变原本的代码执⾏流程和逻辑，达到我们想要的⽬的；http协议中能让⽤户⾃由发挥、随意设置参数的地⽅：GET（url传参）、POST（消息体）、COOKIE（⼀般和权限控制、⽤户⾏为记录等相关），后续会重点关注这3个地⽅；
不同点：
web前端多由html、js、css等构成，能直接通过浏览器查看，相对简单；
APP多由java、c构成，查看源码还需要⽤jeb、jadx、anroid killer等反编译，甚⾄要先脱壳，有点⿇烦；so层的C代码也可能被混淆、增加花指令，⽤IDA的F5反编译也可能看不出啥；
⼆、数据从⽤户侧的APP或web传到服务器，中间会经过N多节点；为了保证每个节点都能⽆误地转发数据，开发⼈员可能会在客户端对关键性信息做base64编码，
1、base64 编码后数据的特征：
⼤写、⼩写、数字混杂，⾁眼直观看不出有啥意义
末尾有=号
长度不统⼀，有长有短
只要原字符串不同，编码后的结果绝对不同
base64由于不是加密算法，所以不⽤密钥可以直接还原成编码前的样⼦，俗称解码；
2、出了base64，另⼀种⼚家的加密⽅式是MD5；MD5编码后的数据特征：
不论原数据有多长，加密后⼀般都是32个字符；⾁眼直观看不出有啥意义
⼩写字母、数字混杂，没有⼤写字母
算法不可逆，只能⽤加密后的密⽂和现有密⽂⽐对，匹配上了再反查明⽂
以上特征很重要，只要在数据包看到了类似的数据，说明“此地⽆银三百两”，肯定是重要的参数，建议优先从这些信息突破；
三、1、拿信创oa办公系统举例：打开APP就是这个界⾯；由于是办公oa，业务特性决定了该APP没有注册功能；“忘记密码”直接弹窗让联系管理员。

这⾥已经没其他办法了，只能爆破管理员账号；
管理员⼀般叫admin（这⾥为了⽅便识别，密码输⼊的123456），⽤burp抓包结果如下；仔细观察，有3个字段的内容直观⽆法理解，分别是：GET的device、POST的user和pass；
从英语字眼看：
　device应该是设备的编码，编码⽅式暂时不详；
　user和pass从字⾯看可能是⽤户名和密码，但字段的value明显不是我输⼊的admin和123456；value是⼤写、⼩写、数字混杂，长度不⼀，有点像base64编码，所以这⾥尝试⽤base64先解码试试，发现pass确实是123456；但user结尾是%3A，url解码是：（冒号），不是base64常见的=结尾，怀疑是开发⼈员很鸡贼，故意⽤冒号替换等号，这⾥先换回等号结尾，再⽤base64解码，成功还原admin；
2、接着就简单了，把常见的密码先⽤base64编码，结尾的 = ⽤：替代，再⽤burp爆破；这⾥构造两个payload：deviceid末尾3位，从100到999随机选择，造成请求从不同设备发出的假象，避免被ban；
pass⽤base64编码后的字典爆破；
终于发现了⼀个返回包和其他不⼀样，从返回的字段看，登陆成功；把request的pass(d29haW5pMTMxNDUyMA%3A%3A)⽤base64解码，⽤得到的密码成功登陆；
3、本着“见框就插”的原则，试了很多地⽅输⼊<script>alert(666)</script>，发现并未弹窗，抓包后重试，发现尖括号、斜杠等被前端转义了，如下：
既然前端不让输⼊特殊符号，就直接在包⾥⾯添加，如下：
结果还是不⾏；继续在其他能输⼊的地⽅都尝试，终于在催办找到⼀个xss漏洞，弹出了对话框；这还是个存储型的，任何⼈只要点开出差->查看详情的模块都有可能中招；
4、出差这⾥有上传⽂件的地⽅，先上传图⽚马：
从返回包看，这⾥有上传⽂件的路径：
根据图⽚的存储路径，利⽤CGI解析漏洞，把jpg⽂件当成php解析，成功执⾏：
接着⽤菜⼑成功连接：。