Zagadnienia dotyczące zabezpieczeń WinHTTP

Następujące zagadnienia dotyczące zabezpieczeń dotyczą aplikacji korzystających z winHTTP:

• Certyfikaty serwera są weryfikowane tylko raz na sesję. Po zweryfikowaniu certyfikatu pozostaje on ważny przez czas trwania bieżącej sesji. Jeśli odcisk palca certyfikatu jest zgodny, co oznacza, że certyfikat nie uległ zmianie, certyfikat będzie nadal ponownie weryfikowany. W związku z tym wszelkie zmiany kryteriów weryfikacji za pośrednictwem protokołu, sprawdzania odwołania lub flagi ignoruj błędy certyfikatu nie zostaną zastosowane po zweryfikowaniu certyfikatu. Aby wymusić natychmiastowe wprowadzenie takiej zmiany, należy zakończyć bieżącą sesję i rozpocząć nową. Podobnie wygaśnięcie certyfikatu w trakcie sesji można wykryć tylko wtedy, gdy sama aplikacja okresowo sprawdza serwer certyfikatów w celu pobrania danych wygaśnięcia.
• Automatyczny serwer proxy obejmuje pobieranie i wykonywanie skryptów. Obsługa automatycznego odnajdywania serwera proxy obejmuje wykrywanie za pośrednictwem protokołu DHCP lub DNS, pobieranie i wykonywanie skryptów serwera proxy, takich jak skrypty języka Java. Aby osiągnąć wyższy stopień zabezpieczeń, aplikacja musi unikać przekazywania flagi WINHTTP_AUTOPROXY_RUN_INPROCESS, aby automatyczne odnajdywanie serwera proxy zostało zainicjowane poza procesem. Nawet wtedy winHTTP próbuje domyślnie uruchomić skrypt automatycznego serwera proxy w procesie, jeśli skrypt nie będzie działać prawidłowo poza procesem. Jeśli uważasz, że to zachowanie rezerwowe stanowi niedopuszczalne ryzyko, wyłącz zachowanie rezerwowe z flagą WINHTTP_AUTOPROXY_RUN_OUTPROCESS_ONLY.
• WINHTTP_STATUS_CALLBACK funkcje muszą zostać zwrócone szybko. Podczas pisania jednej z tych funkcji wywołania zwrotnego należy zachować ostrożność, że nie blokuje. Na przykład wywołanie zwrotne ani żadna wywoływana funkcja nie powinna wyświetlać okna dialogowego użytkownika ani czekać na zdarzenie. Jeśli funkcja WINHTTP_STATUS_CALLBACK blokuje, ma wpływ na wewnętrzne planowanie WinHTTP i powoduje, że inne żądania w ramach tego samego procesu zostaną odrzucone.
• WINHTTP_STATUS_CALLBACK funkcje muszą być ponowne. Podczas pisania wywołania zwrotnego należy unikać zmiennych statycznych lub innych konstrukcji, które są niebezpieczne w ramach ponownej instalacji, i unikać wywoływania innych funkcji, które nie są powtarzane.
• Jeśli operacja asynchroniczna jest możliwa, przekaż listy NUL dla parametrów OUT. Jeśli włączono operację asynchroniczną, rejestrując funkcję wywołania zwrotnego, zawsze przekazuj wartości NULL dla takich parametrów OUT, jak lpdwDataAvailable dla WinHttpQueryDataAvailable, lpdwBytesReadRead dla winHttpReadDatalub lpdwBytesWritten dla WinHttpWriteData. W niektórych okolicznościach wątek wywołujący jest przerywany przed zakończeniem operacji, a jeśli parametry OUT nie są null, funkcja może zakończyć zapisywanie w pamięci, która została już zwolniona.
• Uwierzytelnianie za pomocą paszportu nie jest niezawodne. Każdy schemat uwierzytelniania oparty na plikach cookie jest podatny na ataki. Usługa Passport w wersji 1.4 jest oparta na plikach cookie i dlatego podlega lukom w zabezpieczeniach skojarzonym z dowolnym schematem uwierzytelniania opartym na plikach cookie lub formularzach. Obsługa usługi Passport jest domyślnie wyłączona w aplikacji WinHTTP; można ją włączyć za pomocą WinHttpSetOption.
• Uwierzytelnianie podstawowe powinno być używane tylko za pośrednictwem bezpiecznego połączenia. Uwierzytelnianie podstawowe, które wysyła nazwę użytkownika i hasło w postaci zwykłego tekstu (zobacz RFC 2617), należy używać tylko za pośrednictwem szyfrowanych połączeń SSL lub TLS.
• Ustawienie zasad automatycznego logowania na "niskie" może stanowić ryzyko. Gdy zasady automatycznego logowania są ustawione na niski, poświadczenia logowania użytkownika mogą służyć do uwierzytelniania w dowolnej witrynie. Jednak nie jest dobrym rozwiązaniem w zakresie zabezpieczeń uwierzytelniania w witrynach, którym nie ufasz.
• Połączenia SSL 2.0 nie są używane, chyba że jawnie włączone. Protokoły zabezpieczeń TLS 1.0 i SSL 3.0 są uważane za bezpieczniejsze niż SSL 2.0. Domyślnie usługa WinHTTP żąda protokołu TLS 1.0 lub SSL 3.0 podczas negocjowania połączenia SSL, a nie SSL 2.0. Obsługa protokołu SSL 2.0 w winHTTP może być włączona tylko przez wywołanie WinHttpSetOption.
• Należy jawnie zażądać sprawdzania odwołania certyfikatów. Domyślnie podczas przeprowadzania uwierzytelniania certyfikatu winHTTP nie sprawdza, czy certyfikat serwera został odwołany. Sprawdzanie odwołania certyfikatów można włączyć przy użyciu WinHttpSetOption.
• Aplikacje muszą zapewnić, że sesja jest mapowania na jedną tożsamość. Sesja WinHTTP powinna być mapowa na jedną i tylko jedną tożsamość; oznacza to, że sesja WinHTTP służy do zarządzania aktywnością internetową pojedynczego uwierzytelnionego użytkownika lub grupy użytkowników anonimowych. Jednak ze względu na to, że winHTTP nie wymusza tego mapowania automatycznie, aplikacja musi wykonać kroki, aby upewnić się, że tylko jedna tożsamość jest zaangażowana.
• Operacje na dojściu żądania WinHTTP powinny być synchronizowane. Na przykład aplikacja powinna unikać zamykania uchwytu żądania w jednym wątku, gdy inny wątek wysyła lub odbiera żądanie. Aby zakończyć żądanie asynchroniczne, zamknij dojście żądania podczas powiadomienia zwrotnego wywołania zwrotnego. Aby zakończyć żądanie synchroniczne, zamknij uchwyt po powrocie poprzedniego wywołania WinHTTP.
• Pliki śledzenia zawierają poufne informacje. Pliki śledzenia są chronione przy użyciu list Access-Control (ACL), dzięki czemu można uzyskać do nich dostęp tylko przez administratora lokalnego lub przez konto użytkownika, które je utworzyło. Unikaj naruszania plików śledzenia przez nieautoryzowany dostęp.
• Unikaj przekazywania poufnych danych za pośrednictwemWinHttpSetOption. Nie należy podawać nazwy użytkownika, hasła ani innych poświadczeń do WinHttpSetOption, ponieważ nie masz kontroli nad używanym schematem uwierzytelniania, a poufne dane mogą zostać nieoczekiwanie wysłane w postaci zwykłego tekstu. Użyj WinHttpQueryAuthSchemes i WinHttpSetCredentials zamiast WinHttpSetOption do ustawiania poświadczeń.
• Automatyczne przekierowywanie może stanowić zagrożenie bezpieczeństwa. Domyślnie przekierowywanie (komunikat 302) jest wykonywane automatycznie nawet dla wpisu POST. Aby uniknąć możliwości fałszywych przekierowań, aplikacje powinny wyłączyć automatyczne przekierowywanie lub monitorować ponownie kierunek wywołań zwrotnych podczas publikowania poufnych informacji.
• Nagłówki zdefiniowane przez użytkownika są przenoszone między przekierowaniami bez zmian. Nagłówki zdefiniowane przez użytkownika, takie jak pliki cookie dodane za pomocą WinHTTPAddRequestHeaders, są przesyłane między przekierowaniami bez modyfikacji, podczas gdy nagłówki generowane przez WinHTTP są automatycznie aktualizowane. Jeśli przeniesienie nagłówka zdefiniowanego przez użytkownika między przekierowaniami stanowi zagrożenie bezpieczeństwa, użyj wywołania zwrotnego WINHTTP_STATUS_CALLBACK z ukończeniem WINHTTP_CALLBACK_STATUS_REDIRECT, aby zmodyfikować nagłówek, o który chodzi, gdy nastąpi przekierowanie.
• WinHTTP nie jest reentrant w trybie synchronicznym. Ponieważ WinHTTP nie jest reentrant w trybie synchronicznym, nie należy planować asynchronicznych wywołań procedur (APC), które mogą wywoływać do WinHTTP w wątku aplikacji, który jest wykonywany wewnątrz funkcji WinHTTP. W trybie synchronicznym winHTTP wykonuje "oczekiwanie na alerty", a jeśli wątek oczekiwania jest wstępnie wycopowywane w celu wykonania APC, a następnie ponownie wprowadza winHTTP ponownie, stan wewnętrzny WinHTTP może być uszkodzony.