Oprogramowanie pośredniczące ASP.NET Core OpenId Połączenie umożliwia aplikacji przechwycenie wywołania punktu końcowego wylogowania Platforma tożsamości Microsoft przez podanie zdarzenia OpenId Połączenie o nazwieOnRedirectToIdentityProviderForSignOut
Używanie okresów istnienia skończonych dla wygenerowanych tokenów SaS
Stanowisko
Szczegóły
Składnik
Urządzenie IoT
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny element
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Tokeny saS wygenerowane na potrzeby uwierzytelniania w usłudze Azure IoT Hub powinny mieć skończony okres wygaśnięcia. Zachowaj okresy istnienia tokenu saS do minimum, aby ograniczyć czas ich odtwarzania w przypadku naruszenia zabezpieczeń tokenów.
Używanie minimalnych okresów istnienia tokenów dla wygenerowanych tokenów zasobów
Stanowisko
Szczegóły
Składnik
Azure Document DB
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny element
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Zmniejsz przedział czasu tokenu zasobu do minimalnej wymaganej wartości. Tokeny zasobów mają domyślny przedział czasu 1 godziny.
Implementowanie prawidłowego wylogowywania przy użyciu metod WsFederation podczas korzystania z usług ADFS
Stanowisko
Szczegóły
Składnik
Program ADFS
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny element
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Jeśli aplikacja korzysta z tokenu STS wystawionego przez usługę ADFS, program obsługi zdarzeń wylogowywania powinien wywołać metodę WSFederationAuthenticationModule.FederatedSignOut(), aby wylogować użytkownika. Ponadto bieżąca sesja powinna zostać zniszczona, a wartość tokenu sesji powinna zostać zresetowana i unieważniona.
Przykład
[HttpPost, ValidateAntiForgeryToken]
[Authorization]
public ActionResult SignOut(string redirectUrl)
{
if (!this.User.Identity.IsAuthenticated)
{
return this.View("LogOff", null);
}
// Removes the user profile.
this.Session.Clear();
this.Session.Abandon();
HttpContext.Current.Response.Cookies.Add(new System.Web.HttpCookie("ASP.NET_SessionId", string.Empty)
{
Expires = DateTime.Now.AddDays(-1D),
Secure = true,
HttpOnly = true
});
// Signs out at the specified security token service (STS) by using the WS-Federation protocol.
Uri signOutUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Issuer);
Uri replyUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Realm);
if (!string.IsNullOrEmpty(redirectUrl))
{
replyUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Realm + redirectUrl);
}
// Signs out of the current session and raises the appropriate events.
var authModule = FederatedAuthentication.WSFederationAuthenticationModule;
authModule.SignOut(false);
// Signs out at the specified security token service (STS) by using the WS-Federation
// protocol.
WSFederationAuthenticationModule.FederatedSignOut(signOutUrl, replyUrl);
return new RedirectResult(redirectUrl);
}
Implementowanie prawidłowego wylogowywanie podczas korzystania z serwera tożsamości
Usługa IdentityServer obsługuje możliwość federacji z zewnętrznymi dostawcami tożsamości. Gdy użytkownik wy wylogował się z nadrzędnego dostawcy tożsamości, w zależności od używanego protokołu, może być możliwe otrzymanie powiadomienia po wylogowaniu użytkownika. Dzięki temu usługa IdentityServer może powiadamiać swoich klientów, aby mogli również wylogować użytkownika. Zapoznaj się z dokumentacją w sekcji referencyjnej, aby uzyskać szczegółowe informacje o implementacji.
Aplikacje dostępne za pośrednictwem protokołu HTTPS muszą używać bezpiecznych plików cookie
Pliki cookie są zwykle dostępne tylko dla domeny, dla której zostały objęte zakresem. Niestety definicja "domeny" nie zawiera protokołu, więc pliki cookie tworzone za pośrednictwem protokołu HTTPS są dostępne za pośrednictwem protokołu HTTP. Atrybut "secure" wskazuje przeglądarce, że plik cookie powinien być udostępniany tylko za pośrednictwem protokołu HTTPS. Upewnij się, że wszystkie pliki cookie ustawione za pośrednictwem protokołu HTTPS używają bezpiecznego atrybutu. Wymaganie można wymusić w pliku web.config, ustawiając atrybut requireSSL na true. Jest to preferowane podejście, ponieważ wymusza bezpieczny atrybut dla wszystkich bieżących i przyszłych plików cookie bez konieczności wprowadzania dodatkowych zmian w kodzie.
To ustawienie jest wymuszane, nawet jeśli protokół HTTP jest używany do uzyskiwania dostępu do aplikacji. Jeśli protokół HTTP jest używany do uzyskiwania dostępu do aplikacji, ustawienie powoduje przerwanie aplikacji, ponieważ pliki cookie są ustawione za pomocą bezpiecznego atrybutu, a przeglądarka nie wyśle ich z powrotem do aplikacji.
Stanowisko
Szczegóły
Składnik
Aplikacja internetowa
Faza SDL
Kompilacja
Odpowiednie technologie
Web Forms, MVC5
Atrybuty
EnvironmentType — OnPrem
Dokumentacja
Nie dotyczy
Kroki
Gdy aplikacja internetowa jest stroną uzależnioną, a dostawcą tożsamości jest serwer usługi ADFS, można skonfigurować bezpieczny atrybut tokenu FedAuth, ustawiając właściwość requireSSL na True w system.identityModel.services sekcji web.config:
Przykład
<system.identityModel.services>
<federationConfiguration>
<!-- Set requireSsl=true; domain=application domain name used by FedAuth cookies (Ex: .gdinfra.com); -->
<cookieHandler requireSsl="true" persistentSessionLifetime="0.0:20:0" />
....
</federationConfiguration>
</system.identityModel.services>
Wszystkie aplikacje oparte na protokole HTTP powinny określać tylko dla definicji plików cookie
Aby ograniczyć ryzyko ujawnienia informacji za pomocą ataku skryptów między witrynami (XSS), nowy atrybut — httpOnly — został wprowadzony do plików cookie i jest obsługiwany przez wszystkie główne przeglądarki. Atrybut określa, że plik cookie nie jest dostępny za pośrednictwem skryptu. Korzystając z plików cookie HttpOnly, aplikacja internetowa zmniejsza możliwość kradzieży poufnych informacji zawartych w pliku cookie za pośrednictwem skryptu i wysłania ich do witryny internetowej osoby atakującej.
Przykład
Wszystkie aplikacje oparte na protokole HTTP korzystające z plików cookie powinny określać wartość HttpOnly w definicji pliku cookie, implementując następującą konfigurację w pliku web.config:
Wartość właściwości RequireSSL jest ustawiana w pliku konfiguracji dla aplikacji ASP.NET przy użyciu atrybutu requireSSL elementu konfiguracji. Możesz określić w pliku Web.config dla aplikacji ASP.NET, czy protokół Transport Layer Security (TLS), wcześniej znany jako SSL (Secure Sockets Layer), jest wymagany do zwrócenia pliku cookie uwierzytelniania formularzy do serwera, ustawiając atrybut requireSSL.
Przykład
Poniższy przykład kodu ustawia atrybut requireSSL w pliku Web.config.
Eliminowanie ataków fałszerzowania żądań między witrynami (CSRF) na ASP.NET stronach internetowych
Stanowisko
Szczegóły
Składnik
Aplikacja internetowa
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny element
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Fałszerzować żądania obejmujące wiele witryn (CSRF lub XSRF) to rodzaj ataku, w którym osoba atakująca może wykonywać akcje w kontekście zabezpieczeń sesji innego użytkownika w witrynie internetowej. Celem jest zmodyfikowanie lub usunięcie zawartości, jeśli docelowa witryna internetowa opiera się wyłącznie na plikach cookie sesji w celu uwierzytelnienia odebranych żądań. Osoba atakująca może wykorzystać tę lukę w zabezpieczeniach, uzyskując przeglądarkę innego użytkownika w celu załadowania adresu URL za pomocą polecenia z witryny podatnej na zagrożenia, w której użytkownik jest już zalogowany. Istnieje wiele sposobów na to, aby osoba atakująca to zrobiła, na przykład hostując inną witrynę internetową, która ładuje zasób z serwera podatnego na zagrożenia lub umożliwiając użytkownikowi kliknięcie linku. Atak może być blokowany, jeśli serwer wysyła dodatkowy token do klienta, wymaga, aby klient uwzględnił ten token we wszystkich przyszłych żądaniach i sprawdza, czy wszystkie przyszłe żądania zawierają token odnoszący się do bieżącej sesji, na przykład przy użyciu ASP.NET AntiForgeryToken lub ViewState.
Anty-CSRF i ASP.NET formularzy MVC — użyj metody pomocniczej AntiForgeryToken w widokach; na przykład umieść element Html.AntiForgeryToken() w formularzu
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Przykład
Jednocześnie html.AntiForgeryToken() udostępnia odwiedzającym plik cookie o nazwie __RequestVerificationToken z taką samą wartością jak losowa wartość ukryta pokazana powyżej. Następnie, aby zweryfikować wpis formularza przychodzącego, dodaj filtr [ValidateAntiForgeryToken] do metody akcji docelowej. Przykład:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Filtr autoryzacji sprawdzający, czy:
Żądanie przychodzące ma plik cookie o nazwie __RequestVerificationToken
Żądanie przychodzące ma Request.Form wpis o nazwie __RequestVerificationToken
Te pliki cookie i Request.Form wartości są zgodne przy założeniu, że wszystko jest dobrze, żądanie przechodzi tak normalnie. Jeśli tak nie jest, to błąd autoryzacji z komunikatem "Wymagany token ochrony przed fałszerstwom nie został podany lub był nieprawidłowy".
Przykład
Anti-CSRF i AJAX: token formularza może być problemem dla żądań AJAX, ponieważ żądanie AJAX może wysyłać dane JSON, a nie dane formularza HTML. Jednym z rozwiązań jest wysłanie tokenów w niestandardowym nagłówku HTTP. Poniższy kod używa składni Razor do generowania tokenów, a następnie dodaje tokeny do żądania AJAX.
<script>
@functions{
public string TokenHeaderValue()
{
string cookieToken, formToken;
AntiForgery.GetTokens(null, out cookieToken, out formToken);
return cookieToken + ":" + formToken;
}
}
$.ajax("api/values", {
type: "post",
contentType: "application/json",
data: { }, // JSON data goes here
dataType: "json",
headers: {
'RequestVerificationToken': '@TokenHeaderValue()'
}
});
</script>
Przykład
Podczas przetwarzania żądania wyodrębnij tokeny z nagłówka żądania. Następnie wywołaj metodę AntiForgery.Validate, aby zweryfikować tokeny. Metoda Validate zgłasza wyjątek, jeśli tokeny są nieprawidłowe.
Ataki CSRF w aplikacjach opartych na formach WebForm można ograniczyć, ustawiając wartość ViewStateUserKey na losowy ciąg, który różni się dla każdego użytkownika — identyfikator użytkownika lub, jeszcze lepiej, identyfikator sesji. Z wielu powodów technicznych i społecznościowych identyfikator sesji jest znacznie lepszy, ponieważ identyfikator sesji jest nieprzewidywalny, limit czasu i różni się w zależności od użytkownika.
Przykład
Oto kod, który musisz mieć na wszystkich stronach:
Limit czasu sesji reprezentuje zdarzenie występujące, gdy użytkownik nie wykonuje żadnej akcji w witrynie internetowej w interwale (zdefiniowanym przez serwer internetowy). Zdarzenie po stronie serwera zmienia stan sesji użytkownika na "nieprawidłowy" (na przykład "nie jest już używany") i poinstruuj serwer internetowy, aby go zniszczył (usunięcie wszystkich zawartych w nim danych). Poniższy przykład kodu ustawia atrybut sesji limitu czasu na 15 minut w pliku Web.config.
Gdy aplikacja internetowa jest stroną uzależnioną, a usługi ADFS są usługą STS, okres istnienia plików cookie uwierzytelniania — tokeny FedAuth — można ustawić przez następującą konfigurację w pliku web.config:
Przykład
<system.identityModel.services>
<federationConfiguration>
<!-- Set requireSsl=true; domain=application domain name used by FedAuth cookies (Ex: .gdinfra.com); -->
<cookieHandler requireSsl="true" persistentSessionLifetime="0.0:15:0" />
<!-- Set requireHttps=true; -->
<wsFederation passiveRedirectEnabled="true" issuer="http://localhost:39529/" realm="https://localhost:44302/" reply="https://localhost:44302/" requireHttps="true"/>
<!--
Use the code below to enable encryption-decryption of claims received from ADFS. Thumbprint value varies based on the certificate being used.
<serviceCertificate>
<certificateReference findValue="4FBBBA33A1D11A9022A5BF3492FF83320007686A" storeLocation="LocalMachine" storeName="My" x509FindType="FindByThumbprint" />
</serviceCertificate>
-->
</federationConfiguration>
</system.identityModel.services>
Przykład
Ponadto okres istnienia tokenu oświadczeń SAML wystawiony przez usługę ADFS powinien być ustawiony na 15 minut, wykonując następujące polecenie programu PowerShell na serwerze usług AD FS:
Implementowanie prawidłowego wylogowywanie z aplikacji
Stanowisko
Szczegóły
Składnik
Aplikacja internetowa
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny element
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Wykonaj odpowiednie wylogowywanie z aplikacji, gdy użytkownik naciska przycisk wylogowania. Po wylogowaniu aplikacja powinna zniszczyć sesję użytkownika, a także zresetować i unieważnić wartość pliku cookie sesji, a także zresetować i unieważnić wartość pliku cookie uwierzytelniania. Ponadto, gdy wiele sesji jest powiązanych z jedną tożsamością użytkownika, musi zostać zbiorczo przerwane po stronie serwera przy przekroczeniu limitu czasu lub wylogowaniu. Na koniec upewnij się, że funkcja wylogowywanie jest dostępna na każdej stronie.
Eliminowanie ataków fałszerzowania żądań między witrynami (CSRF) na ASP.NET internetowych interfejsach API
Stanowisko
Szczegóły
Składnik
Internetowy interfejs API
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny element
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Fałszerzować żądania obejmujące wiele witryn (CSRF lub XSRF) to rodzaj ataku, w którym osoba atakująca może wykonywać akcje w kontekście zabezpieczeń sesji innego użytkownika w witrynie internetowej. Celem jest zmodyfikowanie lub usunięcie zawartości, jeśli docelowa witryna internetowa opiera się wyłącznie na plikach cookie sesji w celu uwierzytelnienia odebranych żądań. Osoba atakująca może wykorzystać tę lukę w zabezpieczeniach, uzyskując przeglądarkę innego użytkownika w celu załadowania adresu URL za pomocą polecenia z witryny podatnej na zagrożenia, w której użytkownik jest już zalogowany. Istnieje wiele sposobów na to, aby osoba atakująca to zrobiła, na przykład hostując inną witrynę internetową, która ładuje zasób z serwera podatnego na zagrożenia lub umożliwiając użytkownikowi kliknięcie linku. Atak może być blokowany, jeśli serwer wysyła dodatkowy token do klienta, wymaga, aby klient uwzględnił ten token we wszystkich przyszłych żądaniach i sprawdza, czy wszystkie przyszłe żądania zawierają token odnoszący się do bieżącej sesji, na przykład przy użyciu ASP.NET AntiForgeryToken lub ViewState.
Anti-CSRF i AJAX: token formularza może być problemem dla żądań AJAX, ponieważ żądanie AJAX może wysyłać dane JSON, a nie dane formularza HTML. Jednym z rozwiązań jest wysłanie tokenów w niestandardowym nagłówku HTTP. Poniższy kod używa składni Razor do generowania tokenów, a następnie dodaje tokeny do żądania AJAX.
Przykład
<script>
@functions{
public string TokenHeaderValue()
{
string cookieToken, formToken;
AntiForgery.GetTokens(null, out cookieToken, out formToken);
return cookieToken + ":" + formToken;
}
}
$.ajax("api/values", {
type: "post",
contentType: "application/json",
data: { }, // JSON data goes here
dataType: "json",
headers: {
'RequestVerificationToken': '@TokenHeaderValue()'
}
});
</script>
Przykład
Podczas przetwarzania żądania wyodrębnij tokeny z nagłówka żądania. Następnie wywołaj metodę AntiForgery.Validate, aby zweryfikować tokeny. Metoda Validate zgłasza wyjątek, jeśli tokeny są nieprawidłowe.
Formularze anti-CSRF i ASP.NET MVC — użyj metody pomocnika AntiForgeryToken w widokach; umieść element Html.AntiForgeryToken() w formularzu, na przykład
W powyższym przykładzie zostaną wyświetlone dane wyjściowe podobne do następujących:
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Przykład
Jednocześnie html.AntiForgeryToken() udostępnia odwiedzającym plik cookie o nazwie __RequestVerificationToken z taką samą wartością jak losowa wartość ukryta pokazana powyżej. Następnie, aby zweryfikować wpis formularza przychodzącego, dodaj filtr [ValidateAntiForgeryToken] do metody akcji docelowej. Przykład:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Filtr autoryzacji sprawdzający, czy:
Żądanie przychodzące ma plik cookie o nazwie __RequestVerificationToken
Żądanie przychodzące ma Request.Form wpis o nazwie __RequestVerificationToken
Te pliki cookie i Request.Form wartości są zgodne przy założeniu, że wszystko jest dobrze, żądanie przechodzi tak normalnie. Jeśli tak nie jest, to błąd autoryzacji z komunikatem "Wymagany token ochrony przed fałszerstwom nie został podany lub był nieprawidłowy".
Stanowisko
Szczegóły
Składnik
Internetowy interfejs API
Faza SDL
Kompilacja
Odpowiednie technologie
MVC5, MVC6
Atrybuty
Dostawca tożsamości — ADFS, dostawca tożsamości — identyfikator entra firmy Microsoft
Jeśli internetowy interfejs API jest zabezpieczony przy użyciu protokołu OAuth 2.0, oczekuje tokenu elementu nośnego w nagłówku żądania autoryzacji i udziela dostępu do żądania tylko wtedy, gdy token jest prawidłowy. W przeciwieństwie do uwierzytelniania opartego na plikach cookie przeglądarki nie dołączają tokenów elementu nośnego do żądań. Klient żądający musi jawnie dołączyć token elementu nośnego w nagłówku żądania. W związku z tym w przypadku ASP.NET internetowych interfejsów API chronionych przy użyciu protokołu OAuth 2.0 tokeny elementu nośnego są uznawane za obronę przed atakami CSRF. Należy pamiętać, że jeśli część MVC aplikacji używa uwierzytelniania formularzy (tj. używa plików cookie), tokeny ochrony przed fałszerzami muszą być używane przez aplikację internetową MVC.
Przykład
Internetowy interfejs API musi być informowany, aby polegać tylko na tokenach elementu nośnego, a nie na plikach cookie. Można to zrobić za pomocą następującej konfiguracji w WebApiConfig.Register metodzie:
Metoda SuppressDefaultHostAuthentication informuje internetowy interfejs API o ignorowaniu uwierzytelniania, które ma miejsce przed dotarciem żądania do potoku internetowego interfejsu API przez usługi IIS lub oprogramowanie pośredniczące OWIN. Dzięki temu możemy ograniczyć internetowy interfejs API do uwierzytelniania tylko przy użyciu tokenów elementu nośnego.