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

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

2 голосов
/ 17 июня 2009

Примечание:

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

Используя Fiddler , я могу воспроизвести произвольный запрос на своей странице по умолчанию после удаления заголовка Authorization из 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. Загрузите страницу в ваш любимый браузер и посмотрите на вкладку «Инспекторы» в Скрипач , вы увидите запрос, похожий на: 

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, как и следовало ожидать.

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

Ответы [ 5 ]

2 голосов
/ 16 июля 2009

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;
 }
2 голосов
/ 15 июля 2009

Редактировать: за обновленный вопрос:

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

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

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

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

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

1 голос
/ 16 июля 2009

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

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

1 голос
/ 13 июля 2009

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

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

1 голос
/ 17 июня 2009

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

или попробовать что-то вроде this или this

...