Почему мои страницы ASP.NET возвращают `200 OK` без отправки каких-либо заголовков аутентификации?

StackOverflow https://stackoverflow.com/questions/1008839

Вопрос

Примечание:

  

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

Используя Fiddler , я могу воспроизвести произвольный запрос на странице по умолчанию после стирания моего Заголовок авторизации из HTTP-запроса, и я могу получить ответ 200 OK с действительными данными.

Обновление Баунти

Вот шаги, чтобы воспроизвести это точное поведение:

1. Создать " новый веб-сайт " в ASP.NET не стесняйтесь назвать его «InsecureWebsite»

2. Измените web.config , чтобы запретить всем неаутентифицированным пользователям: 

<authentication mode="Windows" />
  <authorization>
    <deny users="?"/>
  <allow users="*"/>
</authorization>

3. Опубликуйте веб-сайт в произвольном каталоге на сервере DEV и создайте виртуальный каталог для приложения

4. Убедитесь, что у приложения есть доступ к сценариям (.ASP) и включена встроенная проверка подлинности Windows

5. Откройте Fiddler для захвата трафика

6. Загрузите страницу в ваш любимый браузер и посмотрите на " Инспекторы " На вкладке Fiddler вы увидите запрос, аналогичный следующему: 

GET /InsecureWebsite/ HTTP/1.1
Host: dev.subdomain.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Authorization: NTLM
{Base64-encoded authentication data}

Первоначальный запрос к Default.aspx вернет 401 Unauthorized , перейдет к согласованию и, наконец, вернет 200 OK .

В Fiddler я могу стереть заголовок Authorization непосредственно из повторного запроса в Default.aspx и по-прежнему получать 200 OK . Как это возможно?

Решение

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

Снимок экрана параметров Fiddler http://john.cognitivedelay.com/images/fiddler -options.gif

Как только эта опция не будет проверена, любые повторные запросы из Fiddler будут возвращать 401 Unauthorized , как я и ожидал.

Спасибо всем, кто предложил свое время для ответа!

Это было полезно?

Решение

Изменить: за обновленный вопрос:

Вы делаете повтор в самом Fiddler или устанавливаете прямое соединение с веб-сервером? Возможно, Fiddler повторно использует существующее HTTP-соединение (что он может делать в качестве прокси-сервера) ... Я думаю, что IWA может пометить все соединение как аутентифицированное, а не только текущий запрос, что означает, что любые будущие запросы на тот же соединение повторно использует авторизацию и аутентификацию с первого согласования ...

Оригинальный ответ: Попробуйте 

[WebMethod(EnableSession=true)]  
[PrincipalPermission(SecurityAction.Demand, Authenticated=true)]

и посмотрим, поможет ли это?

(Возможно, [PrincipalPermission (SecurityAction.Demand, Role = " myDevRole ")] , если это больше подходит для вас ...)

Другие советы

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

Вы можете получить удостоверение аутентифицированного пользователя, а затем передать его любой подпрограмме управления ролями, сославшись на System.Threading.Thread.CurrentPrincipal.Identity.Name: 

[WebMethod(EnableSession = true)]   
public static string WhoAmI()
{
    // Return the identity of the authenticated windows user.
    Return System.Threading.Thread.CurrentPrincipal.Identity.Name;
 }

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

или вы можете попробовать что-то вроде это или это

Добавьте этот атрибут в веб-метод [PrincipalPermissionAttribute (SecurityAction.Demand, Role = " myDevRole ")] .

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

При использовании аутентификации Windows на вашем локальном компьютере разработки каждый запрос поступает от аутентифицированного пользователя. Таким образом, запретить пользователям = "? & Quot; никогда не будет отклонять запросы локально.

Если вы нажали эту кнопку на удаленном компьютере IIS, на котором вы не проходили проверку подлинности или не использовали проверку подлинности с помощью форм, потребуется проверка подлинности, прежде чем вы сможете успешно запросить либо Default.aspx, либо метод page.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top