一個SQL Injection漏洞在SDL流程中的闖關歷險記

原文出處：微信公衆號 網絡安全生命週期

[圖文]一個SQL Injection漏洞在SDL流程中的闖關歷險記

 

前言

---

衆所周知，產生SQL注入漏洞的根本緣由是SQL語句的拼接，若是SQL語句中的任何一部分（參數、字段名、搜索關鍵詞、索引等）直接取自用戶而未作校驗，就可能存在注入漏洞。

 

攻擊者經過構建特殊的輸入做爲參數傳入服務器，致使原有業務邏輯中原有的SQL語句的語義被改變，或改變查詢條件，或追加語句執行惡意操做，或調用存儲過程等。

在公司沒有實施SDL流程以前，

代碼一般是這樣寫的（以互聯網公司經常使用的PHP語言爲例）：

 

$id=$_GET['id'];
$conn=mysql_connect($dbhost,$dbuser,$dbpassword) or die('Error: ' . mysql_error());
mysql_select_db("myDB");
$SQL="select * from myTable where id=".$id;
$result=mysql_query($SQL) or die('Error: ' . mysql_error());

 

很顯然，大部分教科書也是相似這樣編寫的，將SQL指令和用戶提交的參數拼接成一個字符串，而後提交查詢。

 

開發完成後，通過簡單的功能及性能測試，就直接上線了。

通常過不了多久，就會有漏洞報告過來。

 

但這絕對不是安全上的最佳實踐。

 

讓咱們來看看實施SDL流程以後，是如何在每個關卡攔截漏洞的。

需求階段有將安全歸入需求的要求，但針對此例暫時略過不提；

方案/設計階段，尚未開始編碼，此漏洞暫不涉及，咱們直接從開發階段開始。

 

假設開發人員沒有安全意識，是按照前面存在風險的拼接SQL的方法編碼的，讓咱們來看看一個SQL注入漏洞將要如何闖過項目的各個關卡，存活到最後。

 

更多內容，請查看原文：

[圖文]一個SQL Injection漏洞在SDL流程中的闖關歷險記