C# C# · 30 вопросов · ~85 мин · ⏱ Таймер 25:00 · Сложный ·

Безопасность .NET-приложения

Разбирает безопасность .NET-приложения от аутентификации и прав до секретов, десериализации и наблюдаемости. Сценарии проверяют границы доверия, отрицательные случаи, ротацию ключей и способность заметить решение, которое выглядит защитой, но доверяет данным клиента.

Отвечено: 0 из 30

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 30 вопросов отведено 85 минут. В заданиях с кодом учитывайте указанную конструкцию и не додумывайте отсутствующие условия. После завершения откроются общий результат, тематические шкалы и разбор каждого ответа.

Вопрос 1 из 30

Что доказывает успешная аутентификация?

app.MapGet("/me", (ClaimsPrincipal user) => user.Identity?.Name)
   .RequireAuthorization();

Личность пользователя установлена выбранной схемой Данные не содержат SQL-инъекции Запрос безопасен от CSRF Пользователь является администратором Пользователь получает все права, перечисленные в токене, без отдельной проверки политики

Вопрос 2 из 30

Какие проверки нужны JWT access token?

services.AddAuthentication().AddJwtBearer(options =>
{
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidateAudience = true,
        ValidateLifetime = true,
        ValidateIssuerSigningKey = true,
        ValidIssuer = issuer,
        ValidAudience = audience,
        IssuerSigningKey = signingKey
    };
});

Проверить подпись и срок, но не issuer и audience Base64 без ошибок Проверить issuer и claim sub, считая подпись необязательной во внутренней сети Подпись, issuer, audience, срок и разрешённый ключ Длина токена

Вопрос 3 из 30

Как хранить пароль пользователя?

Base64 В зашифрованном виде с общим ключом для последующего показа В JWT claim Адаптивный хеш с солью и рабочей стоимостью SHA256(password) без соли

Вопрос 4 из 30

Почему access token лучше делать короткоживущим?

Чтобы ограничить окно злоупотребления и продлевать доступ отдельным контролируемым механизмом Чтобы токен гарантированно помещался в cookie браузера Чтобы отказаться от ротации и механизма отзыва учётных данных Чтобы сервер проверял меньше claims в каждом запросе Чтобы не проверять криптографическую подпись при каждом обращении

Вопрос 5 из 30

Какой риск создаёт такое журналирование заголовка авторизации?

var authorization = context.Request.Headers.Authorization.ToString();
log.LogInformation("Authorization: {Header}", authorization);

Структурированное журналирование сохранит тип заголовка, но не его строковое значение ILogger откажется записывать значения HTTP-заголовков Структурированный шаблон изменит подпись токена и сломает запрос Токен или ключ попадёт в журнал и станет доступен читателям логов Преобразование заголовка в строку удалит схему Bearer

Вопрос 6 из 30

Что отвечает авторизация?

var result = await authorization.AuthorizeAsync(
    user, order, "CanRefundOrder");
if (!result.Succeeded) return Results.Forbid();

Есть ли право выполнить действие над ресурсом Зашифрован ли канал передачи данных Записана ли операция в журнал аудита Соответствует ли частота запросов лимиту Кто пользователь

Вопрос 7 из 30

Почему [Authorize(Roles="Manager")] может быть недостаточно для редактирования заказа?

Роль Manager уже доказывает владение любым заказом Роль достаточно проверить один раз при входе, а не для конкретного заказа Нужно заменить роль на claim с тем же названием, не загружая сам заказ Roles не поддерживаются Нужно также проверить tenant/ownership или иной контекст конкретного заказа

Вопрос 8 из 30

Как выполнить resource-based authorization?

var order = await repository.FindAsync(id, token);
if (order is null) return Results.NotFound();
var allowed = await authorization.AuthorizeAsync(user, order, "CanEditOrder");
return allowed.Succeeded ? await Update(order) : Results.Forbid();

Проверить IsAuthenticated и считать любой ресурс доступным вошедшему пользователю Сохранить разрешённые ресурсы в JWT claim и сравнивать без загрузки объекта Сравнить URL со строкой роли Сравнить идентификатор ресурса в клиентском коде перед отправкой запроса Вызвать AuthorizeAsync для пользователя и ресурса

Вопрос 9 из 30

Что означает deny by default?

Доступ не предоставляется без явно удовлетворённой политики Разрешить действие любому аутентифицированному пользователю, пока отдельное правило его не запретило Каждый endpoint возвращает 404 Ограничить доступ только небезопасными HTTP-методами, оставив чтение открытым Авторизация отключена

Вопрос 10 из 30

Почему проверка ownerId из тела запроса опасна?

var command = await request.ReadFromJsonAsync<DeleteDocumentCommand>();
var userId = User.FindFirstValue(ClaimTypes.NameIdentifier);

if (command!.OwnerId != userId)
    return Results.Forbid();

return await documents.DeleteAsync(command.DocumentId);

Нужно загрузить документ и сравнить его владельца с идентификатором из доверенного claim TLS подтверждает истинность поля OwnerId, присланного клиентом Тело запроса нельзя читать после сопоставления маршрута Строковый идентификатор пользователя нельзя сравнивать со значением из JSON Проверка опасна только для запросов POST, но не DELETE

Вопрос 11 из 30

Где не следует хранить production connection string с паролем?

{
  "ConnectionStrings": {
    "Main": "Server=db;User Id=app;Password=plain-secret"
  }
}

В appsettings.json, закоммиченном в репозиторий В управляемой идентичности, где постоянного пароля нет В секретном хранилище платформы В переменной окружения с контролем доступа В vault

Вопрос 12 из 30

Для чего dotnet user-secrets?

Для замены управляемого хранилища секретов в рабочей среде Для локальной разработки вне файлов проекта, но не как рабочее корпоративное хранилище Для шифрования рабочей базы данных средствами проекта Для публикации секретных настроек вместе с пакетом NuGet Для автоматической подписи всех локальных JWT при запуске

Вопрос 13 из 30

Почему управляемая идентичность лучше статического облачного ключа?

Она отменяет необходимость шифровать соединение через TLS Она переносит проверку назначенной роли в клиентское приложение Она добавляет больше диагностических сообщений в журналы Она позволяет обращаться к ресурсу без проверки полномочий Она выдаёт краткоживущие данные по назначенной роли без постоянного ключа

Вопрос 14 из 30

Как подготовить ротацию ключа подписи?

var credentials = keyRing.CurrentSigningCredentials;
var validationKeys = keyRing.ActiveValidationKeys;

Закрепить один key id в коде и менять приложение целиком Публиковать private key Заменить ключ сразу и считать досрочную недействительность старых токенов приемлемой Хранить новый и прежний ключи в переходном окне Менять алгоритм на none

Вопрос 15 из 30

Какое действие должно быть первым после обнаружения такого файла в истории Git?

// appsettings.Production.json из старого коммита
{
  "Payments": {
    "ApiKey": "sk_live_7f3c..."
  }
}

Отозвать ключ, выпустить новый и проверить журналы его использования Убедиться, что репозиторий приватный, и не менять ключ Удалить коммит с ключом через git rebase --interactive и считать этого достаточным Добавить файл в .gitignore и оставить прежний ключ действующим Удалить строку новым коммитом и считать прежние коммиты безопасными

Вопрос 16 из 30

Почему BinaryFormatter не подходит для недоверенных данных?

var formatter = new BinaryFormatter();
var value = formatter.Deserialize(untrustedStream);

Считать неизвестные типы безопасными, потому что десериализатор пропустит их без создания объектов Проблема сводится к медленному форматированию строк При разборе может быть создан опасный граф объектов с нежелательным поведением Формат не способен хранить значения типа int Достаточно проверить тип уже созданного объекта после десериализации

Вопрос 17 из 30

Что опасно в TypeNameHandling.Auto/All для внешнего JSON без binder allowlist?

Числовые значения будут прочитаны как строки Метаданные типа учитываются лишь при сериализации ответа, но не при чтении входа Вход может назвать CLR-тип, который приложение попытается создать Риск ограничивается ростом JSON: выбор CLR-типа не влияет на исполняемое поведение Опасность связана только с политикой имён свойств, которую можно исправить camelCase-настройкой

Вопрос 18 из 30

Как безопасно поддержать несколько видов команд?

return envelope.Kind switch
{
    "create-order" => envelope.Payload.Deserialize<CreateOrderDto>(options),
    "cancel-order" => envelope.Payload.Deserialize<CancelOrderDto>(options),
    _ => throw new JsonException("Unsupported command kind")
};

BinaryFormatter Прочитать произвольное AssemblyQualifiedName Явно сопоставлять разрешённый discriminator с DTO Activator.CreateInstance любого type dynamic без проверки

Вопрос 19 из 30

Зачем MaxDepth и лимит размера?

Чтобы вложенный/огромный payload не исчерпал стек, CPU или память Чтобы уменьшить число свойств, создаваемых сериализатором Чтобы проверить подпись Чтобы сериализатор выравнивал форматирование глубоко вложенных объектов Чтобы сделать тип immutable

Вопрос 20 из 30

Какую защитную границу создаёт этот код?

var dto = await JsonSerializer.DeserializeAsync<CreateUserDto>(body, options, token);
Validate(dto);
var user = User.Create(dto.Name, dto.Email);

Позиционный record сам проверяет диапазоны аргументов до вызова конструктора Безопасность обеспечивается самим пространством имён CreateUserDto Внешний JSON не связывается напрямую с внутренней доменной моделью System.Text.Json не умеет создавать экземпляры доменных классов Десериализованный DTO считается безопасным без дополнительной проверки полей

Вопрос 21 из 30

Какая матрица нужна для защищённого endpoint?

var cases = new[]
{
    Anonymous(), ExpiredToken(), WrongTenant(), Owner(), Administrator()
};
foreach (var testCase in cases)
    await AssertAuthorizationAsync(testCase);

Один случай 401 Аноним, неверный токен, чужой и свой ресурс Достаточно проверить успешные GET и POST от владельца ресурса Достаточно сценария владельца, потому что анонимный доступ проверяется middleware отдельно Достаточно сравнить администратора и одного обычного пользователя без сценария чужого ресурса

Вопрос 22 из 30

Как тестировать JWT-подпись?

var forged = TamperPayload(validToken, new { role = "admin" });
using var request = new HttpRequestMessage(HttpMethod.Get, "/admin");
request.Headers.Authorization = new("Bearer", forged);
Assert.Equal(HttpStatusCode.Unauthorized, (await client.SendAsync(request)).StatusCode);

Изменить payload, сохранив прежнюю подпись Декодировать payload и проверить sub Сравнить длину token Использовать algorithm none Подменить ClaimsPrincipal и не создавать токен с нарушенной подписью

Вопрос 23 из 30

Что делает secret scanning в CI?

Ищет известные шаблоны/энтропию до merge, дополняя ротацию и обучение Secret scanning предотвращает публикацию любого секрета Проверяет authorization Делает отдельное хранилище и ротацию секретов ненужными Шифрует найденную строку прямо в истории Git

Вопрос 24 из 30

Что журналировать при отказе авторизации?

audit.LogAuthorizationDenied(
    policy: "CanEditOrder",
    subjectId: user.FindFirstValue(ClaimTypes.NameIdentifier),
    resourceId: order.Id,
    traceId: Activity.Current?.TraceId.ToString());

Пароль пользователя Токен целиком Записать полный набор claims, чтобы расследование не зависело от других источников Оставить только код 403 без субъекта, политики и идентификатора запроса Политику, субъект, ресурс, trace id и результат

Вопрос 25 из 30

Как fuzzing помогает JSON-граничному коду?

Генерирует повреждённые и глубокие входы, проверяя управляемый отказ Заменяет лимит размера Создаёт production secrets Доказывает бизнес-правильность всех данных Ускоряет разбор корректных документов, не проверяя повреждённые структуры

Вопрос 26 из 30

Почему хеширование пароля намеренно дорогой?

var result = passwordHasher.HashPassword(user, password);

Чтобы получить из пароля готовый JWT Получать одинаковый короткий хеш для одинаковых паролей, чтобы быстрее искать совпадения Чтобы хранить пароль в обратимо зашифрованном виде Чтобы сделать массовый перебор паролей дорогим для атакующего Задать фиксированную задержку входа в одну минуту независимо от мощности сервера

Вопрос 27 из 30

Что кэшировать при проверке JWT от внешнего issuer?

var configuration = await configurationManager
    .GetConfigurationAsync(token);
var signingKeys = configuration.SigningKeys;

Результат проверки каждого встреченного токена без срока действия Публичные ключи JWKS с обновлением при ротации и неизвестном key id Кэшировать discovery-документ без срока, поскольку key id не меняется после публикации issuer Закрытый ключ каждого пользователя, извлечённый из токена Токены всех пользователей вместе с ключами подписи

Вопрос 28 из 30

Что такое граница доверия?

Считать границей доверия только форму входа, где вводится пароль Место перехода данных между сторонами с разным уровнем доверия Класс, который реализует хотя бы один публичный интерфейс Проводить границу по пространствам имён независимо от источника данных Считать границей лишь сетевой экран между физическими узлами

Вопрос 29 из 30

Почему многоуровневая защита не означает дублировать один и тот же if повсюду?

Потому что if медленный Разные слои должны закрывать разные виды отказа Выбрать одну самую сильную проверку и удалить остальные как дублирующие Одну и ту же проверку достаточно оставить только на сетевом уровне Перенести все проверки в WAF, чтобы приложение не повторяло контроль доступа

Вопрос 30 из 30

Как защитить дорогой endpoint генерации отчёта?

app.MapPost("/reports", CreateReport)
    .RequireAuthorization("CanCreateReports")
    .RequireRateLimiting("reports");
// Внутри — bounded queue и cancellation.

Запустить Task.Run без лимита Увеличить timeout, не ограничивая число одновременных отчётов Права, лимит запросов, очередь и лимит размера Использовать общий кэш ответов без включения пользователя и параметров отчёта в ключ Сделать endpoint anonymous

Ответьте на все 30 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу