背景：
這是某OA的一個頁面，主要功能是供用戶提交一些需求，頁面有表單和文件上傳接口，在對該頁面進行安全測試的時候，我希望對這些用戶輸入表單進行存儲型XSS的測試，然而由於頁面使用了隨機Token，致使用掃描器進行掃描時發現並不能批量寫入。於是用Burp進行手工測試。
使用Repeater模塊進行重放：
在對數據提交頁面進行重放時，發現不成功。猜測是服務器端對請求數據的某個變量進行了驗證。如圖。
使用Comparer模塊進行比較：
根據經驗，第一反應判斷是因爲“n_s_token”這個參數起的作用。謹慎起見，還是重新在頁面上填寫測試數據，再提交一次。將兩次提交的數據都發送都發送到Comparer模塊進行比較。比較發現有3處變量是系統生成的數據不同，其它數據不同都是因爲兩次用戶提交的數據不同而造成的，可以忽略，那麼就只用關注3個用戶自動生成的變量即可。這3處變量是：
1、Content-Type中的boundary
2、Cookie頭中的td_cookie
3、正文數據部分的n_s_token
於是，不斷重新在頁面上填寫測試數據，截斷髮送到Repeater模塊進行修改，依次去掉或修改Content-Type中的boundary以及Cookie頭中的td_cookie都能提交成功，而當修改了n_s_token的值時，發現提交不成功。於是判定就是n_s_token從中作祟。下一步就是找到這個n_s_token到底是從哪裏來的了。
使用Proxy模塊查找隨機Token：
分析：
既然服務端驗證的是n_s_token的值，那麼這個隨機token一定是服務端構造發到客戶端，再由客戶端的這個頁面提取的，那麼這個token一定存在於某個請求的返回數據（Response）中（當然我這樣說可能有些絕對，但這是最直接最常用的方法）。
複製n_s_token的一個值dc75246e96b9738ee3f1d46ff8ed12be，切換到Proxy模塊下的HTTP history選項卡，同時在數據展示區切換到Response選項卡，將值粘貼在最下面的搜索區。然後在數據請求區依次翻，最終找到這個Token是在一個頁面的返回數據的input標籤中，以隱藏表單的方式由服務器發送過來的。如圖：
至此，隨機Token的產生就被找到了，下一步就是利用python獲取隨機token然後進行批量提交數據了。請看我的下一篇Python安全之繞過隨機Token——使用requests進行批量提交XSS Payload。