Предотвратить манипулирование строк запроса, добавив хэш?

Question

Чтобы защитить веб-приложение от манипуляции со строкой запроса, я рассматривал возможность добавления параметра строки запроса к каждому URL-адресу, в котором хранится хэш SHA1 всех других параметров и значений строки запроса, а затем проверки по хешу при каждом запросе. *

Обеспечивает ли этот метод надежную защиту от пользовательских манипуляций со значениями строки запроса? Есть ли другие недостатки / побочные эффекты для этого?

Меня не особо беспокоят "уродливые" URL для этого частного веб-приложения. URL-адреса по-прежнему будут «закладками», поскольку хэш всегда будет одинаковым для одинаковых аргументов строки запроса.

Это приложение ASP.NET.

Answer 1

Я не уверен, что это обеспечивает какую-либо безопасность. Если злоумышленник в середине хочет изменить параметры, все, что он должен сделать, это изменить строку запроса, пересчитать хэш SHA-1 и отправить этот запрос на сервер.

Например, URL, отправленный браузером, может быть:

http://www.example.com/addUser.html?parameterA=foo&hash=SHA1("parameterA=foo")

Если злоумышленник перехватит это, он может отредактировать его следующим образом:

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

Действительно, это сводится к тому, что вы можете доверять хешу только столько, сколько самим параметрам.

Один из способов исправить это было бы, если бы у пользователя был пароль, который известен только им и серверу, тогда злоумышленник не сможет пересчитать хэш, если они изменят параметры. Например:

http://www.example.com/addUser.html?parameterA=foo&hash=SHA1("parameterA=foo"+"theuserpassword")

Но не указывайте пароль в качестве одного из параметров в URL:)

Важно отметить, что это не современный уровень для проверки целостности сообщений, передаваемых между двумя сторонами. Сегодня используется форма алгоритма кода аутентификации сообщений (HMAC) на основе хеша, которая довольно хорошо описана в HMAC и, безусловно, в RFC2104 и FIPS Pub 198-1 .

Answer 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

}

Answer 3

Вы можете рассмотреть возможность использования этой маленькой библиотеки с открытым исходным кодом:

http://www.codeproject.com/KB/aspnet/Univar.aspx

Он использует уникальный ключ для каждого клиентского компьютера и поставляется со многими другими вкусностями.

Answer 4

Одна из основных проблем заключается в том, что javascript должен будет выполнять вычисления SHA на стороне клиента, чтобы просто ссылаться на страницы, это, конечно, зависит от того, насколько вы используете JS, но не стоит думать, что аргумент get может include pageNo = 1, и для поля ввода «Перейти к странице» это будет затруднено, если вы добавите хеш. Вы можете хранить в сеансе (на стороне сервера) все, чем вы действительно не хотите манипулировать.

Answer 5

Я считаю хорошей идеей добавить параметр с хешем всех остальных параметров. Это радикально предотвращает манипулирование строкой запросов, но вам нужно подумать о проблеме, которая означает использование этих URL-адресов на других страницах вашего приложения, отправку этих URL-адресов для общего доступа или использование их любым печатным способом. Вы должны иметь очень хороший способ заказа и иметь их под рукой, особенно, если эти страницы не создаются динамически, или если вам просто нужно добавить эти URL вручную.

Я не вижу в этом никакой другой проблемы. Кто-то может сказать вам, что хеш можно вычислить, но вы можете играть с порядком параметров, получая разные хэши и делая очень трудным угадывание.