Compartir a través de

Consideraciones de seguridad de WinHTTP

  • Artículo

Las siguientes consideraciones de seguridad se aplican a las aplicaciones que utilizan WinHTTP:

  • Los certificados de servidor solo se verifican una vez por sesión. Una vez verificado, el certificado sigue siendo válido durante la sesión en curso. Mientras la huella digital del certificado coincida, lo que indica que el certificado no ha cambiado, el certificado sigue revalidándose. Como resultado, cualquier cambio en los criterios de validación, a través de los indicadores de protocolo, comprobación de revocación o ignorar errores de certificado, no surte efecto una vez que se verifica el certificado. Para forzar que un cambio de este tipo surta efecto inmediatamente, hay que finalizar la sesión actual e iniciar una nueva. Del mismo modo, la caducidad de un certificado durante el transcurso de una sesión solo puede detectarse si la propia aplicación comprueba periódicamente el servidor de certificados para recuperar los datos de caducidad.
  • El autoproxy implica la descarga y ejecución de scripts. El soporte de descubrimiento automático de proxy implica la detección a través de DHCP o DNS, descarga y ejecución de scripts de proxy como scripts Java. Para lograr un mayor grado de seguridad, una aplicación debe evitar pasar el WINHTTP_AUTOPROXY_RUN_INPROCESS bandera, para que el descubrimiento del autoproxy se inicie fuera del proceso. Incluso entonces, WinHTTP intenta por defecto ejecutar un script auto-proxy dentro del proceso si el script no se ejecuta correctamente fuera del proceso. Si cree que este comportamiento supone un riesgo inaceptable, desactívelo con la WINHTTP_AUTOPROXY_RUN_OUTPROCESS_ONLY bandera.
  • Las funciones WINHTTP_STATUS_CALLBACK deben devolver puntualmente. Cuando escribas una de estas funciones callback, ten cuidado de que no se bloquee. Por ejemplo, ni la llamada de retorno ni ninguna función a la que llame debe mostrar un diálogo de usuario o esperar un evento. Si una WINHTTP_STATUS_CALLBACK se bloquea, afecta a la programación interna de WinHTTP y provoca que se deniegue el servicio a otras peticiones dentro del mismo proceso.
  • Las funciones WINHTTP_STATUS_CALLBACK deben volver a ingresar. Cuando escriba una llamada de retorno, evite variables estáticas u otras construcciones que no sean seguras bajo reentrada, y evite llamar a otras funciones que no sean reentrantes.
  • Si la operación asíncrona es posible, pase NULLs para los parámetros OUT. Si ha activado el funcionamiento asíncrono registrando una función de devolución de llamada, pase siempre NULO valores para parámetros OUT como lpdwDataAvailable para WinHttpQueryDataAvailable, lpdwBytesRead para WinHttpReadData, o lpdwBytesWritten para WinHttpWriteData. En algunas circunstancias, el subproceso de llamada finaliza antes de que se complete la operación, y si los parámetros OUT no son NULO, la función puede acabar escribiendo en memoria que ya ha sido liberada.
  • La autenticación de pasaportes no es infalible. Cualquier esquema de autenticación basado en cookies es vulnerable a ataques. La versión 1.4 de Passport se basa en cookies y, por tanto, está sujeta a las vulnerabilidades asociadas a cualquier sistema de autenticación basado en cookies o formularios. La compatibilidad con Passport está desactivada por defecto en WinHTTP; puede activarse mediante WinHttpSetOption.
  • La autenticación Básico solo debe utilizarse a través de una conexión segura. Autenticación Básico, que envía el nombre de usuario y la contraseña en texto claro (véase RFC 2617), solo debe utilizarse en conexiones SSL o TLS cifradas.
  • Configurar la política de inicio de sesión automático en "bajo" puede suponer un riesgo. Cuando la política de inicio de sesión automático está configurada en bajo, la credencial de inicio de sesión de un usuario se puede utilizar para autenticarse en cualquier sitio. Sin embargo, no es una buena práctica de seguridad autenticarse en sitios en los que no se confía.
  • Las conexiones SSL 2.0 no se utilizan a menos que se habiliten explícitamente. Los protocolos de seguridad TLS 1.0 y SSL 3.0 se consideran más seguros que SSL 2.0. Por defecto, WinHTTP solicita TLS 1.0 o SSL 3.0 cuando negocia una conexión SSL, no SSL 2.0. El soporte SSL 2.0 en WinHTTP solo puede ser activado llamando a WinHttpSetOption.
  • La comprobación de la revocación de certificados debe solicitarse explícitamente. Por defecto, al realizar la autenticación del certificado, WinHTTP no comprueba si el certificado del servidor ha sido revocado. La comprobación de la revocación de certificados debe permitirse usando WinHttpSetOption.
  • Las aplicaciones deben garantizar que una sesión corresponde a una única identidad. Una sesión WinHTTP debe asignarse a una y solo una identidad; es decir, una sesión WinHTTP se utiliza para gestionar la actividad en Internet de un solo usuario autenticado, o de un grupo de usuarios anónimos. Sin embargo, debido a que WinHTTP no impone esta asignación automáticamente, su aplicación debe tomar medidas para asegurarse de que solo una identidad está involucrada.
  • Las operaciones sobre un manejador de petición WinHTTP deben estar sincronizadas. Por ejemplo, una aplicación debe evitar cerrar un gestor de petición en un subproceso mientras otro subproceso está enviando o recibiendo una petición. Para finalizar una solicitud asíncrona, cierre el manejador de la solicitud durante una notificación de devolución de llamada. Para finalizar una petición sincrónica, cierre el handle cuando la llamada WinHTTP anterior retorne.
  • Los archivos de rastreo contienen información sensible. Los archivos de rastreo están protegidos mediante listas de control de acceso (ACL), de modo que normalmente solo puede acceder a ellos el administrador local o la cuenta de usuario que los creó.Evite poner en peligro los archivos de rastreo mediante cualquier acceso no autorizado.
  • Evite transmitir datos sensibles WinHttpSetOption. No proporcione un nombre de usuario, contraseña o cualquier otra credencial para WinHttpSetOption porque no tienes control sobre el esquema de autenticación que se utiliza, y los datos sensibles podrían enviarse inesperadamente en texto claro. Use WinHttpQueryAuthSchemes y WinHttpSetCredentials en lugar de WinHttpSetOption para credenciales de ajustes.
  • El redireccionamiento automático puede suponer un riesgo para la seguridad. Por defecto, la redirección (un mensaje 302) se sigue automáticamente incluso para un POST. Para evitar la posibilidad de redirecciones espurias, las aplicaciones deben desactivar la redirección automática o controlar la redirección en las devoluciones de llamada al publicar información sensible.
  • Las cabeceras definidas por el usuario se transfieren a través de las redirecciones sin cambios. Cabeceras definidas por el usuario, como las cookies añadidas con WinHTTPAddRequestHeaders, se transfieren a través de las redirecciones sin modificación, mientras que las cabeceras generadas por WinHTTP se actualizan automáticamente. Si la transferencia de un encabezado definido por el usuario a través de redirecciones supone un riesgo para la seguridad, utilice la WINHTTP_STATUS_CALLBACK llame de vuelta a WINHTTP_CALLBACK_STATUS_REDIRECT para modificar la cabecera en cuestión cada vez que se produzca una redirección.
  • WinHTTP no es reentrante en modo síncrono. Dado que WinHTTP no es reentrante en modo síncrono, no programe llamadas a procedimientos asíncronos (APC) que puedan llamar a WinHTTP en un hilo de aplicación que se ejecute dentro de una función WinHTTP. Mientras está en modo síncrono, WinHTTP realiza una "espera alertable", y si el hilo en espera es adelantado para ejecutar un APC y más tarde vuelve a entrar en WinHTTP de nuevo, el estado interno de WinHTTP puede corromperse.