Elevation of Privilege (podniesienie uprawnień)
Podniesienie uprawnień wynika z nadania osobie atakującej uprawnień autoryzacji wykraczających poza te, które początkowo udzielono. Na przykład osoba atakująca z zestawem uprawnień "tylko do odczytu" w jakiś sposób podnosi poziom zestawu, aby uwzględnić "odczyt i zapis".
Zaufane usługi STS powinny podpisywać oświadczenia tokenu SAML
Token języka SAML (Security Assertions Markup Language) to ogólny token XML, który jest domyślnym typem wystawionych tokenów. Token SAML można skonstruować za pomocą usługi tokenu zabezpieczającego (STS), która ufa końcowej usłudze sieci Web w typowej wymiany. Tokeny SAML zawierają oświadczenia w instrukcjach. Osoba atakująca może skopiować oświadczenia z prawidłowego tokenu, utworzyć nowy token SAML i podpisać je za pomocą innego wystawcy. Celem jest określenie, czy serwer sprawdza poprawność wystawców, a jeśli nie, wykorzystać słabość do konstruowania tokenów SAML, które zezwalają na uprawnienia poza tymi, które są przeznaczone przez zaufane usługi STS.
Klasa SamlAssertion weryfikuje podpis cyfrowy zawarty w tokenie SAML, a ustawienie domyślne SamlSecurityTokenAuthenticator wymaga podpisania tokenów SAML przez certyfikat X.509, który jest prawidłowy, gdy CertificateValidationModeIssuedTokenServiceCredential klasa ma wartość ChainTrust. ChainTrust sam tryb jest niewystarczający do określenia, czy wystawca tokenu SAML jest zaufany. Usługi, które wymagają bardziej szczegółowego modelu zaufania, mogą używać zasad autoryzacji i wymuszania w celu sprawdzenia wystawcy zestawów oświadczeń generowanych przez uwierzytelnianie tokenu wystawionego lub użyć ustawień weryfikacji X.509 w IssuedTokenServiceCredential celu ograniczenia zestawu dozwolonych certyfikatów podpisywania. Aby uzyskać więcej informacji, zobacz Zarządzanie oświadczeniami i autoryzacją za pomocą modelu tożsamości i federacji i wystawionych tokenów.
Przełączanie tożsamości bez kontekstu zabezpieczeń
Poniższe zasady dotyczą tylko systemu WinFX.
Po nawiązaniu połączenia między klientem a serwerem tożsamość klienta nie zmienia się, z wyjątkiem jednej sytuacji: po otwarciu klienta programu WCF, jeśli spełnione są wszystkie następujące warunki:
Procedury ustanawiania kontekstu zabezpieczeń (przy użyciu sesji zabezpieczeń transportu lub sesji zabezpieczeń komunikatów) są wyłączone (EstablishSecurityContext właściwość jest ustawiona
falsew przypadku zabezpieczeń wiadomości lub transportu, który nie może ustanowić sesji zabezpieczeń, jest używany w przypadku zabezpieczeń transportu. HTTPS to jeden z przykładów takiego transportu.Używasz uwierzytelniania systemu Windows.
Nie ustawiasz jawnie poświadczeń.
Wywołujesz usługę w ramach personifikowanego kontekstu zabezpieczeń.
Jeśli te warunki są prawdziwe, tożsamość używana do uwierzytelniania klienta w usłudze może ulec zmianie (może to nie być tożsamość personifikowana, ale tożsamość procesu) po otwarciu klienta programu WCF. Dzieje się tak, ponieważ poświadczenia systemu Windows używane do uwierzytelniania klienta w usłudze są przesyłane z każdym komunikatem, a poświadczenia używane do uwierzytelniania są uzyskiwane z tożsamości systemu Windows bieżącego wątku. Jeśli tożsamość systemu Windows bieżącego wątku ulegnie zmianie (na przykład przez personifikację innego obiektu wywołującego), poświadczenie dołączone do komunikatu i użyte do uwierzytelnienia klienta w usłudze może również ulec zmianie.
Jeśli chcesz mieć deterministyczne zachowanie podczas korzystania z uwierzytelniania systemu Windows razem z personifikacją, musisz jawnie ustawić poświadczenia systemu Windows lub ustanowić kontekst zabezpieczeń z usługą. W tym celu należy użyć sesji zabezpieczeń komunikatów lub sesji zabezpieczeń transportu. Na przykład transport net.tcp może zapewnić sesję zabezpieczeń transportu. Ponadto podczas wywoływania usługi należy używać tylko synchronicznej wersji operacji klienta. W przypadku ustanowienia kontekstu zabezpieczeń komunikatów połączenie z usługą nie powinno być otwarte dłużej niż skonfigurowany okres odnawiania sesji, ponieważ tożsamość może również ulec zmianie podczas procesu odnawiania sesji.
Przechwytywanie poświadczeń
Poniższe zasady dotyczą programu .NET Framework 3.5 i kolejnych wersji.
Poświadczenia używane przez klienta lub usługę są oparte na bieżącym wątku kontekstu. Poświadczenia są uzyskiwane, gdy Open wywoływana jest metoda (lub BeginOpen, dla wywołań asynchronicznych) klienta lub usługi. ServiceHost Zarówno dla klas, jak i ClientBase<TChannel> metody Open i BeginOpen dziedziczą z Open metod CommunicationObject i klasy .BeginOpen
Uwaga
W przypadku używania BeginOpen metody przechwycone poświadczenia nie mogą być poświadczeniami procesu, który wywołuje metodę.
Pamięci podręczne tokenów umożliwiają odtwarzanie przy użyciu przestarzałych danych
Program WCF używa funkcji lokalnego urzędu zabezpieczeń (LSA) LogonUser do uwierzytelniania użytkowników według nazwy użytkownika i hasła. Ponieważ funkcja logowania jest kosztowną operacją, program WCF umożliwia buforowanie tokenów reprezentujących uwierzytelnionych użytkowników w celu zwiększenia wydajności. Mechanizm buforowania zapisuje wyniki z LogonUser kolejnych zastosowań. Ten mechanizm jest domyślnie wyłączony; aby ją włączyć, ustaw właściwość na , lub użyj cacheLogonTokens atrybutu <userNameAuthentication>.trueCacheLogonTokens
Dla buforowanych tokenów można ustawić czas wygaśnięcia (TTL), ustawiając CachedLogonTokenLifetime właściwość na TimeSpanwartość , lub używając cachedLogonTokenLifetime atrybutu userNameAuthentication elementu. Wartość domyślna to 15 minut. Należy pamiętać, że podczas buforowania tokenu każdy klient, który przedstawia tę samą nazwę użytkownika i hasło, może użyć tokenu, nawet jeśli konto użytkownika zostanie usunięte z systemu Windows lub jeśli hasło zostało zmienione. Dopóki czas wygaśnięcia nie wygaśnie i token zostanie usunięty z pamięci podręcznej, program WCF zezwala użytkownikowi (prawdopodobnie złośliwemu) na uwierzytelnianie.
Aby rozwiązać ten problem: Zmniejsz okno ataku, ustawiając cachedLogonTokenLifetime wartość na najkrótszy przedział czasu potrzebny użytkownikom.
Wystawiona autoryzacja tokenu: resetowanie wygaśnięcia do dużej wartości
W pewnych warunkach ExpirationTime właściwość AuthorizationContext obiektu może być ustawiona na nieoczekiwanie większą wartość ( MaxValue wartość pola minus jeden dzień lub 20 grudnia 9999).
Dzieje się tak w przypadku używania WSFederationHttpBinding i dowolnych powiązań dostarczonych przez system, które mają wystawiony token jako typ poświadczeń klienta.
Dzieje się tak również w przypadku tworzenia powiązań niestandardowych przy użyciu jednej z następujących metod:
Aby temu zapobiec, zasady autoryzacji muszą sprawdzać akcję i czas wygaśnięcia poszczególnych zasad autoryzacji.
Usługa używa innego certyfikatu niż zamierzony klient
W pewnych warunkach klient może cyfrowo podpisać komunikat przy użyciu certyfikatu X.509 i pobrać inny certyfikat niż zamierzony.
Może się to zdarzyć w następujących okolicznościach:
Klient podpisuje cyfrowo komunikat przy użyciu certyfikatu X.509 i nie dołącza certyfikatu X.509 do komunikatu, ale raczej odwołuje się do certyfikatu przy użyciu jego identyfikatora klucza podmiotu.
Komputer usługi zawiera co najmniej dwa certyfikaty z tym samym kluczem publicznym, ale zawierają różne informacje.
Usługa pobiera certyfikat zgodny z identyfikatorem klucza podmiotu, ale nie jest tym, którego klient zamierza użyć. Gdy program WCF odbierze komunikat i zweryfikuje podpis, program WCF mapuje informacje w niezamierzonym certyfikacie X.509 na zestaw oświadczeń, które są różne i potencjalnie podniesione od oczekiwanego klienta.
Aby temu zapobiec, należy odwołać się do certyfikatu X.509 w inny sposób, na przykład przy użyciu polecenia IssuerSerial.