淺談php表單安全中Token的實際應用

0x0 背景

以前做等級保護的時候漏掃經常掃描出來一些網站有CSRF的漏洞，由於一般掃描器提示為中風險必須要解決經常和開發人員扯皮要怎麼改怎麼改，每次都描述的不清楚經常感覺心累。

最近看到OWASP的一本《安全測試指南第四版》的書就隨手翻了二頁其中談到了關於會話管理測試的一欄目比較感興趣就從網上隨便下載了一個開源的CMS做一下黑盒測試，練練手萬一失業了還能轉化寫寫代碼做做測試，過程中發現CMS對於很多表單請求都採用了Token認證做的挺好的於是寫個筆記方便日後來看。

0x1 抓包分析

架起代理burpsuit開啟準備大幹一場，首先找到了一個表單的提交頁面，表單主要採用Post方法進行提交，隨便填了點數據就提交了。

通過burpsuit攔截下來之後看一下各個參數

通過Post提交到一個Task的action，看這麼多參數萬一有過濾不嚴格的情況方法說不定能出現一些XSS或者sql注入的漏洞於是就稍微看了一下就發送到了scanner。

Proxy放過之後頁面卻出現了異常提示Token驗證不通過。

然後認真一看發現除了一些表單提交的參數外還有一個token=20e168c64ce1f1f98f89e4c8ff9e3aba的欄位。表單提交之後response數據包當中也有一個新的token」:」e40fe4b3afedc40f95903fef92eb79ed，這樣導致這一個請求包只能請求一次，Burpsuit Scanner基於原有請求包的參數測試的掃描模式就基本上沒有什麼用了。

Token普遍有二個作用：

1.防止表單重複提交

2.anti csrf攻擊（跨站點請求偽造）

由於token具有較好的隨機性，不容易被猜測出來具有良好的安全性，於是看一下源碼當中的實現。

0x2 源碼分析

通過請求的路徑找到對應的php文件，當請求這個表單的時候會自動執行$label->token()這麼一個方法

查看label.php的源碼，token這個方法構造hidden表單定義了一個token的變數後賦值CoreFuncCoreFunc::$token

繼續再查看CoreFunc的源碼，包含了對token生成的過程

調用microtime生成毫秒數之後打散成數組增加隨機性，通過substr提取數字與隨機數相乘之後計算md5保證了token的不可預測性。

Token的隨機性取決於當前時間、rand隨機、md5散列演算法

將生成的token存如session伺服器會話當中

提交的表單主要由task.php處理task類當中只是讀取了session中userid的欄位，使用父類Content的 parent::action($jump, $commit)方法進行驗證通過之後再處理表單數據。

一層又一層，感覺真複雜。Content類繼承了Controller中的checkToken()檢查

Token無論驗證是否通過都會刪除當前token的值保證了不會被重用

0x3 總結

session應用相對安全但也繁瑣，同時當多頁面多請求時必須採用多Token同時生成的方法，這樣佔用更多資源，執行效率會降低。但是對安全性的提升是明顯的，對於表單的重複提交、基於單個數據包的變形掃描、解決CSRF漏洞也不是一種不錯的方式。

*本文作者：si1ence，轉載請註明來自FreeBuf.COM

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！