Защита от CSRF-атак в веб-формах ASP.NET без главных страниц

Я проверяю безопасность веб-сайта ASP.NET, которому около 7 лет. Во время создания сайта руководство Microsoft заключалось в том, чтобы добавить следующее на общую базовую страницу (унаследованную всеми кодовыми страницами):

Protected Overrides Sub OnInit(ByVal e As System.EventArgs)
    MyBase.OnInit(e)

    If Request.IsSecureConnection = True Then
        ViewStateUserKey = Session.SessionID
    End If
End Sub

Этот совет взят из следующей статьи MSDN из 2005.

Мой вопрос в том, является ли это все еще действительным и эффективным методом защиты от атак CSRF.

Обратите внимание, я прочитал вопрос SO об этой теме, но, похоже, автоматически сгенерированная защита проекта Visual Studio 2012+ для CSRF добавляется на главные страницы. Сайт, который я просматриваю, не использует главные страницы из-за конфликтов CSS, и добавление главных страниц в текущее обновление не входит в его задачи.


asp.net webforms vb.net csrf
person Josh    schedule 26.06.2016    source источник
comment
Как вышеуказанная функция предотвращает CSRF?   -  person Legends    schedule 27.06.2016

Ответы (1)


arrow_upward
1
arrow_downward

Да, это смягчит CSRF, если включен ViewStateMac.

Это связано с тем, что каждый отдельный пользователь будет иметь ViewState, аутентифицированный своим собственным ключом (который является идентификатором сеанса).

Поскольку ViewState отправляется обратно на сервер при каждом запросе с побочными эффектами, ASP.NET проверяет, действительно ли значение ViewState получено от текущего пользователя.

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

Обратите внимание, что вышеприведенное предполагает, что все запросы с побочными эффектами выполняются через обратные передачи. То есть приложение следует RFC 7231 в отношении определения "безопасный". методы и нет других обработчиков запросов POST, кроме механизма обратной передачи.

Обратите внимание, что любые пользовательские запросы AJAX в приложении, такие как сделанные JQuery, не будут защищены от CSRF, поскольку они не реализованы как обратные передачи.

Для них рекомендуется установить и проверить собственный заголовок, например X-Requested-With. Обратите внимание, что из-за различных уязвимостей Flash вы также можете передать токен в заголовок для проверки на стороне сервера.

person SilverlightFox    schedule 27.06.2016