Безопасная реализация Page.IsPostBack?

Question

После моего предыдущего вопроса о том, является ли безопасная реализация Page.IsPostBack ASP.net по умолчанию (это не так; ее можно подделать ... глагол HTTP даже не должен быть POST!) , Я думал; наверняка должен быть лучший способ реализовать это? Можем ли мы придумать реализацию Page.IsPostBack, которая, когда она истинна, почти гарантированно указывает на то, что страница является реальной обратной передачей ASP.net? Это важно, если кто-то хочет выполнить проверку безопасности только один раз (например, будет ли отображаться какой-либо контент, основываясь на роли (ях) пользователя), и хочет сделать это только в том случае, если мы НЕ имеем дело с обратной передачей ASP.net. .

Мои первые мысли о том, как это сделать, - реализовать проверочный код в свойстве, чтобы я мог написать что-то вроде этого внутри Page_Load:

if (!_isPostBack)
{
    // Do security check
    if (userIsNotAuthorized)
    {
        btnViewReports.Visible = false;
        btnEditDetails.Visible = false;
        // etc.
    }
}

Есть ли способ безопасно реализовать _isPostBack? Возможно, хранить что-то во ViewState, что было бы сложно или невозможно сделать подделкой постбэка? Случайная строка?

Answer 1

Пару лет назад у меня был проект, в котором было проведено тестирование на проникновение кода.Они отметили тот факт, что по умолчанию IsPostback не проверяет глагол http.Чтобы решить эту проблему, я создал абстрактный класс Page с собственной реализацией IsPostback, которая скрывает имплементацию по умолчанию:

Public Class ProjectPage : System.Web.UI.Page

    public new bool IsPostBack()
    {
        return (Page.IsPostBack && Request.HttpMethod.ToUpper() == "POST");
    }

End Class

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

Answer 2

ОК, вот что я считаю решением: Page.IsPostBack уже достаточно достаточно безопасно, если включена проверка событий.Позвольте мне объяснить мои рассуждения ниже, и я буду рад, если кто-нибудь добавит комментарий, если я что-то не так сделал.

Для того, чтобы фальшбэк постбека был опубликован на ASP.net и активировал элемент управления OnClick событие, с включенной проверкой события, клиент должен отправить поле формы __EVENTVALIDATION.Это поле содержит уникально сгенерированную строку, которая, в основном, сообщает ASP.net, который управляет событием обратной передачи для этой страницы.Если вы попытаетесь подменить постбэк для кнопки, для которой установлена ​​.Visibility = false, вы увидите сообщение об ошибке проверки события.Таким образом, похоже, что вы не можете напрямую подделать щелчок на скрытом элементе управления.

Как насчет подмены постбэка одной из существующих кнопок на странице, которую вы обработали (т.е. у вас есть разрешение на просмотр / клик по нему)?Ну, вы можете отправить постбэк на страницу, но вам нужно отправить действительный __VIEWSTATE, или вы просто получите ошибку «информация о состоянии неверна».Для того, чтобы иметь действительный __VIEWSTATE, вам уже нужно было загрузить страницу как без обратной передачи, верно?Это означает, что код проверки безопасности будет выполнен хотя бы один раз, скрывая соответствующие элементы управления и записывая его в __VIEWSTATE.Таким образом, когда вы публикуете постфок-постбек, да, это приведет к тому, что Page.IsPostBack будет иметь значение true, но это не имеет значения, потому что отправленный __VIEWSTATE уже будет сгенерирован при предыдущей загрузке страницы без обратной передачи, чтобы скрыть содержимоеу вас не должно быть доступа к ... так что вы можете подделать обратную передачу, но только передав __VIEWSTATE, который был ранее сгенерирован при загрузке страницы без обратной передачи.

Итак, из-за этихНа самом деле, должно быть безопасно размещать код проверки безопасности только внутри блока Page.IsPostBack == false.Это всегда должно выполняться один раз, прежде чем на сервер ASP.net может быть отправлена ​​допустимая обратная передача.Или я что-то упустил?

Answer 3

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

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

Если файлы cookie запрещеныВы можете отправить токен как часть URL-адреса, если позволяет FormSauth, или как поле формы в вашей обратной передаче.Но это больше, чем управлять файлами cookie, ИМХО, как только вы столкнулись с проблемой создания правильного токена.