ПО промежуточного слоя ASP.NET Core OpenId Подключение позволяет приложению перехватывать вызов конечной точки выхода платформа удостоверений Майкрософт, предоставляя событие OpenId Подключение с именемOnRedirectToIdentityProviderForSignOut
Используйте токены SaS с ограниченным временем существования
Заголовок
Сведения
Компонент
Устройство Интернета вещей
Этап SDL
Сборка
Применимые технологии
Универсальный
Атрибуты
Неприменимо
Ссылки
Неприменимо
Шаги
Токены SaS, созданные для проверки подлинности Центра Интернета вещей Azure, должны иметь ограниченный срок действия. Задайте минимальный срок действия, чтобы ограничить срок повторного воспроизведения токенов SaS в случае их компрометирования.
Используйте токены ресурсов с минимальным временем существования
Заголовок
Сведения
Компонент
Azure DocumentDB
Этап SDL
Сборка
Применимые технологии
Универсальный
Атрибуты
Неприменимо
Ссылки
Неприменимо
Шаги
Задайте минимальное время существования токенов ресурсов. Допустимый интервал времени по умолчанию для маркеров ресурсов составляет 1 час.
Реализуйте надлежащее событие выхода с помощью методов WsFederation при использовании ADFS
Заголовок
Сведения
Компонент
ADFS
Этап SDL
Сборка
Применимые технологии
Универсальный
Атрибуты
Неприменимо
Ссылки
Неприменимо
Шаги
Если приложение использует токен службы токенов безопасности, выданный ADFS, чтобы выйти из системы пользователя, обработчик событий выхода должен вызвать метод WSFederationAuthenticationModule.FederatedSignOut(). Кроме того, необходимо уничтожить текущий сеанс, а также сбросить и обнулить значение токена сеанса.
Пример
[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);
}
Реализуйте надлежащее событие выхода при использовании сервера удостоверений
IdentityServer поддерживает возможность создавать федерацию с внешними поставщиками удостоверений. Когда пользователь выходит из вышестоящего поставщика удостоверений, в зависимости от используемого протокола можно получить уведомление при выходе пользователя из службы. Она позволяет IdentityServer уведомлять своих клиентов, чтобы они также могли подписывать пользователя. Сведения о реализации см. в документации в разделе "ссылки".
Используйте защищенные файлы cookie в приложениях, использующих протокол HTTPS
Как правило, файлы cookie доступны только в домене, для которого они были заданы. К сожалению, определение "домен" не включает в себя протокол, и поэтому файлы cookie, созданные по протоколу HTTPS, доступны по протоколу HTTP. Атрибут secure указывает браузеру, что файлы cookie доступны только по протоколу HTTPS. Убедитесь, что во всех этих файлах, заданных по протоколу HTTPS, используется атрибут secure. Это требование можно выполнить в файле web.config, задав атрибуту requireSSL значение true. Мы рекомендуем использовать этот подход, так как он позволяет применить атрибут secure для всех текущих и будущих файлов cookie, не внося дополнительные изменения в код.
Этот параметр применяется, даже если доступ к приложению осуществляется по протоколу HTTP. Если для доступа к приложению используется протокол HTTP, то этот параметр приводит к сбою приложения, так как из-за атрибута secure браузер не сможет возвращать файлы cookie в приложение.
Заголовок
Сведения
Компонент
Веб-приложение
Этап SDL
Сборка
Применимые технологии
Веб-формы, MVC 5
Атрибуты
EnvironmentType: OnPrem
Ссылки
Неприменимо
Шаги
Если веб-приложение выступает проверяющей стороной, а в качестве сервера ADFS используется IdP, атрибут secure в токене FedAuth можно настроить, задав в разделе system.identityModel.services файла web.config для параметра requireSSL значение true.
Пример
<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>
Укажите атрибут httpOnly в определении файла cookie всех приложений на основе протокола HTTP
Чтобы устранить угрозу раскрытия информации при атаках с использованием межсайтового сценария, в файлы cookie можно добавить новый атрибут httpOnly, поддерживаемый во всех основных браузерах. Атрибут делает файл cookie недоступным для сценария. С помощью атрибута httpOnly веб-приложение снижает возможность кражи конфиденциальной информации, содержащейся в файле cookie, через сценарий и ее отправки злоумышленнику.
Пример
Во всех приложениях на основе HTTP, использующих файлы cookie, необходимо определить атрибут httpOnly в определении файла cookie. Это можно сделать, внедрив в файл web.config следующую конфигурацию:
Значение свойства RequireSSL задается в файле конфигурации web.config для приложения ASP.NET с помощью атрибута requireSSL. Вы можете указать в файле Web.config приложения ASP.NET, требуется ли протокол TLS, ранее известный как SSL (SSL), для возврата файла cookie проверки подлинности форм на сервер путем установки атрибута requireSSL.
Пример
Следующий пример кода задает атрибут requireSSL в файле web.config.
Уменьшите риск атак с подделкой межсайтовых запросов на веб-страницах ASP.NET
Заголовок
Сведения
Компонент
Веб-приложение
Этап SDL
Сборка
Применимые технологии
Универсальный
Атрибуты
Неприменимо
Ссылки
Неприменимо
Шаги
Подделка межсайтовых запросов (CSRF или XSRF) — это тип атак, при которых злоумышленник может выполнять действия в контексте безопасности разных пользовательских активных сеансов на веб-сайте. Целью является изменение или удаление содержимого, если аутентификация полученных на целевом веб-сайте запросов выполняется исключительно с помощью файлов cookie сеанса. Злоумышленник может воспользоваться этой уязвимостью и внедрить в код сайта, на который выполнил вход пользователь, команду, которая перенаправляет пользователя на другой URL-адрес. Это можно сделать несколькими способами, например, разместив другой веб-сайт, который скачивает ресурсы с уязвимого сервера, или заставив пользователя щелкнуть ссылку. Чтобы предотвратить эту атаку, сервер должен отправлять дополнительный токен клиенту, добавлять его во все последующие запросы клиента, а затем проверять наличие этого токена, относящегося к текущему сеансу, во всех будущих запросах, например с помощью метода AntiForgeryToken или ViewState ASP.NET.
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Пример
В то же время Html.AntiForgeryToken() предоставляет посетителю файл cookie __RequestVerificationToken с таким же значением, как и случайное скрытое значение, показанное выше. Затем добавьте в целевой метод действия фильтр [ValidateAntiForgeryToken], чтобы проверить входящую форму POST. Например:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Фильтр авторизации, проверяющий, что:
Входящий запрос имеет файл cookie с именем __RequestVerificationToken.
Входящий запрос имеет запись Request.Form с именем __RequestVerificationToken.
Эти значения файла cookie и Request.Form совпадают. При условии, что все параметры заданы правильно, запрос выполняется в обычном режиме. В противном случае проверка подлинности завершается ошибкой и отображается следующее сообщение: "Обязательный маркер против подделки не был предоставлен или был недопустимым".
Пример
Формы Anti-CSRF и AJAX. Токен формы может вызывать проблемы при выполнении запросов AJAX. Это связано с тем, что этот запрос может отправлять данные JSON, а не данные HTML-формы. В этом случае можно отправлять токены в настраиваемый заголовок HTTP. Следующий код создает токены с использованием синтаксиса Razor, а затем добавляет их в запрос 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>
Пример
При обработке запроса извлеките токены из его заголовка. Затем вызовите метод AntiForgery.Validate для проверки этих токенов. Если токены недопустимые, метод AntiForgery.Validate вызывает исключение.
Подделку межсайтовых запросов в приложениях на основе веб-форм можно предотвратить, добавив параметр ViewStateUserKey в случайную строку, уникальную для каждого пользователя, например в строку с идентификатором пользователя, а еще лучше с идентификатором сеанса. По разным техническим и социальным причинам идентификатор сеанса подходит гораздо лучше, так как его нельзя предсказать, время его ожидания истекает и он уникальный для каждого пользователя.
Пример
Ниже приведен код, который необходимо добавить на всех страницах.
Время ожидания сеанса — это событие, возникающее, когда пользователь не выполняет каких-либо действий на веб-сайте в течение определенного интервала времени (заданного сервером). Это событие на стороне сервера изменяет состояние сеанса пользователя на "Недопустимый" (например, "больше не используется") и дает указание веб-серверу уничтожить его (удалить все данные сеанса). Пример кода ниже задает для атрибута времени ожидания сеанса значение 15 минут в файле web.config.
Когда веб-приложение является проверяющей стороной, а ADFS выступает службой токенов безопасности, время существования файлов cookie проверки подлинности (токенов FedAuth) задается с использованием следующей конфигурации в файле web.config:
Пример
<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>
Пример
Время существования токена утверждений, выданного ADFS, также должно составлять 15 минут. Чтобы задать это значение, выполните на сервере ADFS следующий командлет PowerShell:
После нажатия кнопки выхода приложение должно правильно завершить этот процесс. То есть оно должно уничтожить сеанс пользователя, а также сбросить и обнулить значение файла cookie сеанса и файла cookie проверки подлинности. Кроме того, когда к идентификатору пользователя привязаны несколько сеансов, они должны завершаться все вместе на стороне сервера во время ожидания или выхода. Наконец, убедитесь, что функция выхода доступна на каждой странице.
Уменьшите риск атак с подделкой межсайтовых запросов в веб-интерфейсах API ASP.NET
Заголовок
Сведения
Компонент
Веб-интерфейс API
Этап SDL
Сборка
Применимые технологии
Универсальный
Атрибуты
Неприменимо
Ссылки
Неприменимо
Шаги
Подделка межсайтовых запросов (CSRF или XSRF) — это тип атак, при которых злоумышленник может выполнять действия в контексте безопасности разных пользовательских активных сеансов на веб-сайте. Целью является изменение или удаление содержимого, если аутентификация полученных на целевом веб-сайте запросов выполняется исключительно с помощью файлов cookie сеанса. Злоумышленник может воспользоваться этой уязвимостью и внедрить в код сайта, на который выполнил вход пользователь, команду, которая перенаправляет пользователя на другой URL-адрес. Это можно сделать несколькими способами, например, разместив другой веб-сайт, который скачивает ресурсы с уязвимого сервера, или заставив пользователя щелкнуть ссылку. Чтобы предотвратить эту атаку, сервер должен отправлять дополнительный токен клиенту, добавлять его во все последующие запросы клиента, а затем проверять наличие этого токена, относящегося к текущему сеансу, во всех будущих запросах, например с помощью метода AntiForgeryToken или ViewState ASP.NET.
Формы Anti-CSRF и AJAX. Токен формы может вызывать проблемы при выполнении запросов AJAX. Это связано с тем, что этот запрос может отправлять данные JSON, а не данные HTML-формы. В этом случае можно отправлять токены в настраиваемый заголовок HTTP. Следующий код создает токены с использованием синтаксиса Razor, а затем добавляет их в запрос 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>
Пример
При обработке запроса извлеките токены из его заголовка. Затем вызовите метод AntiForgery.Validate для проверки этих токенов. Если токены недопустимые, метод AntiForgery.Validate вызывает исключение.
Выходные данные приведенного выше примера будут примерно следующие:
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Пример
В то же время Html.AntiForgeryToken() предоставляет посетителю файл cookie __RequestVerificationToken с таким же значением, как и случайное скрытое значение, показанное выше. Затем добавьте в целевой метод действия фильтр [ValidateAntiForgeryToken], чтобы проверить входящую форму POST. Например:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Фильтр авторизации, проверяющий, что:
Входящий запрос имеет файл cookie с именем __RequestVerificationToken.
Входящий запрос имеет запись Request.Form с именем __RequestVerificationToken.
Эти значения файла cookie и Request.Form совпадают. При условии, что все параметры заданы правильно, запрос выполняется в обычном режиме. В противном случае проверка подлинности завершается ошибкой и отображается следующее сообщение: "Обязательный маркер против подделки не был предоставлен или был недопустимым".
Заголовок
Сведения
Компонент
Веб-интерфейс API
Этап SDL
Сборка
Применимые технологии
MVC 5, MVC 6
Атрибуты
Поставщик удостоверений — ADFS, поставщик удостоверений — идентификатор Microsoft Entra
Если для защиты веб-интерфейса API используется OAuth 2.0, в заголовке запроса авторизации должен находиться токен носителя. Доступ к веб-приложению предоставляется, только если этот токен в запросе действительный. В отличие от проверки подлинности на основе файлов cookie браузеры не добавляют токены носителя к запросам. Клиент, отправивший запрос, должен явным образом прикрепить токен носителя в заголовке запроса. Таким образом, в веб-интерфейсах API ASP.NET, защищенных с помощью OAuth 2.0, токены носителя используются для защиты от подделки межсайтовых запросов. Обратите внимание, что если сегмент MVC приложения использует проверку подлинности на основе форм (то есть использует файлы cookie), в веб-приложении MVC необходимо использовать токены защиты от подделки.
Пример
Веб-API должен использовать только токены носителя, а не файлы cookie. Это можно сделать с помощью следующей настройки в методе WebApiConfig.Register.
Метод SuppressDefaultHostAuthentication сообщает веб-API, что необходимо игнорировать любые проверки подлинности, которые происходят прежде, чем запрос достигнет конвейера веб-API, либо с помощью службы IIS, либо с помощью ПО промежуточного слоя OWIN. Таким образом можно ограничить веб-API для проверки подлинности только с помощью токенов носителя.