WinHTTP详解：从基础到高级功能与安全 - CSDN文库

需积分: 9 157 浏览量更新于2024-07-14 收藏 1.4MB PDF 举报

WinHttp参考手册英文版是一份详尽的文档，主要针对Windows HTTP Services (WinHTTP)，这是一种在Microsoft Windows平台上处理网络通信的核心组件。它提供了高级的HTTP/HTTPS协议支持，广泛应用于Web浏览器、网络客户端和服务器之间的数据传输。以下是该手册中的关键知识点概览： 1. **关于WinHTTP**: WinHTTP是Windows操作系统中的一个接口，专门用于创建HTTP(S)会话，执行GET、POST等请求，并处理响应。相较于旧的WinINet API，WinHTTP提供了更好的性能、安全性和功能扩展。 2. **WinHTTP版本比较**: WinHTTP 5.1及后续版本引入了许多新特性，如更强大的身份验证机制（如Passport Authentication）、SSL/TLS支持的增强以及IPv6兼容性。Windows Server 2008和Windows Vista的发布也促使WinHTTP得到了重大改进。 3. **网络术语**: 手册详细解释了网络通信中涉及的基本概念，帮助开发者理解和使用WinHTTP时正确解读网络术语。 4. **选择WinHTTP接口**: 文档指导开发者如何根据应用需求选择合适的WinHTTP接口，如C/C++ API、COM对象或脚本API，以实现不同的开发环境和兼容性。 5. **安全注意事项**: 提供了对WinHTTP安全性的深入分析，包括SSL/TLS配置、密码保护和数据加密，确保应用在通信过程中遵循最佳实践。 6. **从WinINet迁移到WinHTTP**: 对于那些使用过WinINet的开发者，手册阐述了如何平滑地迁移应用程序以利用WinHTTP的新功能和性能优势。 7. **WinHTTP会话管理**: 介绍了WinHTTP会话的概念，包括HINTERNET句柄的管理和使用，以及URL处理方法。 8. **身份验证**: 详细讲解了WinHTTP的身份验证机制，包括基本认证、Passport认证，以及与OAuth、Kerberos等现代身份验证协议的集成。 9. **Cookie处理**: 阐述了WinHTTP如何处理和管理Cookies，这对于保持用户状态和个性化设置至关重要。 10. **错误处理**: 提供了如何识别和处理WinHTTP请求过程中可能出现的错误，确保应用程序具有健壮的错误处理能力。 11. **自动代理支持**: WinHTTP支持通过系统自动配置文件和辅助工具（如WinHttpCertCfg.exe）来发现并设置代理设置。 12. **IPv6扩展**: 对于IPv6网络的支持，手册解释了新的IPv6扩展到Navigator自动配置文件格式和相关的API定义。 13. **WinHttpRequest COM对象**: 介绍了COM对象的使用，它是与脚本语言（如JavaScript）交互的便捷方式，适用于客户端或服务器端编程。 14. **脚本编程**: 提供了如何使用脚本（如VBScript或JavaScript）通过WinHTTP获取数据和进行身份验证的示例。 15. **工具使用**: 包括证书配置工具WinHttpCertCfg.exe，以及Netsh.exe和ProxyCfg用于网络配置的命令行实用程序。 WinHttp参考手册英文版为开发人员提供了全面的指南，涵盖了从基础设置到高级功能的各个方面，确保他们能高效、安全地利用WinHTTP进行网络编程。

Synchronous and Asynchronous Modes

Authentication

it on to the server. When the server responds, the response also passes through the proxy before it is forwarded

on to the client. The proxy can modify the headers in this response.

By intercepting and translating network transactions, a proxy can:

Protect the client by monitoring potentially dangerous transactions.

Enable the client to communicate using protocols that might not be implemented by the client software.

Act as a gateway between a private network and a public network.

The WinHTTP API includes a proxy configuration tool that enables you to provide WinHTTP with information

regarding any proxy servers that intercept your HTTP transactions. For information on using the proxy

configuration tool, see ProxyCfg.exe, a Proxy Configuration Tool.

There are two programming models for obtaining resources over a network using WinHTTP—the synchronous

and asynchronous models. In a synchronous model, a call to a function or method does not finish until the

requested operation is complete or until an error occurs. For example, when your application requests a

resource using WinHTTP synchronously, it does not continue with the next step until the requested data has

been received.

An asynchronous model, on the other hand, allows an application to perform other tasks while it waits for the

resource to be retrieved. If another WinHTTP function or method is called and a previous operation has not

finished, the function returns an error. When using WinHTTP asynchronously, Component Object Model (COM)

events and callback are available to notify an application of progress in an HTTP operation.

Authentication is the process by which an HTTP proxy or HTTP server validates a user's login information before

it allows access to resources. Various authentication schemes are used on the Internet. Usually a user's name

and password are compared against an authorized list, and if the system detects a match, access is granted to

the extent specified in the permission list for the user.

WinHTTP functions support both server and proxy authentication for HTTP sessions. WinHTTP supports the

following authentication schemes: Basic, Digest (see RFC 2617), NTLM Authentication, Negotiate/ Kerberos, and

Microsoft Passport 1.4. For detailed information on authentication, as well as an example of using authentication

in a Microsoft Visual C++ application, see Authentication in WinHTTP.

For information about security considerations regarding Basic and Passport authentication, see WinHTTP

Security Considerations.

WinHTTP Security Considerations

3/5/2021 • 4 minutes to read • Edit Online

The following security considerations apply to applications that use WinHTTP:

Ser ver cer tificates are only verified once per session.Ser ver cer tificates are only verified once per session. After a certificate has been verified, it remains

valid for the duration of the current session. As long as the certificate fingerprint matches, which indicates

that the certificate has not changed, the certificate continues to be re-validated. As a result, any change in the

validation criteria, through the protocol, revocation-check, or certificate-error-ignore flags, does not take

effect once the certificate is verified. To force such a change to take effect immediately, the current session

must be ended and a new one started. Similarly, expiration of a certificate during the course of a session can

only be detected if the application itself checks the certificate server periodically to retrieve expiration data.

Auto-proxy involves downloading and executing scripts.Auto-proxy involves downloading and executing scripts. The automatic proxy discovery support

involves detecting through DHCP or DNS, downloading, and executing proxy scripts such as Java scripts. To

achieve a higher degree of security, an application must avoid passing the

WINHTTP_AUTOPROXY_RUN_INPROCESSWINHTTP_AUTOPROXY_RUN_INPROCESS flag, so that the auto-proxy discovery is initiated out-of-

process. Even then, WinHTTP tries by default to run an auto-proxy script in-process if the script fails to run

properly out-of-process. If you believe that this fallback behavior poses an unacceptable risk, disable the

fallback behavior with the WINHTTP_AUTOPROXY_RUN_OUTPROCESS_ONLYWINHTTP_AUTOPROXY_RUN_OUTPROCESS_ONLY flag.

WINHTTP_STATUS_CALLBACK functions must return promptly.WINHTTP_STATUS_CALLBACK functions must return promptly. When you write one of these callback

functions, be careful that it does not block. For example, neither the callback nor any function it calls should

display a user dialog or wait for an event. If a

WINHTTP_STATUS_CALLBACK

function does block, it affects

WinHTTP's internal scheduling and causes other requests within the same process to be denied service.

WINHTTP_STATUS_CALLBACK functions must be reentrant.WINHTTP_STATUS_CALLBACK functions must be reentrant. When writing a callback, avoid static

variables or other constructs that are unsafe under reentrance, and avoid calling other functions that are not

reentrant.

If asynchronous operation is possible, pass NULLs for OUT parameters.If asynchronous operation is possible, pass NULLs for OUT parameters. If you have enabled

asynchronous operation by registering a callback function, always pass NULLNULL values for such OUT

parameters as

lpdwDataAvailable

for WinHttpQuer yDataAvailableWinHttpQuer yDataAvailable,

lpdwBytesRead

for

WinHttpReadDataWinHttpReadData, or

lpdwBytesWritten

for WinHttpWriteDataWinHttpWriteData. Under some circumstances, the calling

thread is terminated before the operation completes, and if the OUT parameters are not NULLNULL, the function

can end up writing to memory that has already been freed.

Passpor t authentication is not foolproof.Passpor t authentication is not foolproof. Any cookie-based authentication scheme is vulnerable to

attack. Passport version 1.4 is cookie based, and therefore subject to the vulnerabilities that are associated

with any cookie or form-based authentication scheme. Passport support is disabled by default in WinHTTP; it

can be enabled using WinHttpSetOptionWinHttpSetOption.

Basic authentication should only be used over a secure connection.Basic authentication should only be used over a secure connection. Basic authentication, which

sends the user name and password in clear text (see RFC 2617), should be used only over encrypted SSL or

TLS connections.

Setting Auto-Logon Policy to "low" can pose a risk .Setting Auto-Logon Policy to "low" can pose a risk . When the Auto-Logon Policy is set to low, a user's

logon credential can be used to authenticate against any site. However, it is not good security practice to

authenticate against sites you do not trust.

SSL 2.0 connections are not used unless explicitly enabled.SSL 2.0 connections are not used unless explicitly enabled. The TLS 1.0 and SSL 3.0 security

protocols are considered more secure than SSL 2.0. By default, WinHTTP requests TLS 1.0 or SSL 3.0 when

negotiating an SSL connection, not SSL 2.0. SSL 2.0 support in WinHTTP can only be enabled by calling

WinHttpSetOptionWinHttpSetOption.

Cer tificate-revocation checking must be explicitly requested.Cer tificate-revocation checking must be explicitly requested. By default, when performing certificate

authentication, WinHTTP does not check whether the server's certificate has been revoked. Certificate-

revocation checking can be enabled using WinHttpSetOptionWinHttpSetOption.

Applications must ensure that a session maps to a single identity.Applications must ensure that a session maps to a single identity. A WinHTTP session should map

to one and only one identity; that is, a WinHTTP session is used to manage the Internet activity of a single

authenticated user, or a group of anonymous users. However, because WinHTTP does not enforce this

mapping automatically, your application must take steps to ensure that only a single identity is involved.

Operations on a WinHTTP request handle should be synchronized.Operations on a WinHTTP request handle should be synchronized. For example, an application

should avoid closing a request handle on one thread while another thread is sending or receiving a request.

To terminate an asynchronous request, close the request handle during a callback notification. To terminate a

synchronous request, close the handle when the previous WinHTTP call returns.

Trace files contain sensitive information.Trace files contain sensitive information. Trace files are protected using Access-Control Lists (ACLs) so

that one can normally be accessed only by the local administrator or by the user account that created it.Avoid

compromising trace files by any unauthorized access.

Avoid passing sensitive data throughAvoid passing sensitive data through WinHttpSetOptionWinHttpSetOption. Do not supply a user name, password or

any other credentials to WinHttpSetOptionWinHttpSetOption because you have no control over the authentication scheme

that is used, and the sensitive data could unexpectedly be sent in clear text. Use

WinHttpQuer yAuthSchemesWinHttpQuer yAuthSchemes and WinHttpSetCredentialsWinHttpSetCredentials instead of WinHttpSetOptionWinHttpSetOption for setting

credentials.

Automatic redirection can pose a security risk .Automatic redirection can pose a security risk . By default, redirection (a 302 message) is followed

automatically even for a POST. To avoid the possibility of spurious redirects, applications should disable auto-

redirect or monitor re-direction in callbacks when posting sensitive information.

User-defined headers are transferred across redirects unchanged.User-defined headers are transferred across redirects unchanged. User-defined headers, such as

cookies added with WinHTTPAddRequestHeadersWinHTTPAddRequestHeaders, are transferred across redirects without modification,

while headers generated by WinHTTP are automatically updated. If transferring a user-defined header across

redirects poses a security risk, use the

WINHTTP_STATUS_CALLBACK

callback with the

WINHTTP_CALLBACK_STATUS_REDIRECTWINHTTP_CALLBACK_STATUS_REDIRECT completion to modify the header in question whenever a

redirect occurs.

WinHTTP is not reentrant in synchronous mode.WinHTTP is not reentrant in synchronous mode. Because WinHTTP is not reentrant in synchronous

mode, do not schedule asynchronous procedure calls (APC) that can call into WinHTTP on an application

thread that executes inside a WinHTTP function. While in synchronous mode, WinHTTP performs an

"alertable wait," and if the waiting thread is pre-empted to execute an APC and then later re-enters WinHTTP

again, WinHTTP's internal state can be corrupted.

Porting WinINet Applications to WinHTTP

3/5/2021 • 8 minutes to read • Edit Online

Things to Consider Before Porting Your WinINet Application

WinHTTP Equivalents to WinINet Functions

WIN IN ET FU N C T IO NWIN IN ET FU N C T IO N WIN H T T P EQ UIVA L E N TWIN H T T P EQ UIVA L E N T N OTA B L E C H A N GESN OTA B L E C H A N GES

HttpAddRequestHeadersHttpAddRequestHeaders WinHttpAddRequestHeadersWinHttpAddRequestHeaders None.

Microsoft Windows HTTP Services (WinHTTP) is targeted at middle-tier and back-end server applications that

require access to an HTTP client stack. Microsoft Windows Internet (WinINet) provides an HTTP client stack for

client applications, as well as access to the File Transfer Protocol (FTP), SOCKSv4, and Gopher protocols. This

overview can help determine whether porting your WinINet applications to WinHTTP would be beneficial. It also

describes specific conversion requirements.

Things to Consider Before Porting Your WinINet Application

WinHTTP Equivalents to WinINet Functions

Different Handling of Asynchronous Requests

Differences in WinHTTP Callback Notifications

Authentication Differences

Differences in Secure HTTP Transactions

Consider porting your WinINet application to WinHTTP if your application would benefit from:

A server-safe HTTP client stack.

Minimized stack usage.

The scalability of a server application.

Fewer dependencies on platform-related APIs.

Support for thread impersonation.

A service-friendly HTTP stack.

Access to the scriptable WinHttpRequestWinHttpRequest object.

Do not consider porting your WinINet application to WinHTTP if it must support one or more of the following:

The FTP or Gopher protocol from the HTTP stack.

Support for SOCKSv4 protocol for communicating with SOCKS proxies.

Automatic dial-up services.

If you decide to port your application to WinHTTP, the following sections guide you through the conversion

process.

For a sample application for both WinINet and WinHTTP, compare the AsyncDemo sample for WinINet with the

AsyncDemo sample for WinHTTP.

The following table lists WinINet functions related to the HTTP client stack together with the WinHTTP

equivalents.

If your application requires WinINet functions that are not listed, do not port your application to WinHTTP.

剩余242页未读，继续阅读

林角叶子

粉丝: 1
资源: 6

最新资源