青海網站建設、網絡推廣最好的公司--您身邊的網站建設專家,馬上拿起電話,聯系我們:0971-8235355   
黑龙江11选5预测网 黑龙江11选5预测网 |  公司簡介 |  網站建設 |  網絡推廣 |  空間租用 |  域名注冊 |  企業郵局 |  網絡安全 |  網站編程 |  客服中心 |  聯系我們 |  人才招聘
 
西寧威勢最新網站制做案例展示
Lastest Project
 
西寧網站建設  
當前位置為:黑龙江11选5预测网 >> 腳本安全 >> 正文  
[原創]將SQL注入攻擊阻止在發生之前[一]

文章來源: 黑龙江11选5预测网     發布時間:2009-10-27    瀏覽次數:9739    tags:C# .NET 防止SQL注入

將SQL注入攻擊阻止在發生之前[一]

    注意,此文是黑龙江11选5预测网技術人員:孤行一鬼(QQ:147399120)翻譯英文技術文獻而來,原文章版權歸原作者所有,此譯文版權歸黑龙江11选5预测网 以及譯者所有。原文出處為微軟官方網站,此段說明文字是本文章不可缺少的一部分,此文首發于西寧威勢電子公司網站,您可以自由轉載,但請保持文章的完整性,并注明出處,否則西寧威勢電子信息服務有限公司有權力追究版權責任。

    譯者的話:

      近年來SQL注入攻擊大行其道,好多大型站點和很多服務器被都這些攻擊放倒了,老鬼本人也對注入攻擊有一些膚淺的了解,但是水平和那些國內外的頂尖大牛們相比還相差甚遠,本來以老鬼的水平是沒有資格發布這樣的文章的,因為老鬼不是專搞安全的,更不是學英語的,一方面技術有限,對原作者的思路理解可能不是很到位,另一方面E文忒菜,翻譯的時候難免會出錯,而發布這篇文章的主要原因是,老鬼加入了好多技術交流群,好多群內寫程序寫了四五年的編程人員,對自己網站的安全沒有一點概念,好多人經常在群里發問:“我看到我的服務器日志中,有人經常掃描我的SQL端口和密碼,我的服務器是不是離掛不遠了?”、“我的數據庫要是放到內網以防黑客攻擊,而WEB服務器在外網,這樣我的網站還能打開嗎?還能正常使用嗎?”由此看來,更多的人對網絡安全是一無所知的,所以老鬼斗膽把以前翻譯的一篇安全文章貼出來,一方面是引導新人,另一方面我是關老爺門前耍大刀,讓高手們指點指點,起個拋磚引玉的作用,以提高我個人對安全方面認識的不足。By the way,我發布這樣的文章,并不代表我的站點亦很安全,請大牛們友情測試我的站點的時候手下留情,點到為止,并將BUG來信告之([email protected]),我更歡大牛們直接加我QQ進行指點和斧正。在翻譯過程中,老鬼對有些拿捏不準的語句,在“[ ]”中給出了原語句,如果翻譯不對,大家請對照原語句理解。

    譯文開始:

數據安全

 

《將SQL注入阻止在發生之前》

 

這篇文章介紹了:

如何SQL注入攻擊網絡

測試SQL注入的漏洞

驗證用戶的輸入

使用.NET特性來阻止攻擊

程序異常處理的重要性

 

文章提到以下知識

ASP。NET C#,SQL

 

[示例代碼下載] SQLInjection.exe (153 KB)

 

內容提綱

好好的SQL語句發生了問題

不給黑客機會 [原:Equal Opportunity Hacks]

所有的輸入都很不安全

避免動態的SQL

用最小的權限執行

優化錯誤信息[原:Failing Gracefully

結論

 

開發者們有了諸如ASP.NET 和強大的數據庫服務,如Microsoft® SQL Server™的先進的服務端技術武裝以后,他們可以很輕松開發出動態的,數據庫驅動的WEB站點.但是功能強大的ASP.NET 和 SQL 卻能夠被黑客通過架設一個“所有通用”[原: all-too-common ]類的攻擊,那就是―――SQL注入攻擊。

最簡單的攻擊思路是這樣的:你創建了一個WEB頁,這個頁允許用戶在輸入框中輸入字符,這個字符可以被引入到數據庫中去經理查詢操作。一個黑客在這個輸入框中輸入了一個畸形SQL 語句,從而改變了原有的查詢,用是它可以被用來插入,改變,或損害后臺數據庫。這怎么可能呢?讓我來舉個例子吧。

 

好語句也不好使了

 

許多ASP.NET程序都使用和下面“代碼段一”一樣的方法來進行用戶身份驗證。

 當用戶單擊了BadLogin.aspx的登錄按鈕時,cmdLogin_Click 方法就會通過運行一個查詢去計算記錄集的數量值,記錄集是在用戶表 Users table 中進行匹配,條件是用戶名字段UserName和密碼字段Password要和用戶輸入的一致,以此來嘗試驗證這個用戶。

 

Figure 1 BadLogin.aspx.cs

以下是引用片段:

private void cmdLogin_Click(object sender, System.EventArgs e) {

    string strCnx =

     "server=localhost;database=northwind;uid=sa;pwd=;";

     SqlConnection cnx = new SqlConnection(strCnx);

 

    cnx.Open();

 

    //This code is susceptible to SQL injection attacks.

    string strQry = "SELECT Count(*) FROM Users WHERE UserName='" +

     txtUser.Text + "' AND Password='" + txtPassword.Text + "'";

    int intRecs;

 

    SqlCommand cmd = new SqlCommand(strQry, cnx);

    intRecs = (int) cmd.ExecuteScalar();

 

    if (intRecs>0) {

        FormsAuthentication.RedirectFromLoginPage(txtUser.Text, false);

    }

    else {

        lblMsg.Text = "Login attempt failed.";

    }

 

    cnx.Close();

}

在多數情況下,程序都會按我們意想的工作。用戶輸入一個用戶名和密碼,然后在USER表中進行比較。此時一個動態的SQL查詢返回了相匹配的行數查詢結果的數量。用戶驗證完成,并轉向到了請求的頁面。而哪些輸入錯誤用戶名和密碼的用戶將會驗證失敗。然而對于一個黑客來說,它可以輸入一個其實并不存在,表面上看上去也無害的下面的字符,在不知道真正用戶名和密碼的情況下訪問系統。

以下是引用片段:
' Or 1=1 --

 

黑客通過注射一個畸形的查詢到SQL語句中從而中斷了系統。這樣之所以能運行是因為給輸入的user連接了一個固定的字符串和值,看下面所示:[翻譯不準,看原文This particular hack works because the executed query is formed by the concatenation of a fixed string and values entered by the user, as shown here:]

以下是引用片段:
string strQry = "SELECT Count(*) FROM Users WHERE UserName='" +
    txtUser.Text + "' AND Password='" + txtPassword.Text + "'";

當用戶輸入一個無效的用戶名‘Paul’ 密碼 ‘Password’ 的時候,strQry變量成為

SELECT Count(*) FROM Users WHERE UserName='Paul' AND Password='password'

但時當黑客輸入

以下是引用片段:
' Or 1=1 --

 

時,語句卻變成了

SELECT Count(*) FROM Users WHERE UserName='' Or 1=1 --' AND Password=''

因為兩個” --” 符號指定了開始查詢的SQL語句,查詢條件變成:

SELECT Count(*) FROM Users WHERE UserName='' Or 1=1

(這里譯得可能不太準,給出源文Because a pair of hyphens designate the beginning of a comment in SQL, the query becomes simply:)

[譯者加:兩個連字符――后面的內容被當做注釋內容被系統忽略了,所以“――”后面的語句等同于無效]

表達式1=1是恒成立的,而這個條件為真的值與任何表達式OR運算,返回結果永遠是真,所以最少有一行返回記錄可以保證,這條查詢經?;岱禱匾桓齜橇愕募鍬技?。

不是所有的SQL 注入攻擊都包括驗證注入的(翻譯不太好,譯者加:也就是說其它情況也會有注入)[原:Not all SQL injection attacks involve forms authentication],一些動態的構造SQL語句和未驗證的輸入都會讓攻擊發生。給出正確的危害發生的限定情況,范圍,或許可以一個攻擊限定到黑客僅有的SQL語言知識或是數據庫情況。

現在我們再考慮“代碼段二”取自于BadProductList.aspx.這個頁面從NORTHWIND DATABASE[譯者加:裝完SQL2000后會自帶這個數據庫] 中顯示產品,并且允許用戶通過一個名為textFilter的textbox來過濾輸出結果。如最后的這個例子,這個頁面可以成功的被SQL注入攻擊,因為執行語句是由用戶輸入的值來動態構建而成的。這個特殊的頁面就成了電腦黑客的天堂,是因為他可以讓這個機敏的黑客劫持機密數據,改變數據庫的的數據,損害數據庫記錄,甚至創建一個新的數據庫帳戶。

 代碼段 2 BadProductList.aspx.cs

以下是引用片段:
private void cmdFilter_Click(object sender, System.EventArgs e) {
    dgrProducts.CurrentPageIndex = 0;
    bindDataGrid();
}
 
private void bindDataGrid() {
    dgrProducts.DataSource = createDataView();
    dgrProducts.DataBind();
}
 
private DataView createDataView()  {
    string strCnx = 
     "server=localhost;uid=sa;pwd=;database=northwind;";
    string strSQL = "SELECT ProductId, ProductName, " +
     "QuantityPerUnit, UnitPrice FROM Products";
 
    //This code is susceptible to SQL injection attacks.
    if (txtFilter.Text.Length > 0) {
        strSQL += " WHERE ProductName LIKE '" + txtFilter.Text + "'";
    }
 
    SqlConnection cnx  = new SqlConnection(strCnx);
    SqlDataAdapter sda = new SqlDataAdapter(strSQL, cnx);
    DataTable dtProducts = new DataTable();
 
    sda.Fill(dtProducts);
 
    return dtProducts.DefaultView;
}

許多SQL-compliant 數據庫,包括SQL SERVER,保存metadata 到一系列的系統表中,有著這樣的名字 sysobjects,syscolumns,sysindexes等。這意味著黑客們通過使用這些系統表來進一步獲得數據庫的大概信息。如,下面的字輸入到texFilter的 textbox中,可能會顯示數據庫中的用戶表

以下是引用片段:
' UNION SELECT id, name, '', 0 FROM sysobjects WHERE xtype ='U' --

 

UNION查詢語句對黑客來說是非常有用的,因為它可以把一個查詢語句附合到另一個查詢語句上去。在這個例子中,黑客把數據庫中的表名附加到最初的產品查詢表上。只有一點不好的是要計算原查詢列的數量和數據類型。最先的查詢可能會顯示一個命名為數據庫中用戶存在的表。第二次的查詢能夠顯示用戶表中的列。用這些信息,黑客可能輸入下面的字符到testbox中:

以下是引用片段:
' UNION SELECT 0, UserName, Password, 0 FROM Users –

 

輸入這個查詢,顯示了用戶表中存在的USERNAME和PASSWORD,像下面顯示的 FIGURE .3的示

Figure 3 Querying the Users Table 

SQL注入攻擊還可以被用來改變數據或損壞數據庫。SQL注入的黑客可能輸入下面的txtFilter 去改變第一個產品的價格從18美元到0.01美元,并且在別人察覺到他的行為之前,迅速的購買這些產品。

'; UPDATE Products SET UnitPrice = 0.01 WHERE ProductId = 1--

黑客能夠得成是因為SQL SERVER充許你把多個SQL語句通過一個分號或空格連成一個。在這個例子中DataGrid什么也不顯示,但是更新語句卻正常的被執行了。利用相同的技術,可能被用來執行一條刪除表的語句,或是執行一條系統存儲擴展,用來創建一個用戶,并加入系統管理員權限組中。這些黑客們都可能用例2中的BadProductList.aspx頁面。

別給黑客機會

我們要了解SQL攻擊不僅僅是局限在SQL SERVER上面,這一點很重要。其它的數據庫,包括Oracle, MySQL, DB2, Sybase等都容易受到這種注入攻擊。SQL注入攻擊能夠得逞是因為SQL語言包含強大的靈活性和有它的的一些特征:

連字符(--),在SQL中表示注釋

能夠把多語句拼起來執行

能夠從標準配置的系統表中進行進數據查詢

 

通常,數據庫都支持一些更為有力的SQL查詢語言,所以SQL SERVER數據庫數據器經常被攻擊,沒必要大驚小怪的。

SQL 注入攻擊不僅是發生在asp.net程序中,其它的如ASP ,JAVA,JSP和PHP中照樣很容易引起攻擊。實際上注入攻擊。實際上,桌面程序也會受到SQL注入攻擊,這一點上它并不見得能好到哪里去。舉例,我已經在下載文件中打包了一個WINDOWS FORMS應用程序,名字為SQLINJECTWINFORM,它同樣可以被SQL注入(在文章頂頭的下載中可以下載到)

雖然可以很容易的指出一個或兩個關鍵的SQL注入防范措施,可是最好我們還是采取分層的方式來解決。如果即便是你的一種方法因為漏洞被黑客繞過了,但是它還是守?;さ?。建議的總結層,如圖4。

 

Principle

Implementation

永遠不要相信用戶的輸入

驗證用戶所輸入的字符,用驗證控件,正則表達式,或代碼等方式

永別使用動態構建語句

使用參數化 parameterized或是存儲過程 stored procedures

永遠不要用ADMIN帳戶去連數據庫

最用低的權限去連接

不要把你的密碼保存的TXT和其它文件中

密碼信息和其它敏感信息都不要保存到一個文件中,另外還要對SQL連接字符串也要進行加密。

最少的出錯提示信息

盡量使用自定義的錯誤信息,在出錯時候不要顯示太多的錯誤信息。將DEBUG設置為假

所有的用戶輸入都是不可靠的

圖4中的第一個原則是非常重要的,假設所有的用戶輸入都非常不可靠!你永遠不要把用戶的輸入信息沒有通過驗證就帶到數據庫中進行查詢。ASP.NET驗證控件,特別是正則表達式驗證控件是一個驗證用戶輸入的好工具.有兩種最簡單的驗證方式:禁止危險字符和允許所需要的字符.雖然你可以很EASY的禁止一些危險字符,如單引號和連字符,但是這樣還不是最佳方法,有兩個原因:第一,你可能在過濾時會漏掉一些對黑客很有用的字符,第二,通常,我們可以用多種方法來表示這個危險字符,來繞過過濾.比如黑客通過escaped一個單引號的方法繞過單引號限制,直接把它帶到數據庫中進行查詢. Escaped的單引號在數據庫中進行查詢時,它和正常的單引號是沒有任何區別的.這樣就逃過了你的代碼驗證.更好的方法是只確實允許的字符.雖然這種方法加大了工作量,但是卻保證了更好的安全性.除了上述的方法外,你還應該限定輸入字符串的最大長度,因為黑客在攻擊的時候,往往會需要輸入大量的字符串.GoodLogin.aspx(在下載中可以找到)包含了兩個正則表達式驗證控件。一個是驗證用戶名的,另一個用來驗證密碼,讓它限定在4-12個由字符、數字和下劃限組成的字符串。

[\d_a-zA-Z]{4,12}

有時候我們可能需要讓客戶輸入一些危險的過濾字符,舉例, person’s name 中的單引號。這種情況下,你可以使用regular expression 或是 String.Replace 方法來將每個單引號替換成兩個單引號。舉例:

string strSanitizedInput = strInput.Replace("'", "''");

注入測試

    從測試的角度來看,我們重要的是要認識到,SQL注入的主要目標是企圖通過改變被發送到SQL服務端查詢的語句來控制SQL服務器。測試此漏洞前,你首先要知道如何利用這個漏洞,然后自己測試下面的方法:

尋找漏洞

   黑客們開始在網站尋找漏洞。這些漏洞可能是任何可以接收輸入,查找,提交表單,或是ASP,JSP,CGI或PHP頁面,它們也包括隱藏域,而并不是局限在顯示在頁面上的域[譯者加:域是指提交表單,輸入框這類]

測試漏洞是否真的存在

為了測試漏洞是否可以成功利用,黑客們最常用的方法是單引號和撇號{apostrophe},[譯者加:apostrophe翻譯出來是撇的意思,其實應該是指分號";",因為分號可以將新的語句跟到前面的語句來執行,即多語句查詢,以此為攻擊。注,SQL SERVER支持多語句查詢,ACCESS不支持]這兩個字符是SQL語句中用來做分隔符之用。如果用戶的輸入沒有通過驗證而直接到達了數據庫進行操作,那么搞定這個數據庫管理系統將變得很簡單。為了測試這樣的漏洞,黑客們可能將 jo'hn 這樣的代碼輸入到一個輸入框中,或是輸入到這樣的一個地址中//www.ymbxx.icu/index.asp?id=jo'hn 。 如果黑客利用的是代碼中隱藏的一個域的話,這點小麻煩對黑客來說沒算什么,它可以把源代碼下載并保存下來,然后修改URL,隱藏字段,再去提交執行。

如果這是一個真正的弱點,撇號后的其他信息,將被視為一提交到SQL服務器的查詢字符串的一部分,將由后端執行。

錯誤描述

如果黑客要找什么,哪么錯誤頁對于黑客來說,將是幫助他們的一個很好的判斷工具,因為錯誤頁提供了黑客想要知道的一些信息。如果一個ODBC的錯誤信息被返回,黑客就確實了,這真的是一個可以利用的漏洞。這些錯誤是由數據庫系統生成的,這也意味著單引號被成功帶入到后臺進行了查詢。

繼續測試

黑客們將繼續嘗試繞過網站的驗證和其它過濾程序,認真的審查每條服務器的響應輸出情況,這些努力包括:

 改變單引號在不同的地方出現,試圖在任何例程中有機可乘。例如,電子郵件域可能會驗證一個@符號和一個句點。如果黑客輸入joe'@www.ymbxx.icu ,這樣將會驗證失敗,但是[email protected]' 將會成功,并發現漏洞。

在字符串最大長度的末尾上加一個單引號。如果網站轉義了單引號,[原:If the site is escaping single quotes, an attempt to escape the single quote could result in truncation back to the single quote.]

使用連字符(破折號)。在SQL中,這意味后是單行注釋,并可能導致服務器忽略該行的其余部份。

使用分號。這個表明后面跟的是一個新的查詢,可以允許這個新查詢在第一條語句后面被執行。

使用高級的unicode字符,它們經常被降級到ASCII “當量”,包括危險的單引號。[原:Using high Unicode characters that are often downgraded to ASCII "equivalents," including the dangerous single quote.]

在所有的字段域中使用這些技術,不光包括字符串域,而且包括任何隱式轉換的地方和僅僅通過UI格式執行的域。

使用#字符。有時你會覺得這是一個日期/時間的分隔符使用。

使用等值的危險字符。

避免動態SQL

我在本文中演示的SQL注入攻擊都是依賴在動態生成的SQL上執行的,即最終SQL語句是通過和用戶輸入的值進行相連接而成的。但是,使用參數化SQL,將會大大降低了黑客注入你代碼的能力。在表5中的代碼,員工employs的參數化SQL阻止了SQL注入的攻擊。如果你必需使用ad hoc SQL(譯者加:高級特性的SQL?是縮寫,大家自己理解),參數化SQL將是很有用的。這可能是必要的,如果你的IT部門不相信存儲過程或使用諸如MYSQL,MYSQL只至5.0才支持存儲過程。無論如何,你應該使用存儲過程來增加 刪除所有基表權限和創建查詢,像表3的示。BetterLogin.aspx,如表6所示,使用了一條存儲過程,procVerifyUser來驗證客戶。[這段譯的不太好,請自己看原文]

 6 BetterLogin.aspx.cs

private void cmdLogin_Click(object sender, System.EventArgs e) {
    string strCnx = 
        ConfigurationSettings.AppSettings["cnxNWindBetter"];
    using (SqlConnection cnx = new SqlConnection(strCnx))
    {
        SqlParameter prm;
 
        cnx.Open();
 
        string strAccessLevel;
 
        SqlCommand cmd = new SqlCommand("procVerifyUser", cnx);
        cmd.CommandType= CommandType.StoredProcedure;
 
        prm = new SqlParameter("@username",SqlDbType.VarChar,50);
        prm.Direction=ParameterDirection.Input;
        prm.Value = txtUser.Text;
        cmd.Parameters.Add(prm);
 
        prm = new SqlParameter("@password",SqlDbType.VarChar,50);
        prm.Direction=ParameterDirection.Input;
        prm.Value = txtPassword.Text;
        cmd.Parameters.Add(prm);            
 
        strAccessLevel = (string) cmd.ExecuteScalar();
 
        if (strAccessLevel.Length>0) {
            FormsAuthentication.RedirectFromLoginPage(txtUser.Text, false);
        }
        else {
            lblMsg.Text = "Login attempt failed.";
        }
    }
}

 5 GoodLogin.aspx.cs

private void cmdLogin_Click(object sender, System.EventArgs e) {
    string strCnx = ConfigurationSettings.AppSettings["cnxNWindBad"];
    using (SqlConnection cnx = new SqlConnection(strCnx))
    {
        SqlParameter prm;
 
        cnx.Open();
 
        string strQry = 
            "SELECT Count(*) FROM Users WHERE [email protected] " +
            "AND [email protected]";
        int intRecs;
 
        SqlCommand cmd = new SqlCommand(strQry, cnx);
        cmd.CommandType= CommandType.Text;
 
        prm = new SqlParameter("@username",SqlDbType.VarChar,50);
        prm.Direction=ParameterDirection.Input;
        prm.Value = txtUser.Text;
        cmd.Parameters.Add(prm);
 
        prm = new SqlParameter("@password",SqlDbType.VarChar,50);
        prm.Direction=ParameterDirection.Input;
        prm.Value = txtPassword.Text;
        cmd.Parameters.Add(prm);            
 
        intRecs = (int) cmd.ExecuteScalar();
 
        if (intRecs>0) {
            FormsAuthentication.RedirectFromLoginPage(txtUser.Text, false);
        }
        else {
            lblMsg.Text = "Login attempt failed.";
        }
    }
}

用最小的權限執行

使用參數化SQL,大大降低了黑客注入你代碼的能力,在Badlogin.aspx 和 BadProductList.aspx中有一個不好的做法就是連接字符串中使用了SA帳戶。下面是連接字符串,你可以在WEB.CONFIG文件中找到它:

<add key="cnxNWindBad"
value="server=localhost;uid=sa;pwd=;database=northwind;" />

 

此帳戶運行于系統管理員的角色,這意思著它將會允許胡作非為,如創建一個登錄,刪除刪除庫這些操作都是小菜一碟。我只是想說明,數據庫應用程序中用SA的方法是一個糟透了的做法。有一個更好的方法就是創建一個受限的用戶來代替SA用戶。GoodLogin.aspx中使用了下面的連接字符串:

<add key="cnxNWindGood"
value="server=localhost;uid=NWindReader;pwd=utbbeesozg4d;
database=northwind;" />

 

NWindReader帳戶運行于db_datareader角色之下,這個角色被限定于只能讀取數據庫中的表。BetterLogin.aspx利用存儲過程和一個登錄改善了效率,WebLimitedUser只擁有執行該存儲過程的權限,而無底層表的權利。

保存密碼的安全

在表3所示的注入攻擊中,導致USERS表中的用戶名和密碼顯示出來。這類表經常被用在窗體身份驗證中,并且許多程序中,用戶名和密碼以明文保存。一個更好的方法是把它們進行加密或哈希存儲在數據庫中。哈希密碼比起加密密碼更安全,因為他們不能被解密。你可以通過添加一個salt(鹽?)(一個加密隨機值)給哈希來強化一個哈希密碼

BestLogin.aspx包含了把用戶輸入和存儲在SecureUsers表(見表7)中被鹽化(salted)哈希版本密碼相比較的代碼。哈希密的另一個是AddSecureUser.aspx頁面。這個頁面是用來得到被鹽化的密碼,把它們存到secureUsers表中。

7 BestLogin.aspx.cs

     private void cmdLogin_Click(object sender, System.EventArgs e) {
    try {
        // Grab the encrypted connection string and decrypt it
        string strCnx = SecureConnection.GetCnxString("cnxNWindBest");
 
        // Establish connection to database
        using (SqlConnection cnx = new SqlConnection(strCnx))
        {
            SqlParameter prm;
 
            cnx.Open();
 
            // Execute sproc to retrieved hashed password for this user
            string strHashedDbPwd;
 
            SqlCommand cmd = new SqlCommand("procGetHashedPassword", cnx);
            cmd.CommandType = CommandType.StoredProcedure;
            prm = new SqlParameter("@username", SqlDbType.VarChar,50);
            prm.Direction = ParameterDirection.Input;
            prm.Value = txtUser.Text;
            cmd.Parameters.Add(prm);
 
            strHashedDbPwd = (string) cmd.ExecuteScalar();
 
            if (strHashedDbPwd.Length>0) {
                // Verify that hashed user-entered password is the same
                // as the hashed password from the database
                if (SaltedHash.ValidatePassword(txtPassword.Text, 
                    strHashedDbPwd)) {
                    FormsAuthentication.RedirectFromLoginPage(
                        txtUser.Text, false);
                }
                else {
                    lblMsg.Text = "Login attempt failed.";
                }
            }
            else {
                lblMsg.Text = "Login attempt failed.";
            }
        }
    }
    catch {
        lblMsg.Text = "Login attempt failed.";
    }
}

 BestLogin.aspx和AddSecureUser.aspx都使用了SaltedHash類庫,如表8所示。這些代碼都是使由JEFF PROSISE使用用

FormsAuthentication.HashPasswordForStoringInConfigFile方法來創建的,它繼續于System.Web.Security 命名空間來創建密碼哈希,和從

System.Security.Cryptography

這個命名空間RNGCryptoServiceProvider.GetNonZeroBytes方法來創建一個隨機16位的鹽化(salt value)值(使用Convert.ToBase64String將之轉換為字符串時它將變成24位)

 8 SaltedHash Class

using System;
using System.Web.Security;
using System.Security.Cryptography;
 
public class SaltedHash {
    static public bool ValidatePassword (string password, 
        string saltedHash) {
 
        // Extract hash and salt string
        const int LEN = 24;
        string saltString = saltedHash.Substring(saltedHash.Length - LEN);
        string hash1 = saltedHash.Substring(0, saltedHash.Length - LEN);
 
        // Append the salt string to the password
        string saltedPassword = password + saltString;
 
        // Hash the salted password
        string hash2 = 
            FormsAuthentication.HashPasswordForStoringInConfigFile(
            saltedPassword, "SHA1");
 
        // Compare the hashes
        return (hash1.CompareTo(hash2) == 0);
    }
 
    static public string CreateSaltedPasswordHash (string password) {
 
        // Generate random salt string
        RNGCryptoServiceProvider csp = new RNGCryptoServiceProvider();
        byte[] saltBytes = new byte[16];
        csp.GetNonZeroBytes(saltBytes);
        string saltString = Convert.ToBase64String(saltBytes);
 
        // Append the salt string to the password
        string saltedPassword = password + saltString;
 
        // Hash the salted password
        string hash = 
            FormsAuthentication.HashPasswordForStoringInConfigFile(
            saltedPassword, "SHA1");
 
        // Append the salt to the hash
        return hash + saltString;
    }
}

雖然沒有直接關系到SQL注入攻擊,但是BestLogin.aspx演示了另一個最安全的做法:加密連接字符串。

確保連接字符串安全是相當重要的,如果它包含了數據庫帳戶密碼,做為一個例子看BestLogin.aspx。既然你需要解密連接字符串來連接數據庫,所以你不能將它哈希加密,實際上你還需要解密。下面是存儲在web.config中的加密后的連接字符串,在BestLogin.aspx頁面中使用方法如下:

<add key="cnxNWindBest"
value="AQAAANCMnd8BFdERjHoAwE/
Cl+sBAAAAcWMZ8XhPz0O8jHcS1539LAQAAAACAAAAAAADZgAAqAAAABAAAABdodw0YhWfcC6+
UjUUOiMwAAAAAASAAACgAAAAEAAAALPzjTRnAPt7/W8v38ikHL5IAAAAzctRyEcHxWkzxeqbq/
V9ogaSqS4UxvKC9zmrXUoJ9mwrNZ/
XZ9LgbfcDXIIAXm2DLRCGRHMtrZrp9yledz0n9kgP3b3s+
X8wFAAAANmLu0UfOJdTc4WjlQQgmZElY7Z8"
/>
BestLogin calls the GetCnxString method from the SecureConnection class, shown in Figure 9, to retrieve the cnxNWindBest AppSetting value and decrypt it with this code:

BestLogin從SecureConnection類中調取GetCnxString方法,如表9所示,以此來檢索和解密cnxNWindBest AppSetting的值。

string strCnx = SecureConnection.GetCnxString("cnxNWindBest");
public class SecureConnection {
    static public string GetCnxString(string configKey) {
        string strCnx;
 
        try {
            // Grab encrypted connection string from web.config
            string strEncryptedCnx = 
                ConfigurationSettings.AppSettings[configKey];
 
            // Decrypt the connection string
            DataProtector dp = new 
                DataProtector(DataProtector.Store.USE_MACHINE_STORE);
            byte[] dataToDecrypt = 
                Convert.FromBase64String(strEncryptedCnx);
            strCnx = 
                Encoding.ASCII.GetString(dp.Decrypt(dataToDecrypt,null));
        }
        catch {
            strCnx="";
        }
 
        return strCnx;
    }
}

 

SecureConnection類回調DataProtect類庫(不在這里顯示,但是可以在下載中找到)它封裝調用了win32的數據?;PI(DPAPI)。對DPAPI的很好特性之一就是它為您管理加密密鑰。關于DataProtect類的更多信息,包括使用它的一些額外的選項,請參閱“構建安全的ASP.NET應用程序:身份驗證,授權和安全通信”微軟模式和實踐指導。

10 EncryptCnxString.aspx 

您可以使用EncryptCnxString.aspx頁面創建計算機特有的加密連接字符串貼到你的配置文件中。這個頁面顯示所表10。當然,除了有連接字符串的密碼和其他機密,您可能要加密或哈希,包括信用卡號碼和其他任何可能造成損害的信息,否則他們可能會被泄露給黑客所知道。ASP.NET2.0包含了一些新特性,它簡化了哈希密碼和對連接字符串的加密。

優化錯誤信息

運行時的異常錯誤處理不當將成為被黑客利用的另一片領域。所以在你的代碼產品中加入異常處理變得非常重要。處理的和未處理的異常信息應該提供最少的對黑客有利的信息。

此文首發于://www.ymbxx.icu/ShowNews/?11-200910271239038948.html 轉載請注明出處

 

未完待續 :[原創]將SQL注入攻擊阻止在發生之前[二]


上一篇:[原創]HI在線客服的一個漏洞
下一篇:本人N年前寫的文章,注入影子鷹
評論列表
正在加載評論……
  
評論   
呢  稱:
驗證碼: 若看不清請點擊更換!
內  容:
 
 
  在線洽談咨詢:
點擊這里,在線洽談   點擊這里,在線洽談   點擊這里,在線洽談
與我交談  與我交談 與我交談
乘車路線    匯款方式   加盟合作  人才招聘  
公司地址:青海省西寧市西關大街73號(三二四部隊招行所四樓)     青ICP備13000578號-1 公安機關備案號:63010402000123    
QQ:147399120    mail:[email protected]    電話: 13897410341    郵編:810000
© Copyright( 2008-2009) www.ymbxx.icu All Rights Reserved    版權所有:西寧威勢電子信息服務有限公司 未經書面制授權,請勿隨意轉載!
業務:青海網站制做、青海網站建設、青海網頁設計、西寧網站制做、西寧網站建設、青海域名注冊、青海網絡推廣、青海網站推廣、青??占渥庥?/a>、黑龙江11选5预测网、黑龙江11选5预测网、網絡安全