Безопасность со значениями QueryString в Asp.net MVC

Question

Как правильно убедиться, что пользователь не вмешивается в значения строки запроса или значения URL действия? Например, у вас может быть действие Delete Comment на вашем CommentController, которое принимает CommentID. URL действия может выглядеть так: / Комментарии / Удалить / 3, чтобы удалить комментарий с идентификатором 3.

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

Делаете ли вы несколько вызовов базы данных, чтобы получить комментарий и убедиться, что автор комментария соответствует пользователю, вызывающему действие удаления?

Вместо этого вы передаете CommentID и UserID хранимой процедуре, которая выполняет удаление, и делает Delete, где UserID и CommentID равны переданным значениям?

Лучше ли шифровать значения строки запроса?

Answer 1

Вы не.

Кардинальное правило программирования, особенно в наши дни, заключается в том, что вы никогда не доверяете никаким данным, исходящим от пользователя, браузера, клиента и т. Д.

Это также основное правило программирования, что вы, вероятно, не должны пытаться реализовать шифрование и безопасность самостоятельно, если вы действительно не знаете, что делаете. И даже если вы знаете, что делаете, вы останетесь на шаг впереди от взломщиков. Умные все еще будут смеяться над тобой.

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

Answer 2

Шифрование и дешифрование параметров запроса - тривиальный процесс, и здесь есть несколько замечательных примеров того, как сделать это с помощью HttpModule в StackOverflow.

«Вы не делаете», «Вы не можете» или «Это не просто» - это просто неприемлемые ответы в наши дни и в возрасте ...

Answer 3

Vyrotek: метод ввода не важен. GET, POST, зашифрованный / запутанный GET - никакой разницы нет. Независимо от того, каким образом ваше приложение получает команды, для выполнения административных действий оно должно убедиться, что выдающему пользователю разрешено делать то, что он хочет. Проверка прав доступа должна выполняться ПОСЛЕ получения команды и ДО ее выполнения. В противном случае это совсем не безопасность.

Answer 4

Рассмотрите возможность использования техники, описанной в статье Стивена Вальтера. Совет № 46. Не используйте удаление ссылок, поскольку они создают дыры безопасности , в которых используется [AcceptVerbs (HttpVerbs.Delete)] *

Answer 5

Вы также можете разрешить только отправлять запросы на удаление действия контроллера, используя атрибут Accept Verbs, как показано ниже.

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Delete(int? id)
{
    //Delete
}

Тогда вы также можете использовать токен защиты от подделки, как описано здесь:

http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Answer 6

Вы не можете легко сделать это.

У меня приятные воспоминания о сайте, который использовал URL-адреса действий для удаления.

Все было хорошо до тех пор, пока они не начали поиск, просматривая интранет.

Упс, до свидания данные.

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

Answer 7

Я сделал забавные вещи, взяв строку запроса, сжав ее, Base64 или просто закодировав ее в шестнадцатеричном виде, так что "commentid = 4 & userid = 12345" становится "code = 1a2b23de12769"

Это в основном «Безопасность через неизвестность», но она делает большую работу для того, кто пытается взломать сайт.