一、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解析，成功執行：
接着用菜刀成功連接：
