¿Por qué mis páginas ASP.NET devuelven '200 OK' sin enviar ningún encabezado de autenticación?

Question

Nota:

  

Esta pregunta ha ampliado su alcance de las revisiones anteriores. He intentado simplificar el problema para que cualquiera pueda reproducirlo fácilmente.

Utilizando Fiddler , puedo reproducir una solicitud arbitraria en mi página predeterminada después de borrar mi Autorización del encabezado de la solicitud HTTP, y puedo obtener una respuesta de 200 OK con datos válidos.

Actualización de recompensas

Estos son los pasos para reproducir este comportamiento exacto:

1. Crear un " Nuevo sitio web " en ASP.NET, siéntase libre de nombrarlo "InsecureWebsite"

2. Edite web.config para denegar a todos los usuarios no autenticados:

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

3. Publique el sitio web en un directorio arbitrario en un servidor DEV y cree un directorio virtual para la aplicación

4. Asegúrese de que la aplicación tenga acceso de script (.ASP) y autenticación de Windows integrada habilitada

5. Abra Fiddler para capturar el tráfico

6. Cargue la página en su navegador favorito y mire los " Inspectores " pestaña dentro de Fiddler , verá una solicitud similar 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}

La solicitud inicial de Default.aspx devolverá un 401 no autorizado , entrará en negociación y finalmente devolverá un 200 OK .

En Fiddler puedo borrar el encabezado Authorization directamente de una solicitud repetida a Default.aspx y aún así obtener un 200 OK . ¿Cómo es eso posible?

Solución

Resulta que Fiddler usa la misma conexión subyacente cuando realiza las solicitudes, por lo que una vez que la conexión se autentica, cualquier solicitud en la misma conexión también se autenticará como el mismo usuario que la solicitud inicial. Puede desactivar esta función en Fiddler aquí:

Captura de pantalla de las opciones de Fiddler http://john.cognitivedelay.com/images/fiddler -options.gif

Una vez que esto se haya desmarcado, cualquier solicitud reproducida desde Fiddler devolverá un 401 no autorizado como era de esperar.

¡Gracias a todos los que ofrecieron su tiempo para responder!

Answer 1

Editar: por pregunta actualizada:

¿Estás haciendo la repetición en el propio Fiddler o estableciendo una conexión directa con el servidor web? Puede ser que Fiddler esté reutilizando una conexión HTTP existente (que puede hacer, como proxy) ... Creo que IWA podría marcar toda la conexión como autenticada, no solo la solicitud actual, lo que significa que cualquier solicitud futura sobre el mismo la conexión reutiliza la autorización y la autenticación desde la primera negociación ...

Respuesta original: Probar

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

y ver si eso ayuda?

(Posiblemente [PrincipalPermission (SecurityAction.Demand, Role = " myDevRole ")] si es más apropiado para usted ...)

Answer 2

La llamada Ajax se realiza en un nuevo subproceso para una sesión autenticada existente. Es por eso que no ve ninguna información de autenticación en los encabezados. La sesión ya está autenticada.

Puede obtener la identidad del usuario autenticado y luego transmitirla a cualquier rutina de administración de roles, haciendo referencia a 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

Podría agregar información de autenticación al encabezado del mensaje y luego autenticarse en el método web.

o podría intentar algo como this o this

Answer 4

Agregue este atributo al método web [PrincipalPermissionAttribute (SecurityAction.Demand, Role = " myDevRole ")] .

Luego, en el evento Global.asax Application_AuthenticateRequest puede asegurarse de que el usuario actual del hilo esté autenticado correctamente, es decir, haga lo necesario para evitar cookies o sesiones fraudulentas.

Answer 5

Usando la autenticación de Windows en su máquina de desarrollo local, cada solicitud será de un usuario autenticado. Entonces, denegar usuarios = "? & Quot; nunca negará ninguna solicitud localmente.

Si estaba accediendo a esto en una máquina IIS remota con la que no está autenticado o estaba utilizando la autenticación de formularios, requeriría autenticación antes de poder solicitar con éxito Default.aspx o el método de página.