Нужно ли использовать `[ValidateAntiForgeryToken] и @Html.AntiForgeryToken()` на всех моих страницах?

Вся моя страница проекта нуждается в аутентификации.. И обычно я не использую [ValidateAntiForgeryToken] and @Html.AntiForgeryToken() на моем контроллере и в представлении.. Только на странице входа есть это.

  • Каковы они [ValidateAntiForgeryToken] and @Html.AntiForgeryToken()??
  • Нужно ли использовать их?
  • Какой cookieless я должен использовать?

Моя часть web.config вроде этого;

<authorization>
  <deny users="?" />
</authorization>
<authentication mode="Forms">
  <forms loginUrl="~/User/Login" timeout="30" cookieless="UseDeviceProfile" name="AbosSMSP" />
</authentication>

Моя ошибка: My error like this

Ответы

Ответ 1

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

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

Входите, есть всевозможные гадости, с которыми они могут справиться, поэтому посмотрите рекомендации OSWAP и посмотрите, есть ли какие-либо другие атаки, к которым вы можете быть уязвимы. http://www.ergon.ch/fileadmin/doc/Airlock_Factsheet_OWASP_en.pdf

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

Мои главные советы по безопасности

  • Antiforgerytoken на странице входа в систему
  • Медленная попытка аутентификации вниз, по крайней мере, на секунду (делает грубую силу нецелесообразной)
  • Внедрить процедуру блокировки учетной записи на n количества недопустимых входов в систему
  • Всегда используйте общее сообщение об ошибке при неудавшихся входах, чтобы хакеры не знали, какая часть входа неверна.
  • Всегда шифруйте свои пароли в db с солью, соль должна быть для пользователя, чтобы предотвратить атаку радуги на украденной базе данных.
  • Всегда убедитесь, что любые данные, отображаемые или извлеченные, действительны для этого пользователя
  • Всегда используйте параметризованный sql
  • Попробуйте и обфускайте идентификаторы, пропущенные в ваших URL-адресах и представлениях, чтобы предотвратить модификацию или попытку прямой ссылочной атаки.

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