Создание AntiForgeryToken посредством внедрения зависимости

Первое правило безопасности: Не пытайтесь перевернуть вашу собственную безопасность

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

Приношу свои извинения, если я полностью неправильно понял ваше описание ...

Во-первых, я полагаю, я должен спросить ... что вы на самом деле имеете в виду под "AntiForgery"? Что вас беспокоит, что вас подделывают? Остальное - это просто общая информация, которая приходит на ум ...

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

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

Вы делаете это через ssl? Во-первых, ssl - это линия защиты номер один для атак человека в середине. Это может быть недостаточно безопасно (и другие могут спорить об этом) для каждой потребности, но если вас беспокоят такие вещи, это отправная точка, если не что иное. Если нет, как убедиться, что вы получаете ответ от нужной машины, а не от посредника, который отвечает первым? Без SSL или его эквивалента ваш токен так же легко украсть, как и все остальное, что вы делаете.

Еще одна вещь, которую следует рассмотреть, - это сделать так, чтобы ваши токены были годны только для одной поездки, а вы генерируете новый обратно клиенту на Следующая поездка. Попытка повторно использовать его не удалась.

Я бы не пытался заменить SSL чем-то другим, созданным вами, если вы так думаете. Однако, если вас беспокоит воспроизведение, создание одноразового токена - один из способов его остановить. Если ты' Если вы беспокоитесь о том, что пользователь дважды отправит одни и те же данные формы, это одно. Я бы также рассмотрел ваш общий дизайн приложения, если вас это беспокоит. Многие повторения и аналогичные сценарии могут быть проиграны с помощью продуманного дизайна вашей бизнес-логики, например, если вы не доверяете клиенту отправлять вам конфиденциальную информацию, например цену товара в корзине.

Также ознакомьтесь с различными руководствами Microsoft по ASP Безопасность .NET и IIS (т. Е. Google ASP.NET или сайт безопасности IIS: microsoft.com) в качестве отправной точки. Многие умные люди уже решили многие вопросы за нас.

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

Также ознакомьтесь с различными руководствами Microsoft по ASP Безопасность .NET и IIS (т. Е. Google ASP.NET или сайт безопасности IIS: microsoft.com) в качестве отправной точки. Многие умные люди уже решили многие вопросы за нас.

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

Также ознакомьтесь с различными руководствами Microsoft по ASP Безопасность .NET и IIS (например, Google ASP.NET или сайт безопасности IIS: microsoft.com) в качестве отправной точки. Многие умные люди уже решили многие вопросы за нас.

все это будет действительным реализация AntiForgery схема?

Насколько я могу судить, похоже, что вы вставляете GUID на страницу, а затем ищете тот же GUID, когда страница возвращается.

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

1. Если GUID существует только на странице, что может помешать пользователю прочитать страницу на одном компьютере и отправить форму с другого? Было бы хорошо связать его с файлом cookie или сеансом (который также использует файл cookie), если вы еще этого не сделали.
2. Если GUID записан на страницу как статический скрытый , тогда форма может быть прочитана и отправлена ​​ботами. Вы можете обойти это, потребовав на странице скрипта для обработки токена перед его отправкой.
3. Вы используете ViewState? Если так, вы можете просто установить ViewStateUserKey на некоторое повторяемое значение, уникальное для каждого клиента; он выполняет функцию, аналогичную той, которую вы описали здесь.

Как сказал Ник, для меня тоже код, который вы дали, выглядит так, как будто вы вставляете GUID на страницу, а затем ищете тот же GUID, когда страница возвращается. Это тоже хорошая идея, когда вы используете структурную карту, сохраняемую в сеансе.

Но есть некоторые встроенные методы, доступные для этой концепции AntiForgery.

Пожалуйста, сначала обратитесь к приведенной ниже ссылке и поймите

http://blog.maartenballiauw.be/post/2008/09/01/ASPNET -MVC-preview-5s-AntiForgeryToken-helper-method-and-attribute.aspx

Теперь,

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

http://msdn.microsoft. com / en-us / library / system.web.mvc.htmlhelper_methods.aspx

http: //blog.codeville.

Мне кажется, что при каждом запросе создается канарейка. Что произойдет, если пользователь откроет несколько вкладок? :)

Проблема с вашим подходом (и реализацией ASP.NET MVC) заключается в том, что его реализация зависит от разработчиков. Такая безопасность должна быть отключена, а не включена. Когда я написал модуль AntiCSRF , я в конечном итоге использовал жизненный цикл страницы ASP.NET, что означает отсутствие изменений в базовом коде, если только разработчик не хотел исключить страницу из проверок CSRF. Вы заметите, что он использует один токен, который действует в течение всего времени существования сеанса браузера этого пользователя - на самом деле нет необходимости изменять токен при каждом запросе.

Теперь я написал модуль в основном как способ проиллюстрировать некоторые концепции для моя предстоящая книга (вставьте сюда рекламу ухмылка ),

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

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

Тем не менее, использование GUID не очень безопасно . Гиды создаются на основе алгоритма, написанного для уникальности, а не случайности. AFAIK существует три действительных алгоритма: на основе имени, на основе времени и случайный. Если алгоритм Guid, используемый системой (который может быть изменен в будущей версии .NET), основан на времени,