Consideraciones de seguridad de WinHTTP

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

• Los certificados de servidor solo se comprueban una vez por sesión. Una vez comprobado un certificado, sigue siendo válido durante la sesión actual. Siempre que la huella digital del certificado coincida, lo que indica que el certificado no ha cambiado, el certificado continúa siendo revalidado. Como resultado, cualquier cambio en los criterios de validación, mediante el protocolo, la comprobación de revocación o las marcas certificate-error-ignore, no surte efecto una vez comprobado el certificado. Para forzar que este cambio surta efecto inmediatamente, la sesión actual debe finalizarse y se iniciará una nueva. Del mismo modo, la expiración de un certificado durante el transcurso de una sesión solo se puede detectar si la propia aplicación comprueba periódicamente el servidor de certificados para recuperar los datos de expiración.
• El proxy automático implica descargar y ejecutar scripts. La compatibilidad con la detección automática de proxy implica la detección a través de DHCP o DNS, la descarga y la ejecución de scripts de proxy, como scripts de Java. Para lograr un mayor grado de seguridad, una aplicación debe evitar pasar la marca WINHTTP_AUTOPROXY_RUN_INPROCESS , de modo que la detección de proxy automático se inicie fuera del proceso. Incluso después, WinHTTP intenta ejecutar de forma predeterminada un script de proxy automático en proceso si el script no se ejecuta correctamente fuera del proceso. Si cree que este comportamiento de reserva supone un riesgo inaceptable, deshabilite el comportamiento de reserva con la marca WINHTTP_AUTOPROXY_RUN_OUTPROCESS_ONLY .
• WINHTTP_STATUS_CALLBACK las funciones deben devolverse rápidamente. Al escribir una de estas funciones de devolución de llamada, tenga cuidado de que no se bloquee. Por ejemplo, ni la devolución de llamada ni ninguna función a la que llama deben mostrar un cuadro de diálogo de usuario o esperar un evento. Si una función de WINHTTP_STATUS_CALLBACK bloquea, afecta a la programación interna de WinHTTP y hace que se denieguen otras solicitudes dentro del mismo proceso.
• WINHTTP_STATUS_CALLBACK las funciones deben ser reentrantes. Al escribir una devolución de llamada, evite variables estáticas u otras construcciones que no sean seguras en la reentrada y evite llamar a otras funciones que no sean reentrantes.
• Si es posible la operación asincrónica, pase valores NULL para parámetros OUT. Si ha habilitado la operación asincrónica mediante el registro de una función de devolución de llamada, pase siempre valores NULL para estos parámetros OUT como lpdwDataAvailable para WinHttpQueryDataAvailable, lpdwBytesRead para WinHttpReadData o lpdwBytesWritten para WinHttpWriteData. En algunas circunstancias, el subproceso que realiza la llamada finaliza antes de que se complete la operación y, si los parámetros OUT no son NULL, la función puede terminar escribiendo en la memoria que ya se ha liberado.
• La autenticación de Passport no es infalible. Cualquier esquema de autenticación basado en cookies es vulnerable a ataques. Passport versión 1.4 se basa en cookies y, por tanto, está sujeto a las vulnerabilidades asociadas a cualquier esquema de autenticación basado en formularios o cookies. La compatibilidad con Passport está deshabilitada de forma predeterminada en WinHTTP; se puede habilitar mediante WinHttpSetOption.
• La autenticación básica solo se debe usar a través de una conexión segura. La autenticación básica, que envía el nombre de usuario y la contraseña en texto no cifrado (consulte RFC 2617), solo se debe usar a través de conexiones SSL o TLS cifradas.
• Establecer la directiva de inicio de sesión automático en "bajo" puede suponer un riesgo. Cuando la directiva de inicio de sesión automático se establece en baja, se puede usar la credencial de inicio de sesión de un usuario para autenticarse en cualquier sitio. Sin embargo, no es una buena práctica de seguridad autenticarse en sitios en los que no confía.
• Las conexiones SSL 2.0 no se usan a menos que se habilite explícitamente. Los protocolos de seguridad TLS 1.0 y SSL 3.0 se consideran más seguros que SSL 2.0. De forma predeterminada, WinHTTP solicita TLS 1.0 o SSL 3.0 al negociar una conexión SSL, no SSL 2.0. La compatibilidad con SSL 2.0 en WinHTTP solo se puede habilitar llamando a WinHttpSetOption.
• La comprobación de revocación de certificados debe solicitarse explícitamente. De forma predeterminada, al realizar la autenticación de certificados, WinHTTP no comprueba si se ha revocado el certificado del servidor. La comprobación de revocación de certificados se puede habilitar mediante WinHttpSetOption.
• Las aplicaciones deben asegurarse de que una sesión se asigna a una única identidad. Una sesión de WinHTTP debe asignarse a una y solo una identidad; es decir, se usa una sesión de WinHTTP para administrar la actividad de Internet de un único usuario autenticado o un grupo de usuarios anónimos. Sin embargo, dado que WinHTTP no aplica esta asignación automáticamente, la aplicación debe seguir los pasos necesarios para asegurarse de que solo haya una sola identidad implicada.
• Las operaciones en un identificador de solicitud WinHTTP deben sincronizarse. Por ejemplo, una aplicación debe evitar cerrar un identificador de solicitud en un subproceso mientras otro subproceso envía o recibe una solicitud. Para finalizar una solicitud asincrónica, cierre el identificador de solicitud durante una notificación de devolución de llamada. Para finalizar una solicitud sincrónica, cierre el identificador cuando vuelva la llamada winHTTP anterior.
• Los archivos de seguimiento contienen información confidencial. Los archivos de seguimiento están protegidos mediante listas de Access-Control (ACL) para que solo el administrador local o la cuenta de usuario que la haya creado puedan acceder normalmente. Evite poner en peligro los archivos de seguimiento por cualquier acceso no autorizado.
• Evite pasar datos confidenciales a través deWinHttpSetOption. No proporcione un nombre de usuario, una contraseña ni ninguna otra credencial a WinHttpSetOption porque no tiene control sobre el esquema de autenticación que se usa y los datos confidenciales podrían enviarse inesperadamente en texto no cifrado. Use WinHttpQueryAuthSchemes y WinHttpSetCredentials en lugar de WinHttpSetOption para establecer las credenciales.
• El redireccionamiento automático puede suponer un riesgo de seguridad. De forma predeterminada, el redireccionamiento (un mensaje 302) se sigue automáticamente incluso para un POST. Para evitar la posibilidad de redireccionamientos falsos, las aplicaciones deben deshabilitar la redirección automática o supervisar la reenvío en las devoluciones de llamada al publicar información confidencial.
• Los encabezados definidos por el usuario se transfieren a través de redirecciones sin cambios. Los encabezados definidos por el usuario, como las cookies agregadas con WinHTTPAddRequestHeaders, se transfieren entre redirecciones sin modificaciones, mientras que los encabezados generados por WinHTTP se actualizan automáticamente. Si la transferencia de un encabezado definido por el usuario entre redirecciones supone un riesgo de seguridad, use la devolución de llamada WINHTTP_STATUS_CALLBACK con la finalización del WINHTTP_CALLBACK_STATUS_REDIRECT para modificar el encabezado en cuestión siempre que se produzca una redirección.
• WinHTTP no es reentrant en modo sincrónico. Dado que WinHTTP no es reentrante en modo sincrónico, no programe llamadas a procedimientos asincrónicos (APC) que puedan llamar a WinHTTP en un subproceso de aplicación que se ejecute dentro de una función WinHTTP. Mientras se encuentra en modo sincrónico, WinHTTP realiza una "espera alertable" y si el subproceso en espera se vacía previamente para ejecutar un APC y, después, vuelve a entrar en WinHTTP de nuevo, el estado interno de WinHTTP se puede dañar.