2009-06-29 46 views
1

爲了保護Web應用程序不受查詢字符串操作的影響,我正在考慮向每個存儲所有其他查詢字符串參數值&的SHA1哈希的url添加查詢字符串參數,然後在每個請求上針對哈希值進行驗證。通過添加散列來防止查詢字符串操作?

此方法是否可以防止用戶操縱查詢字符串值?這樣做有沒有其他缺點/副作用?

我並不特別關心這個私人網絡應用程序的'醜陋'的網址。由於相同查詢字符串參數的散列值始終相同,所以Url仍然是「可收藏的」。

這是一個ASP.NET應用程序。

+1

爲什麼不使用真正的安全/認證? – tster 2010-10-14 03:13:25

回答

7

我不確定這是否提供任何形式的安全。如果中間人攻擊者想要更改參數,他所要做的就是更改查詢字符串並重新計算SHA-1哈希值並將該請求發送到服務器。

例如,通過瀏覽器發送的網址可能是:

http://www.example.com/addUser.html?parameterA=foo&hash=SHA1(「參數α=富」)

如果攻擊者攔截此,他可以用這種方式編輯:

http://www.example.com/adduser.html?parameterA=bar&hash=SHA1(「parameterA = bar」)

真的,這可以歸結爲你可以信任散列的事實只有參數本身。

你可以修復這個問題的一種方法是,如果用戶有一個只有他和服務器知道的密碼,那麼攻擊者如果改變參數就不可能重新計算哈希值。例如:

http://www.example.com/addUser.html?parameterA=foo&hash=SHA1(「參數α=富」 +「theuserpassword」)

但是,不要把密碼作爲網址:)的參數之一

要注意,這是非常重要的這不是用於驗證雙方之間傳遞的消息的完整性的最新技術。今天使用的是基於哈希的消息認證碼(HMAC)算法的一種形式,其在HMAC中被很好地描述,並且明確地在RFC2104FIPS Pub 198-1中被描述。

+6

您可以簡單地使用哈希的鹽來防止操作/中間人等。 – 2009-09-29 14:39:25

+2

如果您的意思是鹽/ etc/passwd鹽,那麼這些鹽不會提供任何針對mitm攻擊的安全性。鹽通常是公衆所知的,並且僅用於使用蠻力攻擊來反轉哈希更加困難。 'salt'(確實是密鑰散列中的關鍵字)必須是祕密的,以防止攻擊者能夠更改和重新計算摘要。這基本上是一種認證方案,通常需要一些共享的祕密知識。 – 2009-09-30 20:15:19

0

我認爲用所有其他參數的散列添加參數是一個好主意。它從根本上阻止了查詢字符串的操作,但您必須考慮這個問題,即在應用程序的其他頁面中使用這些URL,將這些URL發送給公衆或以任何打印方式使用它們。您需要有一個非常好的方式來訂購,並且如果這些頁面不是動態創建的,或者您只需要手動添加這些網址,就可以專門定製它們。

我沒有看到任何其他問題。有人可能會告訴你可以計算哈希值,但是你可以使用獲得不同哈希值的參數順序來玩,並且很難猜測。

0

這樣做的一個主要問題是,JavaScript將不得不做客戶端SHA計算只是爲了鏈接到頁面,這當然取決於你使用JS多少,但它不應該是不可思議的認爲get參數可能包含pageNo = 1,並且有一個「跳轉到頁面」的輸入框,如果你添加一個散列,這將變得很困難。你可以在會話中(服務器端)存儲任何你不想操縱的東西。

2

我的解決辦法,以防止查詢字符串操作,沒有散:

在Global.asax文件

protected void Application_AuthenticateRequest(Object sender, EventArgs e) 
{ 
    // I take the url referer host. (manipulating the query string this value is null or your local address) 
    string strRefererHost = Request.UrlReferrer == null ? string.Empty : Request.UrlReferrer.Host; 

    // This is the host name of your application 
    string strUrlHost = Request.Url.Host; 

    // I read the query string parameters 
    string strQSPars = Request.Url.Query ?? string.Empty; 

    // If the referer is not the application host (... someone manipulated the qs)... 
    // and there is a query string parameter (be sure of this otherwise nobody can access the default page of your site 
    // because this page has always a local referer...) 
    if (strRefererHost != strUrlHost && strQSPars != string.Empty) 
     Response.Redirect("~/WrongReferer.aspx"); // your error page 

}