Considerazioni sulla sicurezza di WinHTTP

Le considerazioni sulla sicurezza seguenti si applicano alle applicazioni che usano WinHTTP:

• I certificati server vengono verificati una sola volta per sessione. Dopo la verifica di un certificato, rimane valido per la durata della sessione corrente. Se l'impronta digitale del certificato corrisponde, che indica che il certificato non è stato modificato, il certificato continua a essere convalidato nuovamente. Di conseguenza, tutte le modifiche apportate ai criteri di convalida, tramite il protocollo, il controllo delle revoche o i flag certificate-error-ignore, non diventano effettive dopo la verifica del certificato. Per forzare immediatamente l'applicazione di tale modifica, è necessario terminare la sessione corrente e avviarne una nuova. Analogamente, la scadenza di un certificato durante il corso di una sessione può essere rilevata solo se l'applicazione controlla periodicamente il server certificati per recuperare i dati di scadenza.
• Il proxy automatico prevede il download e l'esecuzione di script. Il supporto per l'individuazione automatica del proxy comporta il rilevamento tramite DHCP o DNS, il download e l'esecuzione di script proxy, ad esempio script Java. Per ottenere un livello di sicurezza superiore, un'applicazione deve evitare di passare il flag di WINHTTP_AUTOPROXY_RUN_INPROCESS , in modo che l'individuazione automatica del proxy venga avviata out-of-process. Anche in questo caso, WinHTTP prova per impostazione predefinita a eseguire uno script proxy automatico in-process se lo script non viene eseguito correttamente out-of-process. Se si ritiene che questo comportamento di fallback rappresenti un rischio inaccettabile, disabilitare il comportamento di fallback con il flag WINHTTP_AUTOPROXY_RUN_OUTPROCESS_ONLY .
• WINHTTP_STATUS_CALLBACK funzioni devono restituire tempestivamente. Quando si scrive una di queste funzioni di callback, prestare attenzione a non bloccarla. Ad esempio, né il callback né alcuna funzione che chiama deve visualizzare una finestra di dialogo utente o attendere un evento. Se una funzione WINHTTP_STATUS_CALLBACK viene bloccata, influisce sulla pianificazione interna di WinHTTP e fa sì che altre richieste all'interno dello stesso processo vengano negate.
• WINHTTP_STATUS_CALLBACK funzioni devono essere reinsenti. Quando si scrive un callback, evitare variabili statiche o altri costrutti non sicuri in caso di reentrance ed evitare di chiamare altre funzioni che non rientrano.
• Se è possibile un'operazione asincrona, passare NULLs per i parametri OUT. Se è stata abilitata l'operazione asincrona registrando una funzione di callback, passare sempre valori NULL per tali parametri OUT come lpdwDataAvailable per WinHttpQueryDataAvailable, lpdwBytesRead per WinHttpReadData o lpdwBytesWritten per WinHttpWriteData. In alcune circostanze, il thread chiamante viene terminato prima del completamento dell'operazione e se i parametri OUT non sono NULL, la funzione può finire per scrivere in memoria che è già stata liberata.
• L'autenticazione Passport non è infallibile. Qualsiasi schema di autenticazione basato su cookie è vulnerabile agli attacchi. Passport versione 1.4 è basato su cookie e quindi soggetto alle vulnerabilità associate a qualsiasi cookie o schema di autenticazione basato su form. Il supporto passport è disabilitato per impostazione predefinita in WinHTTP; può essere abilitato tramite WinHttpSetOption.
• L'autenticazione di base deve essere usata solo tramite una connessione sicura. L'autenticazione di base, che invia il nome utente e la password in testo non crittografato (vedere RFC 2617), deve essere usata solo tramite connessioni SSL o TLS crittografate.
• L'impostazione dei criteri di accesso automatico su "bassa" può comportare un rischio. Quando il criterio di accesso automatico è impostato su basso, le credenziali di accesso di un utente possono essere usate per l'autenticazione in qualsiasi sito. Tuttavia, non è buona norma di sicurezza eseguire l'autenticazione nei siti non attendibili.
• Le connessioni SSL 2.0 non vengono usate a meno che non siano abilitate in modo esplicito. I protocolli di sicurezza TLS 1.0 e SSL 3.0 sono considerati più sicuri rispetto a SSL 2.0. Per impostazione predefinita, WinHTTP richiede TLS 1.0 o SSL 3.0 durante la negoziazione di una connessione SSL, non SSL 2.0. Il supporto SSL 2.0 in WinHTTP può essere abilitato solo chiamando WinHttpSetOption.
• Il controllo della revoca dei certificati deve essere richiesto in modo esplicito. Per impostazione predefinita, quando si esegue l'autenticazione del certificato, WinHTTP non controlla se il certificato del server è stato revocato. Il controllo delle revoche di certificati può essere abilitato tramite WinHttpSetOption.
• Le applicazioni devono assicurarsi che una sessione sia mappata a una singola identità. Una sessione WinHTTP deve essere mappata a una e una sola identità; ovvero, una sessione WinHTTP viene usata per gestire l'attività Internet di un singolo utente autenticato o un gruppo di utenti anonimi. Tuttavia, poiché WinHTTP non applica automaticamente questo mapping, l'applicazione deve eseguire i passaggi per assicurarsi che sia coinvolta solo una singola identità.
• Le operazioni su un handle di richiesta WinHTTP devono essere sincronizzate. Ad esempio, un'applicazione deve evitare di chiudere un handle di richiesta in un thread mentre un altro thread invia o riceve una richiesta. Per terminare una richiesta asincrona, chiudere l'handle della richiesta durante una notifica di callback. Per terminare una richiesta sincrona, chiudere l'handle quando viene restituita la chiamata WinHTTP precedente.
• I file di traccia contengono informazioni riservate. I file di traccia sono protetti tramite elenchi di controllo di accesso (ACL) in modo che sia possibile accedervi normalmente solo dall'amministratore locale o dall'account utente che lo ha creato. Evitare di compromettere i file di traccia da qualsiasi accesso non autorizzato.
• Evitare di passare dati sensibili tramite WinHttpSetOption. Non fornire un nome utente, una password o altre credenziali a WinHttpSetOption perché non si ha alcun controllo sullo schema di autenticazione usato e i dati sensibili potrebbero essere inviati in modo imprevisto in testo non crittografato. Usare WinHttpQueryAuthSchemes e WinHttpSetCredentials anziché WinHttpSetOption per impostare le credenziali.
• Il reindirizzamento automatico può rappresentare un rischio per la sicurezza. Per impostazione predefinita, il reindirizzamento (un messaggio 302) viene seguito automaticamente anche per un POST. Per evitare la possibilità di reindirizzamenti spuri, le applicazioni devono disabilitare il reindirizzamento automatico o monitorare di nuovo la direzione nei callback durante la pubblicazione di informazioni riservate.
• Le intestazioni definite dall'utente vengono trasferite tra reindirizzamenti invariati. Le intestazioni definite dall'utente, ad esempio i cookie aggiunti con WinHTTPAddRequestHeaders, vengono trasferite tra reindirizzamenti senza modifiche, mentre le intestazioni generate da WinHTTP vengono aggiornate automaticamente. Se il trasferimento di un'intestazione definita dall'utente tra i reindirizzamenti rappresenta un rischio per la sicurezza, usare il callback WINHTTP_STATUS_CALLBACK con il completamento WINHTTP_CALLBACK_STATUS_REDIRECT per modificare l'intestazione in questione ogni volta che si verifica un reindirizzamento.
• WinHTTP non rientra in modalità sincrona. Poiché WinHTTP non rientra in modalità sincrona, non pianificare chiamate di routine asincrone (APC) che possono chiamare in WinHTTP in un thread di applicazione che viene eseguito all'interno di una funzione WinHTTP. In modalità sincrona, WinHTTP esegue un 'attesa avvisabile', e se il thread in attesa viene pre-superato per eseguire un APC e successivamente immette nuovamente WinHTTP, lo stato interno di WinHTTP può essere danneggiato.