資安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: 上一篇 || 下一篇
———–———–

留言

這個網誌中的熱門文章

資安JAVA(八):HTTP強制傳輸安全(HSTS)

以 SharpPcap 實作可收聽封包的 C# 程式

資安JAVA(四):Session Cookie HTTPOnly Flag