Implementar una solución de inicio de sesión único mediante autenticación básica y el cliente de Internet Explorer


Resumen


Cuando instala la actualización de seguridad en el boletín de seguridad de Microsoft MS04-004 en su equipo, pueden romper algunas de las aplicaciones Web que pasan las credenciales a través de una dirección URL. En este artículo se describe varios métodos para evitar este problema y se explica las limitaciones de cada método.

INTRODUCCIÓN


Este artículo describe cómo pasar las credenciales del usuario a través de la dirección URL para Single Sign-On (SSO) mediante autenticación básica. Cuando instala la actualización de seguridad en el boletín de seguridad de Microsoft MS04-004, no puede pasar las credenciales a través de la dirección URL.

Más información


Problema con el boletín de seguridad de Microsoft MS04-004

Boletín de seguridad de Microsoft MS04-004 proporciona una actualización de seguridad para Microsoft Internet Explorer y un componente de dependencia que se denomina WinInet. Actualización de seguridad MS04-004 cumple con la sección 3.2.2 de Request for Comments (RFC) 2616 y sección 3.3 de RFC 1738. Ambas secciones de estos RFC indicar que las direcciones URL HTTP debe tener sólo el formato siguiente:
http://host:port/path?querystring
Nota: host, puertoy ruta de acceso son marcadores de posición para el nombre de host, el número de puerto y la ubicación de la página Web solicitada en el servidor, respectivamente. cadena de consulta es un marcador de posición para los parámetros de la cadena de consulta que se debe pasar al servidor.

Boletín de seguridad MS04-004 incluye una actualización que evita un problema determinado de suplantación de dirección URL. Suplantación de identidad es la práctica de engañar a los usuarios para proporcionar contraseñas y otra información para permitir el acceso no autorizado a un sistema. En este escenario, los usuarios se engaña pensando que están explorando un sitio Web determinado, cuando en realidad se examina un sitio Web diferente. Actualización de seguridad MS04-004 impide que la dirección URL de problema de la suplantación. Sin embargo, después de aplicar la actualización de seguridad MS04-004, pueden interrumpir algunas aplicaciones Web. Las aplicaciones Web que se ven afectadas se basan en la característica que pasa las credenciales a través de la dirección URL

Nota: Debido a que las credenciales de autenticación básica se pasan a través de la red en texto sin cifrar para cada solicitud que se envía desde el cliente Web en el servidor Web, limitar el uso de la autenticación básica. Utilizar la autenticación básica sólo cuando no hay otros métodos de autenticación disponibles. Asimismo, puede utilizar la autenticación básica junto con cifrado como SSL/TLS.

Microsoft está de acuerdo con la siguiente advertencia en la que se proporciona en la sección 7 de RFC 2396:
Es imprudente claramente a utilizar una dirección URL que contiene una contraseña que pretende ser secreta. En particular, el uso de una contraseña dentro del componente 'userinfo' de una dirección URL es disrecommended fuertemente excepto en esos casos raros donde el parámetro de 'contraseña' pretende ser público.
Microsoft recomienda que implemente soluciones SSO basado en la autenticación básica. Sin embargo, este artículo contiene varios métodos que puede utilizar para evitar el comportamiento que se produce después de aplicar la actualización de seguridad MS04-004. Cuando se utiliza este método, los sistemas anteriores que implementan basados en autenticación SSO soluciones trabajo básico como lo hacían antes de instalar la actualización de seguridad MS04-004.

Para obtener información adicional acerca del boletín de seguridad de Microsoft MS04-004, visite el siguiente sitio Web de Microsoft:

Implementación de SSO

Los pasos siguientes ilustran la implementación de una solución SSO mediante la autenticación básica.

Nota: Este escenario funciona antes de instalar la actualización de seguridad MS04-004.
  1. Solicita un cliente Web PageOfInterest.asp desde
    ServerA.

    Nota: PageOfInterest.aspy ServerA son marcadores de posición para el nombre de la página solicitada y el nombre del servidor donde se almacena la página solicitada, respectivamente.
  2. ServerA responde al cliente Web con el mensaje la indica al cliente Web para recuperar
    PageOfInterest.asp desde la ubicación siguiente:
    http://sbUsername:sbPassword@ServerB/SomePath/PageOfInterest.asp
    Esta instrucción es cualquiera enviados en el encabezado de ubicación de una respuesta HTTP con código de estado = 302, o enviarlo como una etiqueta "meta actualizar" en el cuerpo de una respuesta HTTP con código de estado = 200.

    Nota: sbUsername, sbPassword, ServerBy SomePath son marcadores de posición para el nombre de usuario, la contraseña, el nombre del servidor donde se almacena la página solicitada y ubicación de la página Web solicitada en el servidor, respectivamente. Modificar estos valores de acuerdo con su entorno.
  3. Las solicitudes de cliente de Web
    PageOfInterest.asp de
    Servidor by, a continuación, proporciona las credenciales cuando se enfrenta.
Cuando Internet Explorer canoniza una dirección URL antes de instalar la actualización de seguridad MS04-004, WinInet guarda las credenciales que encuentran entre las secciones de protocolo y de host de la dirección URL para su uso posterior en la comunicación entre el cliente Web y el servidor Web. WinInet es el componente que Internet Explorer utiliza para comunicarse a través de TCP/IP. Si una solicitud posterior en el mismo territorio de autenticación básica devuelve WWW-Authenticate: encabezado de respuesta básico, WinInet utiliza una autorización tienen un formato correcto: encabezado de solicitud básica para emitir otra solicitud al servidor Web que incluya las credenciales que se guardaron durante la canonización. Cuando se guardan las credenciales, el cliente Web puede autenticar al servidor Web y no se solicita al usuario las credenciales.

Ejemplo de secuencia

El siguiente es un ejemplo de los datos HTTP que se intercambian entre un cliente de Internet Explorer y un equipo servidor que está ejecutando Microsoft Internet Information Services (IIS) en una secuencia típica de autenticación básica.

Nota: Mediante la utilidad WFetch se recolectó esta muestra. Los caracteres \r\n representan los caracteres hexadecimales 0D 0A o el carácter ASCII CRLF. Para obtener información adicional acerca de la utilidad WFetch, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

284285 cómo usar Wfetch.exe para solucionar problemas de las conexiones HTTP

  1. El explorador emite una solicitud anónima al servidor Web.
    GET /SomePath/PageOfInterest.aspx HTTP/1.1\r\nHost: ServerB\r\n
    Accept: */*\r\n
    \r\n

  2. El servidor Web responde al cliente Web que se ha denegado el acceso, y que el recurso solicitado requiere credenciales de autenticación básica.
    HTTP/1.1 401 Access Denied\r\nContent-Length: 4431\r\n
    Content-Type: text/html\r\n
    Server: Microsoft-IIS/6.0\r\n
    WWW-Authenticate: Basic realm="ServerB"\r\n
    X-Powered-By: ASP.NET\r\n
    Date: Mon, 16 Feb 2004 00:38:11 GMT\r\n
    \r\n
    [ *** HTTP MESSAGE-BODY REMOVED FOR BREVITY *** ]
    \r\n

  3. El explorador vuelve a emite la misma solicitud que envió en el paso 1. Sin embargo, esta vez el explorador inserta la autorización: encabezado básico que incluye las credenciales del usuario.
    GET /SomePath/PageOfInterest.aspx HTTP/1.1\r\nHost: ServerB\r\n
    Accept: */*\r\n
    Authorization: Basic TG9jYWxVc2VyOkxvY2FsUGFzc3dvcmQ=\r\n
    \r\n

  4. Las credenciales son válidas y el usuario tiene permiso de acceso al recurso solicitado. Por lo tanto, se devuelven los datos que se solicita al usuario.
    HTTP/1.1 200 OK\r\nDate: Mon, 16 Feb 2004 00:40:37 GMT\r\n\
    Server: Microsoft-IIS/6.0\r\n
    X-Powered-By: ASP.NET\r\n
    X-AspNet-Version: 1.1.4322\r\n
    Set-Cookie: ASP.NET_SessionId=zzseaci1a4tyhrymokckmau2; path=/\r\n
    Cache-control: private\r\n
    Content-Type: text/html\r\n
    Content-Length: 44\r\n
    \r\n
    [ *** HTTP MESSAGE-BODY REMOVED FOR BREVITY *** ]
    \r\n

El significado de este ejemplo de comunicación es demostrar que en una secuencia típica de autenticación básica, el cliente Web primero intentará comunicarse mediante autenticación anónima (es decir, sin autorización: se envía el encabezado de solicitud básica). El servidor responde con una respuesta que contiene un código de estado 401 Acceso denegado y WWW-Authenticate: encabezado de respuesta básico. Normalmente, entre los pasos 2 y 3, el explorador muestra al usuario un cuadro de diálogo que pide al usuario que escriba las credenciales en respuesta a la autenticación del servidor: desafío básico. Sin embargo, por RFC 2617, la mayoría de los exploradores (como Internet Explorer) proporciona la autorización: encabezado básico si el usuario ya ha proporcionado las credenciales de autenticación básica para el territorio especificado. Después de instalar la actualización de seguridad MS04-004, Internet Explorer descarta las credenciales que se pasan a través de la dirección URL y WinInet ya no tiene las credenciales para reenviar automáticamente. Por lo tanto, el usuario recibe un cuadro de diálogo que solicita al usuario las credenciales de autenticación básica.

Solución alternativa


Para evitar este problema, utilice uno de los métodos siguientes. El enfoque propuesto en esta sección hace referencia a tres hosts: ServerA,
Servidor by el cliente Web. Donde servidor es el nombre de la página solicitada y b es el nombre del servidor donde se almacena la página solicitada.

Nota: Debido a los cambios que se realizan en la actualización de seguridad MS04-004 se aplican sólo a las versiones de Microsoft Windows de Internet Explorer, se supone que el cliente Web es una versión de Internet Explorer que se ha actualizado con la actualización de seguridad MS04-004.

Puede descargar los ejemplos de código de las distintas soluciones que se sugieren en este artículo. El archivo siguiente está disponible para su descarga desde Microsoft Download Center:
Download Descargar ahora el paquete de ejemplos de código. Para obtener información adicional acerca de cómo descargar archivos de Microsoft Support, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
119591 cómo obtener archivos de soporte técnico de Microsoft desde los servicios en línea
Microsoft analizó este archivo en busca de virus. Microsoft ha utilizado el software de detección de virus más reciente que estaba disponible en la fecha en que se publicó el archivo. El archivo se almacena en servidores seguros que ayudan a impedir cambios no autorizados en el archivo.

Método 1: Utilizar el objeto XMLHTTP

Utilice el objeto XMLHTTP para realizar una solicitud intermedia en la secuencia de comandos de cliente que se ejecuta en el cliente Web, en lugar de depender de Internet Explorer para redirigir automáticamente cuando recibe la respuesta de 302 (redirección) desde el servidor. El objeto XMLHTTP expone varias propiedades que permiten a los desarrolladores recopilar datos de los encabezados de respuesta HTTP, la cadena de consulta o en el cuerpo del mensaje del documento HTML.

Requisitos
  • (MSXML) debe estar disponible para secuencias de comandos en el cliente (MSXML 3.0 se incluye con Microsoft Windows 2000 y versiones posteriores y se incluye con Internet Explorer 6.0 y versiones posteriores).
  • ServerA debe admitir la modificación de su configuración. Esta modificación permite ServerA para enviar al cliente Web a una página que se carga el objeto XMLHTTP . El objeto XMLHTTP intercepta el mensaje redirect en lugar de intentar procesar el mensaje redirect tal como antes de instalar la actualización de seguridad MS04 004.
Limitaciones
  • Un error en MSXML impide que esta solución sin ninguna configuración adicional. Este error se ha corregido. Sin embargo, los clientes de Internet Explorer que han instalado la actualización de seguridad MS04-004 requieren una versión actualizada de msxml?. DLL. Para obtener información adicional acerca de la versión actualizada de msxml?. DLL, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

    832414 XMLHTTP llamada produce un error para las direcciones URL con credenciales de usuario incrustadas

Método 2: Utilizar una aplicación de servidor que puede modificar la secuencia de datos HTTP antes de la ejecución de secuencias de comandos

Utilice una aplicación de servidor que puede modificar la secuencia de datos HTTP antes de la ejecución de secuencias de comandos (por ejemplo, un filtro ISAPI o un HttpModule. NET) en
B para interceptar las credenciales que se transmiten mediante el cliente Web a través de otra sección de una solicitud HTTP válida y, a continuación, generan una autorización válida: encabezado básico para pasar al servidor Web para la autenticación.

Requisitos
  • ServerA debe admitir la modificación de su configuración (para enviar al cliente Web de las credenciales en otra sección de la respuesta, por ejemplo, la cadena de consulta o en una Cookie. Por lo tanto, el cliente Web puede transmitir esas credenciales a ServerB para el filtro ISAPI o HttpModule para interceptar)
Limitaciones
  • B debe ser compatible con la aplicación de servidor, como los filtros ISAPI o HttpModules. NET, que se utiliza en esta solución.

Método 3: Utilizar un componente de servidor como WinHttp o ServerXMLHTTP

Utilizar un componente de servidor como el objeto de WinHttp o el objeto ServerXMLHTTPdentro de una página ASP o una página ASPX en ServerA para recuperar el contenido del servidor bdirectamente, (es decir, en nombre del usuario) y, a continuación, devolver ese contenido al cliente Web. En este escenario, el cliente Web nunca se comunica con el servidor b.


Requisitos
  • El ID de Prog WinHttp.WinHttpRequest.5.1 debe estar disponible en
    ServerA. De forma predeterminada, WinHttp.WinHttpRequest.5.1 se incluye con Microsoft Windows 2000 Service Pack 3, Microsoft Windows XP Service Pack 1 y Microsoft Windows Server 2003.
Limitaciones
  • WinHttp.WinHttpRequest.5.1 espera ServerB para devolver contenido completado al cliente Web. En este escenario, el cliente Web tiene la versión instalada de Internet Explorer que se ha actualizado con la actualización de seguridad MS04-004. Si este cliente Web espera llevar a cabo comunicaciones sincrónicas con ServerB (a través de un control ActiveX o un applet de Java), esta solución no funcionen.
  • Microsoft no recomienda esta solución porque el rendimiento de ServerA afectará a la funcionalidad del cliente Web si el cliente Web tiene la versión instalada de Internet Explorer que se ha actualizado con la actualización de seguridad MS04-004.

Método 4: Utilizar una aplicación cliente personalizada

Utilice una aplicación de cliente personalizada como un control ActiveX que llama a la API de WinInet o la API de WinHttp o un control de formularios Windows Forms .NET que utiliza el espacio de nombres System.Net.Sockets , que se puede crear una instancia de código de cliente en el explorador. Este objeto personalizado debe ser capaz de establecer una conexión TCP y debe ser capaz de transmitir los mensajes HTTP (S) correcto (incluyendo la generación de una autorización: encabezado de solicitud básica).


Requisitos
  • Solución de ActiveX: los usuarios deben tener permiso para instalar controles ActiveX en su equipo.
  • Solución de ActiveX: configuración de seguridad de Internet Explorer debe permitir la ejecución de aplicaciones ActiveX.
  • Solución .NET WinForms: Microsoft.NET Framework debe estar instalado en el cliente Web.
Limitaciones
  • Los usuarios en entornos administrados no podrán modificar su configuración de descarga y ejecución para permitir controles ActiveX o controles de formularios Windows Forms. NET.
  • WinHttp (llamado directamente a través de COM, o el de.NET Framework) utiliza un conjunto diferente de la API de WinInet (que se utiliza con Internet Explorer). Por lo tanto, debe producirse ninguna autenticación en una aplicación de cliente para cada solicitud que se envía al servidor Web.
  • Solución .NET WinForms: antes de ejecutar el control de cliente, debe configurar la característica de seguridad de .NET en cada cliente de Web.
  • Solución .NET WinForms: es la única manera de comprobar que el.NET Framework está instalado en un cliente de Web no administrado de forma remota consultar la cadena de agente de usuario HTTP que es proporcionada por Internet Explorer. Sin embargo, dado que este valor puede modificarse con una configuración del registro, no se considera este tipo de detección autorizado.

Referencias


El siguiente archivo está disponible para su descarga desde el Centro de descarga de Microsoft:
Download Descargar ahora el paquete Samples.exe. Para obtener información adicional acerca de cómo descargar archivos de Microsoft Support, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
119591 cómo obtener archivos de soporte técnico de Microsoft desde los servicios en línea
Microsoft analizó este archivo en busca de virus. Microsoft ha utilizado el software de detección de virus más reciente que estaba disponible en la fecha en que se publicó el archivo. El archivo se almacena en servidores seguros que ayudan a impedir cambios no autorizados en el archivo.
Para obtener más información, visite los siguientes sitios Web de Microsoft Developer Network (MSDN):
Autenticación mediante secuencias de comandos
http://msdn2.microsoft.com/en-us/library/aa383147.aspx
DHTML y. NET de Host seguro, controles de cliente ligeros en Microsoft Internet Explorer
http://msdn.microsoft.com/msdnmag/issues/02/01/userctrl/
GetResponseHeader (método (IXMLHTTPRequest))
http://msdn2.microsoft.com/en-us/library/ms757006.aspx
Boletín de seguridad de Microsoft MS04-004
http://www.microsoft.com/technet/security/bulletin/ms04-004.mspx
Para obtener información adicional acerca de Request for Comments (RFC), visite los siguientes sitios Web de RFC:Para obtener información adicional, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

815148 cómo ajustar la seguridad.NET Framework zona por zona

259100 ejemplo: Vbhttp.exe muestra cómo utilizar APIs de HTTP WinInet en Visual Basic

303436 ejemplo: red de Visual .NET C# clases de cliente HTTP de Internet

Las zonas de seguridad de Internet Explorer 182569 entradas del registro para usuarios avanzados

834489 de Internet Explorer no admite nombres de usuario y contraseñas en direcciones de sitios Web (URL HTTP o HTTPS)

284285 cómo usar Wfetch.exe para solucionar problemas de las conexiones HTTP

836640 se no pueden tener acceso a Outlook Web Access y único inicio de sesión en aplicaciones Web utilizando XMLHTTP después de aplicar la actualización de seguridad Internet Explorer MS04-004