Можно ли заставить Page.IsPostBack быть истинным независимо от ASP.net?

Question

Если кто-то проверяет роли пользователя, чтобы определить, могут ли они получить доступ к странице, безопасно ли ставить эту проверку только внутри if (!Page.IsPostBack) { ... }? Может ли клиент вызывать Page.IsPostBack == true независимо от ASP.net; то есть клиент отправляет на страницу и устанавливает правильные поля формы? Если бы это было возможно, то я полагаю, что лучшей практикой было бы проверять безопасность при каждой загрузке страницы, а не только тогда, когда Page.IsPostBack == false.

Answer 1

Легко.И это даже не должно быть через сообщение HTTP.

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

Answer 2

В качестве конкретного примера, предположим, что на вашей странице есть кнопка, которую должны видеть только администраторы, и нажмите:

<asp:Button runat="server" ID="resetButton" Text="Reset" OnClick="resetButton_Click" />

Внутри блока if (!IsPostBack) в выделенном фрагменте кода вы скрываете кнопку, если пользователь не является администратором:

protected override void OnInit(EventArgs e)
{
    if (!IsPostBack)
        resetButton.Visible = IsAdmin();
}

private bool IsAdmin()
{
    ...
}

Вопрос: Может ли не администратор вызвать выполнение кода в resetButton_Click?

Ответ: ДА, даже если состояние просмотра и проверка события включены.

Кто-то может просто перейти на вашу страницу с добавлением ?__VIEWSTATE= или ?__EVENTTARGET= к URL (в результате IsPostBack возвращает true) и затем нажать кнопку.

Вывод: Отключение чувствительных функций в if (!IsPostBack) НЕ безопасно.

Чтобы устранить проблему, снимите флажок IsPostBack или добавьте Visible="False" к разметке кнопки (по умолчанию защищено).

Answer 3

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

Чтобы конкретно ответить на вопрос, если вы не используете ViewState и не устанавливаете значение ViewStateUserKey, которое является уникальным для вашего аутентифицированного пользователя, тогда легко заставить вашу систему думать, что IsPostback верен, когда это не так. Он проверяет поля viewstate и event, и viewstate можно подделать. Даже если он зашифрован с помощью машинного ключа, этого недостаточно, поскольку злоумышленник может сам зайти на страницу, скопировать зашифрованное состояние просмотра и использовать его в своей злонамеренной атаке.

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

* РЕДАКТИРОВАТЬ *

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

Вы, похоже, обеспокоены следующими угрозами:

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

Чтобы смягчить первую угрозу, посмотрите на стандартные готовые компоненты для выполнения аутентификации, такие как FormsAuthenticationModule, который является частью Аутентификации с помощью форм. Эти компоненты встроены в ASP.Net и хорошо разработаны.

Как только пользователь будет должным образом аутентифицирован в вашем приложении, чтобы определить, имеют ли они определенные привилегии, посмотрите на Role Based Authorizaton и RoleManagerModule. Это даст вам возможность связать набор ролей с каждым удостоверением, которое было авторизовано с помощью проверки подлинности с помощью форм.

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

Чтобы обезопасить себя от этого, проще всего использовать значение ViewStateUserKey, о котором я упоминал ранее, и убедиться, что используется либо EnableViewStateMAC, либо ViewStateEncryption. Шифрование является предпочтительным, так как HMAC будет только следить за тем, чтобы злоумышленник не мог вмешаться в состояние просмотра, но его содержимое все еще можно восстановить. Шифрование обеспечивает конфиденциальность и целостность.

Answer 4

Вы бы настроили себя на некоторые неприятные формы атаки, если бы вы не проверяли во всех случаях;Учтите, что злонамеренный пользователь может просто создать HTTP-запрос к вашему серверу со всеми правильными значениями формы, чтобы ASP.NET решил, что это обратная передача.Я настоятельно рекомендую проверять роль пользователя при каждом запросе, обратной передаче или нет.

Answer 5

Извините всех тех, кто уже ответил, но я не согласен с тем, что только проверка авторизации безопасности внутри блока Page.IsPostBack == false обязательно небезопасна (, пока проверка события и зашифрованное состояние просмотра включены на). Я объяснил, почему я думаю, что это здесь , но краткий ответ таков: я не думаю, что вы можете подделать обратную передачу на страницу без предварительной загрузки ее в контексте без обратной передачи, чтобы получить представление состояния и проверку события. поля формы. Возвращенное поле viewstate приведет к тому, что содержимое, которое вы спрятали в вашем блоке Page.IsPostBack == false, останется скрытым в любой обратной передаче, которая использует это viewstate, и, поскольку viewstate зашифровано, оно не может быть подделано.

Answer 6

Абсолютно возможно POST к URL независимо от ASP.Net.Вам даже не нужен браузер.

Вы должны проверить встроенные в ASP.Net функции аутентификации, авторизации и членства, а не пытаться свернуть свои собственные.

Вот хорошее место для начала: http://www.4guysfromrolla.com/articles/120705-1.aspxи http://www.4guysfromrolla.com/articles/031204-1.aspx