Udostępnij za pośrednictwem

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".

Zaufany STS powinien podpisywać żądania 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że zostać skonstruowany przez usługę tokenu zabezpieczającego (STS), której końcowa usługa sieciowa ufa w typowej wymianie. Tokeny SAML zawierają roszczenia w deklaracjach. 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 tworzenia tokenów SAML, które zezwalają na uprawnienia poza tymi, które są przeznaczone przez zaufanego 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 weryfikacji wystawcy zestawów oświadczeń generowanych poprzez uwierzytelnianie za pomocą wydanego tokenu lub użyć ustawienia weryfikacji X.509 na IssuedTokenServiceCredential w 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:

  • Procedura ustanawiania kontekstu zabezpieczeń (przy użyciu sesji zabezpieczeń transportu lub sesji zabezpieczeń komunikatów) jest wyłączona (EstablishSecurityContext właściwość jest ustawiona na false w przypadku zabezpieczeń wiadomości lub gdy transport nie może ustanowić sesji zabezpieczeń w przypadku zabezpieczeń transportu. HTTPS to jeden z przykładów takiego transportu).

  • Używasz uwierzytelniania systemu Windows.

  • Nie ustawiasz jawnie poświadczenia.

  • 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 kontekście wątku. Poświadczenia są uzyskiwane, gdy metoda klienta lub usługi Open (lub BeginOpen dla wywołań asynchronicznych) jest wywoływana. Zarówno metody ServiceHost i ClientBase<TChannel> klas Open i BeginOpen dziedziczą z metod Open i BeginOpen klasy CommunicationObject.

Uwaga / Notatka

W przypadku używania metody BeginOpen nie ma gwarancji, że przechwycone poświadczenia są poświadczeniami procesu, który wywołuje tę metodę.

Bufory tokenów umożliwiają ponowne użycie 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 do późniejszego użytku. Ten mechanizm jest domyślnie wyłączony; aby ją włączyć, ustaw CacheLogonTokens właściwość na true, lub użyj cacheLogonTokens atrybutu <userNameAuthentication>.

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 TTL nie minie i token nie zostanie usunięty z pamięci podręcznej, program WCF umożliwia użytkownikowi (prawdopodobnie złośliwemu) uwierzytelnienie.

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 właściwość ExpirationTimeAuthorizationContext może być ustawiona na nieoczekiwanie większą wartość (wartość pola MaxValue pomniejszona o 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 WCF odbierze komunikat i zweryfikuje podpis, mapuje informacje w nieplanowanym certyfikacie X.509 na zestaw oświadczeń, które są różne i potencjalnie wyższe od tego, czego oczekiwał klient.

Aby temu zapobiec, należy odwołać się do certyfikatu X.509 w inny sposób, na przykład przy użyciu polecenia IssuerSerial.

Zobacz także