[Security]SQL injection的簡介與預防

前言 『程式不是會動就好！』，在安全性上的設計，更是完全的貼切這句話。如果設計出在裸奔的網站（請參考黑大的文章），就算網站上的功能可以正常運作，但千瘡百孔的網站，可能淪為人家的玩物或是提款機。 SQL injection的問題，在前幾年掀起了不少次旋風，甚至包括現在可能還有一堆網站有著同樣的問題，要命的是，根本不需要到駭客等級，就可以把有SQL injection問題的網站搞掛。一個程式設計師寫出來的程式，最要不得的就是有SQL injection的問題，我個人認為那是程式設計師不夠專業，甚至不夠格的表現。這不需要多高深的技巧跟學問，要嘛就是程式設計師偷懶，要嘛就是還不夠專業。 這篇文章簡介一下，SQL injection的基本原理，以及基本的防範措施。 什麼是SQL injection 回到之前重構系列的第一篇文章：[ASP.NET]重構之路系列v1 – UI, Business logic, Data access概念分開 畫面： 需求： 當輸入的帳號密碼，在資料庫中有吻合的資料，代表帳號密碼是對的。（再強調一次，一般設計驗證密碼的部分，應該是透過畫面上輸入密碼的值進行hash，再與資料庫中該帳號所對應hash完的密碼比對，以保障密碼不是以明文存在於資料庫中，確保密碼無法被還原） 直覺設計且造成SQL injection問題的程式碼： view source print? 01 protected void Verify_Click(object sender, EventArgs e) 02 { 03 string connectionString = @"myConnectionString"; 04 int count; 05 using (SqlConnection cn = new SqlConnection(connectionString)) 06 { 07 cn.Open(); 08 string sqlStatement = @"Select Count(1) From SomeTable Where ID= '" + this.Id.Text + "' AND Password= '" + this.Password.Text + "'"; 09 SqlCommand sqlCommand = new SqlCommand(sqlStatement, cn); 10 count = (int)sqlCommand.ExecuteScalar(); 11 } 12 13 this.Result.Text = (count > 0) ? "Pass" : "帳號或密碼錯誤"; 14 } 這樣的程式碼會有什麼問題？ 問題可大了！ 假設我是壞人，知道或猜測這功能的SQL是這樣串的（大部分功能都很好猜的，猜錯了也不會被咬），那麼我只要在畫面上的Id，隨便輸入個值，接著在密碼的部分，輸入' OR 1=1; -- 這時候，這一支聰明的功能就可以把完整的SQL statement組出來，變成： view source print? 1 Select Count(1) From SomeTable Where ID= '隨便輸入' AND Password ='' OR 1=1; -- 輸入這樣的值代表什麼，代表所有畫面上的輸入值都無所謂，因為1=1恆等式一定會成立，且前面的condition為OR，所以可以把前面的where condition都忽略掉。後面再補上個分號，代表這一個SQL子句已經結束，最後再補上--，代表後面的sql為註解。 就這樣，最基本的SQL injection就成功了。是的，這個網站在裸奔了。 如果你以為，只有登入頁面會存在這樣的問題，或是這樣的問題影響不大，那就大錯特錯了。通常會寫出這樣程式的人，如果又都是自己設計，那洞就不只一個。首先，DB的存取帳號，可能就是預設的sa或admin，也就是權限開到最大。這時候的SQL injection要進DB做事，就跟進自己家廚房一樣，例如： view source print? 1 Select Count(1) From SomeTable Where ID= '隨便輸入' AND Password ='' OR 1=1; DROP DATABASE pubs -- 恭喜你，你DB中的pubs這個DataBase就被Drop掉了。 駭客高興的話，也可以針對sysobjects跟syscolumns來瞭解你DB中有哪些table, 欄位，再比對一下網頁的資料，接著透過Update的語法，把相關的欄位資料加入一些html tag或惡意的程式碼，進而引發從SQL injection觸發的Cross-site Scripting(XSS攻擊)，常見的結果就是連到那一頁時，可能被導到別頁，或是XX政府網站上被掛上特殊的國旗，再來就是莫名其妙的個資外洩。 這些情況充斥在我們的生活中，這一切的原罪，都是因為程式設計師的偷懶或不專業。 除了上述的例子，還可以怎麼瞭解SQL的組成？以ASP.NET來說，一樣，通常會寫出那樣有問題的程式，web.config可能也沒有設定custom error頁面，所以當程式出錯時，IIS就大剌剌的幫你把程式錯誤的資訊show在網頁上（就是黃頁的那個），要讓錯誤資訊是掛在SQL statement執行錯誤，是一件再簡單不過的事。所以，要瞭解該網頁的輸入和對應SQL的組成，根本不需要駭客等級就可以做。瞭解之後，要啟動SQL injection，也就只是易如反掌的事。 如何避免SQL injection 簡單的說，過濾輸入值。 但，攻擊手法相當多種，要過濾的字元組合可能一個都漏不得，所以自己設定黑名單來進行過濾，是一件非不得以才做的事。如果是用ASP.NET寫，那所有人的強烈建議，就是使用Parameters。 Parameter的用法相當簡單，這也是為什麼我前面會說，寫出SQL injection問題的程式碼，是一種偷懶的行為。 對應剛剛上面的範例，使用Parameter的方式來改寫： view source print? 01 protected void Verify_Click(object sender, EventArgs e) 02 { 03 string connectionString = @"myConnectionString"; 04 var id = this.Id.Text; 05 var password = this.Password.Text; 06 07 int count; 08 using (SqlConnection cn = new SqlConnection(connectionString)) 09 { 10 cn.Open(); 11 string sqlStatement = @"Select Count(1) From SomeTable Where ID= @id AND Password= @password"; 12 SqlCommand sqlCommand = new SqlCommand(sqlStatement, cn); 13 14 ////定義parameter型別 15 sqlCommand.Parameters.Add("@id", SqlDbType.VarBinary); 16 sqlCommand.Parameters["@id"].Value = id; 17 18 ////讓ADO.NET自行判斷型別轉換 19 sqlCommand.Parameters.AddWithValue("@password", password); 20 21 count = (int)sqlCommand.ExecuteScalar(); 22 } 23 24 this.Result.Text = (count > 0) ? "Pass" : "帳號或密碼錯誤"; 25 } 透過使用parameter，在SqlCommand執行時，會自動過濾掉可能造成問題的字元。 另外，SQL injection並不只會發生在where condition，也有可能發生在Order by等語法中。所以只要是畫面上可能被改變的值，要串到SQL語法中，就應該使用parameter。如果是Parameter無法使用的語法，例如Table的名字，那也應該自己建立一個mapping module，來避免畫面上user可任意輸入且可能為惡意攻擊碼的值，直接存進DB中或被非預期地執行。 結論 在patterns & practices Developer Center簡單歸納出三個步驟防止SQL injection： 1. Constrain input. 2. Use parameters with stored procedures. 3. Use parameters with dynamic SQL.