Considerações sobre a Segurança do WinHTTP

As considerações de segurança a seguir se aplicam aos aplicativos que usam o WinHTTP:

• Os certificados de servidor são verificados apenas uma vez por sessão. Depois que um certificado é verificado, ele permanece válido durante a sessão atual. Desde que a impressão digital do certificado corresponda, o que indica que o certificado não foi alterado, o certificado continua a ser revalidado. Como resultado, qualquer alteração nos critérios de validação, por meio dos sinalizadores de protocolo, revocation-check ou certificate-error-ignore, não entra em vigor depois que o certificado é verificado. Para forçar essa alteração a entrar em vigor imediatamente, a sessão atual deve ser encerrada e uma nova iniciada. Da mesma forma, a expiração de um certificado durante o curso de uma sessão só pode ser detectada se o próprio aplicativo verificar o servidor de certificados periodicamente para recuperar dados de expiração.
• O proxy automático envolve o download e a execução de scripts. O suporte à descoberta automática de proxy envolve a detecção por meio de DHCP ou DNS, download e execução de scripts de proxy, como scripts Java. Para obter um grau mais alto de segurança, um aplicativo deve evitar passar o sinalizador WINHTTP_AUTOPROXY_RUN_INPROCESS, para que a descoberta de proxy automático seja iniciada fora do processo. Mesmo assim, o WinHTTP tenta, por padrão, executar um script de proxy automático em processo se o script não for executado corretamente fora do processo. Se você acredita que esse comportamento de fallback representa um risco inaceitável, desabilite o comportamento de fallback com o sinalizador WINHTTP_AUTOPROXY_RUN_OUTPROCESS_ONLY.
• As funções WINHTTP_STATUS_CALLBACK devem retornar prontamente. Ao escrever uma dessas funções de retorno de chamada, tome cuidado para que ela não seja bloqueada. Por exemplo, nem o retorno de chamada nem qualquer função que ele chama deve exibir uma caixa de diálogo do usuário ou aguardar um evento. Se uma função WINHTTP_STATUS_CALLBACK bloquear, isso afetará o agendamento interno do WinHTTP e fará com que outras solicitações dentro do mesmo processo tenham o serviço negado.
• As funções WINHTTP_STATUS_CALLBACK devem ser reentrantes. Ao gravar um retorno de chamada, evite variáveis estáticas ou outras construções que não sejam seguras na reentrada e evite chamar outras funções que não sejam reentrantes.
• Se a operação assíncrona for possível, passe NULLs para parâmetros OUT. Se você tiver habilitado a operação assíncrona registrando uma função de retorno de chamada, sempre passe valores NULL para parâmetros OUT como lpdwDataAvailable para WinHttpQueryDataAvailable, lpdwBytesRead para WinHttpReadData ou lpdwBytesWritten para WinHttpWriteData. Em algumas circunstâncias, o thread de chamada é encerrado antes da conclusão da operação e, se os parâmetros OUT não forem NULL, a função pode acabar gravando na memória que já foi liberada.
• A autenticação do passaporte não é infalível. Qualquer esquema de autenticação baseado em cookie é vulnerável a ataques. A versão 1.4 do Passport é baseada em cookies e, portanto, está sujeita às vulnerabilidades associadas a qualquer esquema de autenticação baseado em cookies ou formulários. O suporte ao Passporte está desabilitado por padrão no WinHTTP; ele pode ser habilitado usando WinHttpSetOption.
• A autenticação básica só deve ser usada em uma conexão segura. A autenticação básica, que envia o nome de usuário e a senha em texto não criptografado (consulte RFC 2617), deve ser usada somente em conexões SSL ou TLS criptografadas.
• Definir a política de logon automático como "baixa" pode representar um risco. Quando a Política de Logon Automático é definida como baixa, a credencial de logon de um usuário pode ser usada para autenticar em qualquer site. No entanto, não é uma boa prática de segurança autenticar-se em sites em que você não confia.
• As conexões SSL 2.0 não são usadas, a menos que sejam explicitamente habilitadas. Os protocolos de segurança TLS 1.0 e SSL 3.0 são considerados mais seguros do que o SSL 2.0. Por padrão, o WinHTTP solicita TLS 1.0 ou SSL 3.0 ao negociar uma conexão SSL, não SSL 2.0. O suporte a SSL 2.0 no WinHTTP só pode ser habilitado chamando WinHttpSetOption.
• A verificação de revogação de certificado deve ser solicitada explicitamente. Por padrão, ao executar a autenticação de certificado, o WinHTTP não verifica se o certificado do servidor foi revogado. A verificação de revogação de certificado pode ser habilitada usando WinHttpSetOption.
• Os aplicativos devem garantir que uma sessão seja mapeada para uma única identidade. Uma sessão WinHTTP deve ser mapeada para uma e apenas uma identidade; ou seja, uma sessão WinHTTP é usada para gerenciar a atividade da Internet de um único usuário autenticado ou de um grupo de usuários anônimos. No entanto, como o WinHTTP não impõe esse mapeamento automaticamente, seu aplicativo deve tomar medidas para garantir que apenas uma única identidade esteja envolvida.
• As operações em um identificador de solicitação WinHTTP devem ser sincronizadas. Por exemplo, um aplicativo deve evitar fechar um identificador de solicitação em um thread enquanto outro thread está enviando ou recebendo uma solicitação. Para encerrar uma solicitação assíncrona, feche o identificador de solicitação durante uma notificação de retorno de chamada. Para encerrar uma solicitação síncrona, feche o identificador quando a chamada WinHTTP anterior retornar.
• Os arquivos de rastreamento contêm informações confidenciais. Os arquivos de rastreamento são protegidos usando ACLs (Listas de Controle de Acesso) para que normalmente só possam ser acessados pelo administrador local ou pela conta de usuário que o criou. Evite comprometer arquivos de rastreamento por qualquer acesso não autorizado.
• Evite passar dados confidenciais por meio de WinHttpSetOption. Não forneça um nome de usuário, senha ou qualquer outra credencial para WinHttpSetOption porque você não tem controle sobre o esquema de autenticação usado e os dados confidenciais podem ser enviados inesperadamente em texto não criptografado. Use WinHttpQueryAuthSchemes e WinHttpSetCredentials em vez de WinHttpSetOption para definir credenciais.
• O redirecionamento automático pode representar um risco de segurança. Por padrão, o redirecionamento (uma mensagem 302) é seguido automaticamente, mesmo para um POST. Para evitar a possibilidade de redirecionamentos espúrios, os aplicativos devem desabilitar o redirecionamento automático ou monitorar o redirecionamento em retornos de chamada ao postar informações confidenciais.
• Os cabeçalhos definidos pelo usuário são transferidos entre redirecionamentos inalterados. Os cabeçalhos definidos pelo usuário, como cookies adicionados com WinHTTPAddRequestHeaders, são transferidos entre redirecionamentos sem modificação, enquanto os cabeçalhos gerados pelo WinHTTP são atualizados automaticamente. Se a transferência de um cabeçalho definido pelo usuário entre redirecionamentos representar um risco de segurança, use o retorno de chamada WINHTTP_STATUS_CALLBACK com a conclusão de WINHTTP_CALLBACK_STATUS_REDIRECT para modificar o cabeçalho em questão sempre que ocorrer um redirecionamento.
• O WinHTTP não é reentrante no modo síncrono. Como o WinHTTP não é reentrante no modo síncrono, não agende APC (chamadas de procedimento assíncrono) que podem chamar o WinHTTP em um thread de aplicativo executado dentro de uma função WinHTTP. Enquanto estiver no modo síncrono, o WinHTTP executa uma "espera alertável" e, se o thread em espera for antecipado para executar uma APC e, posteriormente, entrar novamente no WinHTTP, o estado interno do WinHTTP poderá ser corrompido.