Guids, QueryStrings и Аутентификация

Question

У меня есть несколько мест в нескольких приложениях, которые я создал, где страница принимает строку QueryString в следующем формате: http://localhost/MySite.aspx?ID=ab1cbabe-42e2-4d15-ab11-17534b829381

Затем эти страницы будут принимать строку запроса, пытаться ее проанализировать и отобразить данные, которые соответствуют guid, с использованием вызова базы данных со строго типизированными значениями.

Пример:

Guid value;
if (Guid.TryParse(Request.QueryString["ID"], out value))
{
    SomeControl.Datasource = DatabaseCall(value);
    SomeControl.Databind();
}

Что это, очевидно, означает, что любой пользователь (при условии, что у него есть гид для данных) может технически получить доступ к данным любых других пользователей. Очевидно, что предугадать руководство практически невозможно, но я все еще не уверен в этом.

Как все остальные решают эту проблему? Есть ли «правильный» способ? Стоит ли волноваться?

Answer 1

В различных обстоятельствах это абсолютно стоит беспокоиться.

1. Люди, как правило, публикуют или отправляют по электронной почте URI, не убирая строки запроса
2. Большинство браузеров хранят весь URI, включая строку запроса, в истории
3. Большинство браузеров даже предлагают автозаполнение в адресной строке, что позволяет вам пробовать уже посещенные ресурсы
4. HTTP-запрос может быть перехвачен практически в любом месте на пути от клиента к серверу, открывая строку запроса

Я бы порекомендовал какой-нибудь механизм аутентификации на основе пользователей, например, поставщик членства asp.net.

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

Answer 2

Я согласен с @ Laurent.

Но - это зависит от вашего вида бизнеса. Для экстремальных условий, связанных с безопасностью, таких как банковские операции, денежные операции, конфиденциальные личные данные и т. Д., Я бы использовал зашифрованный файл cookie или простой - уникальный ключ, который передается в строке запроса (как вы и просили), но не guid, но что-то гораздо более длинное (просто убедитесь, что его случайность довольно сложно предсказать), а также фоновую задачу на сервере, которая делает недействительными «токены» старше X минут, чтобы снизить риск кражи URL-адресов.

Рассмотрите возможность использования какого-либо стандартного механизма, такого как Членство в ASP.NET .

Answer 3

Вы ответили на свой вопрос: «Очевидно, что прогнозирование руководств почти невозможно»

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