Considerações sobre segurança do WinHTTP

As seguintes considerações de segurança se aplicam a aplicativos que usam WinHTTP:

• Os certificados do servidor são verificados apenas uma vez por sessão. Depois que um certificado for verificado, ele permanecerá 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 continuará a ser validado novamente. Como resultado, qualquer alteração nos critérios de validação, por meio do protocolo, marcar de revogação ou sinalizadores 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 será iniciada. Da mesma forma, a expiração de um certificado durante o curso de uma sessão só poderá ser detectada se o próprio aplicativo verificar o servidor de certificado periodicamente para recuperar dados de expiração.
• O proxy automático envolve o download e a execução de scripts. O suporte automático à descoberta de proxy envolve a detecção por meio de DHCP ou DNS, download e execução de scripts 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 .
• WINHTTP_STATUS_CALLBACK funções devem retornar imediatamente. Ao escrever uma dessas funções de retorno de chamada, tenha cuidado para que ela não bloqueie. Por exemplo, nem o retorno de chamada nem qualquer função que ele chama devem exibir uma caixa de diálogo do usuário ou aguardar um evento. Se uma função WINHTTP_STATUS_CALLBACK bloquear, ela afetará o agendamento interno do WinHTTP e fará com que outras solicitações dentro do mesmo processo sejam negadas ao serviço.
• WINHTTP_STATUS_CALLBACK funções devem ser reentrantes. Ao gravar um retorno de chamada, evite variáveis estáticas ou outros constructos que não sejam seguros sob reentrância e evite chamar outras funções que não são 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 poderá acabar gravando na memória que já foi liberada.
• A autenticação de passaporte não é à prova de falhas. Qualquer esquema de autenticação baseado em cookie é vulnerável a ataques. O Passport versão 1.4 é baseado em cookie e, portanto, está sujeito às vulnerabilidades associadas a qualquer cookie ou esquema de autenticação baseado em formulário. O suporte ao Passport 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 se autenticar em sites em que você não confia.
• As conexões SSL 2.0 não são usadas, a menos que 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 ao 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 marcar 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 Access-Control) para que normalmente seja possível acessar somente pelo administrador local ou pela conta de usuário que a 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 à segurança. Por padrão, o redirecionamento (uma mensagem 302) é seguido automaticamente até mesmo para um POST. Para evitar a possibilidade de redirecionamentos espúrios, os aplicativos devem desabilitar o redirecionamento automático ou monitorar a redirecionamento em retornos de chamada ao postar informações confidenciais.
• Os cabeçalhos definidos pelo usuário são transferidos entre redirecionamentos inalterados. 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 do 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 chamadas de procedimento assíncrono (APC) que possam chamar o WinHTTP em um thread de aplicativo executado dentro de uma função WinHTTP. Enquanto estiver no modo síncrono, o WinHTTP executará uma "espera alertável" e, se o thread em espera for previamente empado para executar um APC e, posteriormente, reentrar no WinHTTP novamente, o estado interno do WinHTTP poderá ser corrompido.