Considerações de segurança WinHTTP

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

• Os certificados do servidor só são verificados uma vez por sessão. Depois que um certificado for verificado, ele permanecerá válido durante a sessão atual. Enquanto a impressão digital do certificado corresponder, 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, através dos sinalizadores protocolo, revogação-verificação ou certificado-erro-ignorar, não entra em vigor depois que o certificado é verificado. Para forçar tal mudança 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 uma sessão só pode ser detetada 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 deteçã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 de 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, desative o comportamento de fallback com o sinalizador WINHTTP_AUTOPROXY_RUN_OUTPROCESS_ONLY.
• WINHTTP_STATUS_CALLBACK funções devem retornar imediatamente. Quando você escreve 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 chamada 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 sejam negadas ao serviço.
• WINHTTP_STATUS_CALLBACK funções devem ser reentrantes. Ao escrever um retorno de chamada, evite variáveis estáticas ou outras construções que não são seguras sob reentrada 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 de NULL para parâmetros OUT como lpdwDataAvailable para WinHttpQueryDataAvailable, lpdwBytesRead para WinHttpReadDataou lpdwBytesWritten para WinHttpWriteData. Em algumas circunstâncias, o thread de chamada é encerrado antes que a operação seja concluída 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 cookies é vulnerável a ataques. A versão 1.4 do Passport é baseada em cookies e, portanto, está sujeita às vulnerabilidades associadas a qualquer cookie ou esquema de autenticação baseado em formulário. O suporte ao Passport está desativado por padrão no WinHTTP; ele pode ser ativado 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 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 a SSL 2.0 no WinHTTP só pode ser habilitado chamando WinHttpSetOption.
• A verificação da revogação do certificado deve ser explicitamente solicitada. 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 certificados pode ser habilitada usando WinHttpSetOption.
• Os aplicativos devem garantir que uma sessão seja mapeada para uma única identidade. Uma sessão WinHTTP deve mapear para uma e apenas uma identidade; ou seja, uma sessão WinHTTP é usada para gerenciar a atividade na Internet de um único usuário autenticado ou um grupo de usuários anônimos. No entanto, como o WinHTTP não impõe esse mapeamento automaticamente, seu aplicativo deve executar etapas 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 Listas de Access-Control (ACLs) para que normalmente possam ser acessados apenas pelo administrador local ou pela conta de usuário que os criou. Evite comprometer arquivos de rastreamento por qualquer acesso não autorizado.
• Evite passar dados confidenciais atravésWinHttpSetOption. Não forneça um nome de usuário, senha ou quaisquer outras credenciais para WinHttpSetOption porque você não tem controle sobre o esquema de autenticação que é 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 desativar 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 do WINHTTP_CALLBACK_STATUS_REDIRECT para modificar o cabeçalho em questão sempre que ocorrer um redirecionamento.
• 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íncronas (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 executa uma "espera alertável" e, se o thread de espera for antecipado para executar um APC e, mais tarde, reinserir o WinHTTP novamente, o estado interno do WinHTTP pode ser corrompido.