Por que minhas páginas ASP.NET retornar `200 OK` sem quaisquer cabeçalhos de autenticação sendo enviados?

Question

Nota:

Esta questão tem um âmbito alargado em de revisões anteriores. Eu tentei simplificar o problema para que ele possa ser facilmente reproduzido por qualquer pessoa.

Usando Fiddler , posso repetir uma solicitação arbitrária à minha página padrão depois de apagar meu cabeçalho Authorization a partir da solicitação HTTP, e eu sou capaz de obter uma resposta de 200 OK com dados válidos.

Recompensa Atualização

Aqui estão os passos para reproduzir este comportamento exato:

1. Criar um "novo site" em ASP.NET, não hesite em nome dele "InsecureWebsite"

2 Editar web.config para negar todos os usuários não autenticados:.

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

3. Publicar o site para um diretório arbitrário no servidor DEV e criar um diretório virtual para o aplicativo

4. Verifique se o aplicativo tem acesso roteiro (.asp) e autenticação integrada do Windows habilitado

5. Open Fiddler para capturar o tráfego

6. Carregue a página no seu navegador favorito e olhar para o guia "inspectores" dentro de Fiddler , você verá um pedido semelhante a:

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}

O pedido inicial para Default.aspx retornará um 401 Unauthorized, vai entrar em negociação, e, finalmente, voltar a 200 OK.

Em Fiddler então eu posso apagar o cabeçalho Authorization diretamente de um pedido repetido para Default.aspx e ainda obter uma 200 OK. Como isso é possível?

Solução

Acontece que Fiddler usa a mesma conexão subjacente ao fazer os pedidos, por isso, uma vez que a conexão é autenticado, qualquer pedido na mesma conexão também será autenticado como o mesmo usuário como o pedido inicial. Você pode desativar esse recurso em Fiddler aqui:

tela de opções de violinista http://john.cognitivedelay.com/images/fiddler -options.gif

Uma vez que este tem sido desmarcada, todos os pedidos repetidos de dentro Fiddler irá retornar uma 401 Unauthorized como seria de esperar.

Obrigado a todos que ofereceram seu tempo para responder!

Answer 1

Edit: por questão actualização:

Você está fazendo o replay em si Fiddler, ou fazendo uma conexão direta com o servidor web? Pode ser que Fiddler é reutilizar uma conexão HTTP existente (que ele pode fazer, como um proxy) ... Eu acho IWA pode marcar toda a connnection como autenticado, e não apenas a solicitação atual, o que significa que quaisquer futuros pedidos sobre o mesmo conexão re-utilizar a autorização e autenticação da primeira negociação ...

resposta Original: Tentar

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

e ver se isso ajuda?

(Possivelmente [PrincipalPermission(SecurityAction.Demand, Role="myDevRole")] se que é mais adequado para você ...)

Answer 2

chamada

O Ajax é feito em um novo segmento para uma sessão autenticada existente, é por isso que você não vê qualquer informação de autenticação nos cabeçalhos. A sessão já está autenticado.

Você pode obter a identidade do usuário autenticado e, em seguida, passar isso para quaisquer rotinas de gerenciamento de papel, fazendo referência 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;
 }

Answer 3

Você poderia potencialmente adicionar informações de autenticação para o cabeçalho da mensagem e, em seguida autenticar-se no webmethod.

ou você poderia tentar algo como este ou este

Answer 4

Adicione este atributo para o método web [PrincipalPermissionAttribute( SecurityAction.Demand, Role = "myDevRole" )].

Em seguida, no evento Global.asax Application_AuthenticateRequest você pode ter certeza que o usuário thread atual é autenticado corretamente -. Ou seja, fazer o que é necessário biscoitos fraude evitar ou sessões

Answer 5

Usando a autenticação do Windows na máquina de desenvolvimento local, cada pedido vai ser a partir de um usuário autenticado. Assim, negar users = "?" nunca vai negar quaisquer pedidos localmente.

Se você estava batendo isso em uma remota IIS máquina que não são autenticados com ou fosse usar autenticação de formulários, seria exigir autenticação antes que você poderia com sucesso solicitar tanto Default.aspx ou o método página.