企業檢測SQL注入的一些方式探討

尋找SQL注入點的 way

在企業中有以下幾種方式能夠選擇；

• 自動化
  - 白盒基於源碼卡點審計
  - 黑盒基於流量進行自動化掃描
• 手動
  - 手動白盒看代碼
  - 手動黑盒檢查

MySQL Inject 入門案例

沒有作任何過濾，直接把參數插入到SQL語句中，就是注入點；

PHP Demo:

// 接收來自前端輸入參數id
$uid = $_GET['id'];
// 構造查詢SQL語句，注意這裏，uid參數沒作過濾就放到SQL語句中進行拼接
$sql = "select * from user where user_id = $uid";
// 語句也未使用預編譯，就執行查詢動做，SQL注入就是這麼產生的
query($sql);

注意，上面只是一個演示案例，如今的Web框架基本是MVC模式的，Model層通常不接收前端的參數，接收前端參數通常在Control層完成，也就意味着查詢SQL注入的時候你須要跟蹤一個前端參數從Control層傳遞到Model。這期間，一個前端參數可能會通過十幾個函數的調用傳遞都是有可能的。這個時候考驗你的就不是技術了，而是耐心。

自動化審計的嘗試之旅

最開始使用的是Seay源代碼審計工具，後面使用的是Rips代碼審計工具，發現都不能知足本身的需求，由於有個致命缺陷，就是會有遺漏的SQL注入找不全。這樣就很是危險了，你說XSS、CSRF這種攻擊客戶端的洞，漏幾個就漏幾個了。但SQL注入這種攻擊服務端的漏了幾個，若是漏的那幾個還被外部發現了，那飯碗還要不要了？

比較的結果是 Rips 比 Seay 誤報率、準確率要高好幾個檔次。使用Risp能提升審覈的效率，可是並不能提升精度，因此正確用法的是，拿到陌生的代碼時，可使用Rips先掃一遍，先找出一些容易找到SQL注入點。想要覆蓋全，而且有精度的效果，往下看。

Taint這種參數污染標記跟蹤的工具又會比Rips的準確率高。

人工審計才能保證精度

精度和效率感受是個矛盾；

Taint總會有誤報和漏的，畢竟taint是基於流量的，若是沒有人點擊那個url，是不可能檢測出來的，能夠用一個笨方法來解決，如今的情景下，光靠檢測工具是可能的，只能說依靠工具輔助人來提升效率而已。