一、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解析，成功执行：

　　接着用菜刀成功连接：