2009-06-29 73 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 

}