資安JAVA(三六)：解決SQL injection

來源：John Melton's Weblog
標題：YEAR OF SECURITY FOR JAVA – WEEK 36 – SOLVE SQL INJECTION
作者：John Melton

What is it and why should I care?

SQL注入漏洞是因為沒分開處理程式碼和資料而產生。一般而言，開發者善意的設想使用者輸入內容都是資料，但攻擊者自訂輸入內容讓資料庫誤認為命令執行。這裡有些SQL注入攻擊事件，造成財務的、政治的或名譽的損失。若你了解C語言exec函數的問題，你應該認同防護SQL注入的重要性。

What should I do about it?

1. Parameterized Queries
使用參數查詢句(JAVA稱為Prepared Statements)避免攻擊者操作輸入內容，只能輸入特定長度字串、數字、日期等等格式。任何應用程式都適用，開發者不需要多學一種API，只要懂得 SQL 就好。

2. Stored Procedures
當你要將 sql 指令和程式碼分開管理，預存程序是個很好的選擇。如果經過調教甚至可以增進應用程式的效能。

3. Output Encoding/Escaping
輸出內容編碼 / 跳出通常是最終方案，因為需要很多時間修改程式碼，不同應用程式都要進行客製化修改，所以通常人們偏向採用前兩個方案。作者建議可以採用 OWASP 的 ESAPI 框架。

現在我們已經對了解JAVA環境中 SQL 注入問題的解決技術，接著更深入的應用上周的概念，將詳細步驟列出來。

1. 了解問題
多涉獵SQL注入問題的文件吧。同時也針對你的環境中的資料庫，可能遇到哪些 SQL 注入問題，多做研究。當你寫程式時，請小心別用到有弱點的函數、方法或框架。

2. 列出所有使用情境
我會列出應用程式和資料庫之間有幾種互動模式。列出使用幾種程式語言開發？列出開發哪些類型(web、 serveice、視窗應用程式、行動應用程式、大型主機等等)的應用程式？列出資料儲存(OLAP、OLTP、倉儲、批次)的哪些方式？

3. 評估解決方案
參考OWASP SQL Injection Sheet，然後評估OWASP的建議方案是否適合我的環境。我考量的重點是，該方案適不適合所有開發成員，然後思考無法使用的特例。

4. 將解決方案制度化
當你決定解決方案後，請跟開發團隊討論目前資料庫和應用程式之間的關係，是用串接SQL字串呢？還是用參數化字串？請經由這個階段，好好教育開發團隊如何更安全的開發。然後你在進行測試，檢查開發團隊的成果是否符合期待。你也可以降低(應用程式)使用者的存取權限，降低可能造成的傷害。

5. 增加新技術或新流程到驗證步驟
最後階段，我會利用新工具來檢查新的解決方案是否充分利用。
利用靜態和動態分析來檢查 SQL 注入問題是否減少了。
Code Review 應用程式會用到的SQL查詢句。
自訂靜態分析工具的檢查規則，減少解決方案中新的安全函數的假警報。
監控 Log 是否有可疑的活動。( AppSensor 可以幫助你)

希望以上步驟能幫助你，雖然不是十全十美的解決方案，起碼是個好的開始。請記得不要頭痛醫頭腳痛醫腳，改幾個bugs就算了。

參考資料
———–
作者關於SQL注入防護的舊文章
https://www.owasp.org/index.php/SQL_Injection
實用的 SQL Injection Prevention Cheat Sheet
如何在 Java 網站應用程式中防範 SQL Injection, TWISC@NTUST網路應用安全知識庫
———–———–
資安Java: 上一篇 || 下一篇
———–———–