💡 Инструкция: Выберите один ответ из пяти. Время — 85 минут. У каждого задания ровно один правильный вариант. Фрагменты рассчитаны на Ruby 4.0.6; задания Rails — на Rails 8.1.3. После завершения откроются общий процент, 6 тематических результатов и разбор всех ответов.
Вопрос 1 из 30
Какое описание результата точно соответствует показанному коду «Массовое присваивание атрибутов»? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Ruby Ruby — Массовое присваивание атрибутов Копировать
# Проследите выполнение и выберите точный результат.
def profile_params
params.require(:user).permit(:name, :timezone)
end
current_user.update!(profile_params)
Обычный `<%= comment.body %>` выводит пользовательский HTML как текст, а не исполняемый тег. Это объясняется тем, что mass assignment безопасен только при белом списке полей конкретной операции; защита модели не заменяет ограничения прав.
Параметр `role` не попадает в `update!`, потому что разрешены только name и timezone. Это объясняется тем, что mass assignment безопасен только при белом списке полей конкретной операции; защита модели не заменяет ограничения прав.
Выбранное направление берётся только из словаря `asc/desc`, а имя поля задано приложением. Это объясняется тем, что mass assignment безопасен только при белом списке полей конкретной операции; защита модели не заменяет ограничения прав.
Параметр `role` не попадает в `update!`, потому что разрешены только name и timezone. Это объясняется тем, что параметризация защищает значения SQL, но имена столбцов, направления сортировки и фрагменты команд требуют белого списка.
Параметр `role` не попадает в `update!`, потому что разрешены только name и timezone. Это объясняется тем, что секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ.
Вопрос 2 из 30
Как следует прочитать результат показанного примера «XSS и CSRF»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — XSS и CSRF Копировать
# Проследите выполнение и выберите точный результат.
# ERB
# Безопасная форма для обычного текста:
# <%= comment.body %>
# Опасная без строгой очистки:
# <%= comment.body.html_safe %>
Обычный `<%= comment.body %>` выводит пользовательский HTML как текст, а не исполняемый тег. Причина такого результата: архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути.
Выбранное направление берётся только из словаря `asc/desc`, а имя поля задано приложением. Причина такого результата: Rails экранирует вывод шаблонов по умолчанию, CSRF-токен защищает cookie-сессию от межсайтовой команды; `html_safe` и отключение проверки снимают эти гарантии.
Параметр `role` не попадает в `update!`, потому что разрешены только name и timezone. Причина такого результата: Rails экранирует вывод шаблонов по умолчанию, CSRF-токен защищает cookie-сессию от межсайтовой команды; `html_safe` и отключение проверки снимают эти гарантии.
Обычный `<%= comment.body %>` выводит пользовательский HTML как текст, а не исполняемый тег. Причина такого результата: Rails экранирует вывод шаблонов по умолчанию, CSRF-токен защищает cookie-сессию от межсайтовой команды; `html_safe` и отключение проверки снимают эти гарантии.
Обычный `<%= comment.body %>` выводит пользовательский HTML как текст, а не исполняемый тег. Причина такого результата: исправление безопасности нужно измерять по пути атаки и накладным расходам; микротест безопасной функции не доказывает защиту всего запроса.
Вопрос 3 из 30
Как изменится состояние программы после выполнения кода по теме «Инъекции»? Нужен вариант без логического разрыва между первой и второй частью.
Ruby Ruby — Инъекции Копировать
# Проследите выполнение и выберите точный результат.
directions = { 'oldest' => :asc, 'newest' => :desc }
direction = directions.fetch(params[:order], :desc)
records = Event.order(created_at: direction)
Выбранное направление берётся только из словаря `asc/desc`, а имя поля задано приложением. Такой итог следует из правила: параметризация защищает значения SQL, но имена столбцов, направления сортировки и фрагменты команд требуют белого списка.
Выбранное направление берётся только из словаря `asc/desc`, а имя поля задано приложением. Такой итог следует из правила: секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ.
Выбранное направление берётся только из словаря `asc/desc`, а имя поля задано приложением. Такой итог следует из правила: mass assignment безопасен только при белом списке полей конкретной операции; защита модели не заменяет ограничения прав.
Обычный `<%= comment.body %>` выводит пользовательский HTML как текст, а не исполняемый тег. Такой итог следует из правила: параметризация защищает значения SQL, но имена столбцов, направления сортировки и фрагменты команд требуют белого списка.
Параметр `role` не попадает в `update!`, потому что разрешены только name и timezone. Такой итог следует из правила: параметризация защищает значения SQL, но имена столбцов, направления сортировки и фрагменты команд требуют белого списка.
Вопрос 4 из 30
Что покажет выполнение этого фрагмента из раздела «Управление секретами»? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Ruby Ruby — Управление секретами Копировать
# Проследите выполнение и выберите точный результат.
api_key = Rails.application.credentials.dig(:payments, :api_key)
raise 'payment key is missing' if api_key.nil? || api_key.empty?
PaymentClient.new(api_key: api_key)
Код читает ключ из credentials и не содержит его буквального значения. Механизм результата таков: архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути.
Параметр `role` не попадает в `update!`, потому что разрешены только name и timezone. Механизм результата таков: секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ.
Код читает ключ из credentials и не содержит его буквального значения. Механизм результата таков: параметризация защищает значения SQL, но имена столбцов, направления сортировки и фрагменты команд требуют белого списка.
Код читает ключ из credentials и не содержит его буквального значения. Механизм результата таков: секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ.
Выбранное направление берётся только из словаря `asc/desc`, а имя поля задано приложением. Механизм результата таков: секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ.
Вопрос 5 из 30
Как следует прочитать результат показанного примера «Профилирование решения»? Нужен вариант без логического разрыва между первой и второй частью.
Ruby Ruby — Профилирование решения Копировать
# Проследите выполнение и выберите точный результат.
require 'benchmark'
input = File.read('fixture.json')
puts Benchmark.measure {
1_000.times { SafeParser.call(input) }
}
Отдельная роль базы для web-процесса не имеет права изменять таблицу аудита или выполнять административные команды. Наблюдение согласуется с тем, что исправление безопасности нужно измерять по пути атаки и накладным расходам; микротест безопасной функции не доказывает защиту всего запроса.
Benchmark сравнивает ограниченный и небезопасный парсер на одном наборе, но итоговая оценка требует профиля реального endpoint. Наблюдение согласуется с тем, что исправление безопасности нужно измерять по пути атаки и накладным расходам; микротест безопасной функции не доказывает защиту всего запроса.
Обычный `<%= comment.body %>` выводит пользовательский HTML как текст, а не исполняемый тег. Наблюдение согласуется с тем, что исправление безопасности нужно измерять по пути атаки и накладным расходам; микротест безопасной функции не доказывает защиту всего запроса.
Benchmark сравнивает ограниченный и небезопасный парсер на одном наборе, но итоговая оценка требует профиля реального endpoint. Наблюдение согласуется с тем, что архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути.
Benchmark сравнивает ограниченный и небезопасный парсер на одном наборе, но итоговая оценка требует профиля реального endpoint. Наблюдение согласуется с тем, что секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ.
Вопрос 6 из 30
Разберите выражения по порядку. Как завершится фрагмент из раздела «Архитектурные компромиссы»? Выберите связку, в которой верны и основной вывод, и его обоснование.
Ruby Ruby — Архитектурные компромиссы Копировать
# Проследите выполнение и выберите точный результат.
# Идея настройки ролей, выполняется администратором БД:
# GRANT SELECT, INSERT, UPDATE ON orders TO web_app;
# REVOKE DELETE ON audit_events FROM web_app;
p ActiveRecord::Base.connection_db_config.configuration_hash[:username]
Benchmark сравнивает ограниченный и небезопасный парсер на одном наборе, но итоговая оценка требует профиля реального endpoint. Этот вывод опирается на правило: архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути.
Отдельная роль базы для web-процесса не имеет права изменять таблицу аудита или выполнять административные команды. Этот вывод опирается на правило: архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути.
Отдельная роль базы для web-процесса не имеет права изменять таблицу аудита или выполнять административные команды. Этот вывод опирается на правило: секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ.
Обычный `<%= comment.body %>` выводит пользовательский HTML как текст, а не исполняемый тег. Этот вывод опирается на правило: архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути.
Отдельная роль базы для web-процесса не имеет права изменять таблицу аудита или выполнять административные команды. Этот вывод опирается на правило: исправление безопасности нужно измерять по пути атаки и накладным расходам; микротест безопасной функции не доказывает защиту всего запроса.
Вопрос 8 из 30
Какое скрытое условие делает фрагмент «XSS и CSRF» хрупким? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Ruby Ruby — XSS и CSRF Копировать
# Обычный запуск проходит. Найдите скрытый риск.
# ERB
# Безопасная форма для обычного текста:
# <%= comment.body %>
# Опасная без строгой очистки:
# <%= comment.body.html_safe %>
Интерполяция `params[:sort]` в order остаётся SQL-инъекцией, даже если where построен параметрами. Этот риск связан с тем, что Rails экранирует вывод шаблонов по умолчанию, CSRF-токен защищает cookie-сессию от межсайтовой команды; `html_safe` и отключение проверки снимают эти гарантии.
Пометка внешней строки `html_safe` превращает хранимый текст в XSS для каждого читателя страницы. Этот риск связан с тем, что Rails экранирует вывод шаблонов по умолчанию, CSRF-токен защищает cookie-сессию от межсайтовой команды; `html_safe` и отключение проверки снимают эти гарантии.
Пометка внешней строки `html_safe` превращает хранимый текст в XSS для каждого читателя страницы. Этот риск связан с тем, что архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути.
Общий суперпользователь базы во всех сервисах превращает SQL-инъекцию одного endpoint в компрометацию всей схемы. Этот риск связан с тем, что Rails экранирует вывод шаблонов по умолчанию, CSRF-токен защищает cookie-сессию от межсайтовой команды; `html_safe` и отключение проверки снимают эти гарантии.
Пометка внешней строки `html_safe` превращает хранимый текст в XSS для каждого читателя страницы. Этот риск связан с тем, что исправление безопасности нужно измерять по пути атаки и накладным расходам; микротест безопасной функции не доказывает защиту всего запроса.
Вопрос 9 из 30
Какой рабочий сбой вероятнее всего связан именно с механизмом «Инъекции»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Ruby Ruby — Инъекции Копировать
# Обычный запуск проходит. Найдите скрытый риск.
directions = { 'oldest' => :asc, 'newest' => :desc }
direction = directions.fetch(params[:order], :desc)
records = Event.order(created_at: direction)
Общий суперпользователь базы во всех сервисах превращает SQL-инъекцию одного endpoint в компрометацию всей схемы. Уязвимое место возникает потому, что параметризация защищает значения SQL, но имена столбцов, направления сортировки и фрагменты команд требуют белого списка.
Пометка внешней строки `html_safe` превращает хранимый текст в XSS для каждого читателя страницы. Уязвимое место возникает потому, что параметризация защищает значения SQL, но имена столбцов, направления сортировки и фрагменты команд требуют белого списка.
Интерполяция `params[:sort]` в order остаётся SQL-инъекцией, даже если where построен параметрами. Уязвимое место возникает потому, что параметризация защищает значения SQL, но имена столбцов, направления сортировки и фрагменты команд требуют белого списка.
Интерполяция `params[:sort]` в order остаётся SQL-инъекцией, даже если where построен параметрами. Уязвимое место возникает потому, что mass assignment безопасен только при белом списке полей конкретной операции; защита модели не заменяет ограничения прав.
Интерполяция `params[:sort]` в order остаётся SQL-инъекцией, даже если where построен параметрами. Уязвимое место возникает потому, что секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ.
Вопрос 10 из 30
Какой дефект может проявиться на границе показанного сценария «Управление секретами»? Правильным считается только полностью согласованное утверждение.
Ruby Ruby — Управление секретами Копировать
# Обычный запуск проходит. Найдите скрытый риск.
api_key = Rails.application.credentials.dig(:payments, :api_key)
raise 'payment key is missing' if api_key.nil? || api_key.empty?
PaymentClient.new(api_key: api_key)
Наличие шифрованного credentials-файла не помогает, если master key лежит в том же репозитории или печатается при старте. К такому сбою приводит правило: архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути.
Наличие шифрованного credentials-файла не помогает, если master key лежит в том же репозитории или печатается при старте. К такому сбою приводит правило: секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ.
Общий суперпользователь базы во всех сервисах превращает SQL-инъекцию одного endpoint в компрометацию всей схемы. К такому сбою приводит правило: секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ.
Оптимизация проверки подписи через кэш без привязки к токену/сроку действия может повторно принять отозванный доступ. К такому сбою приводит правило: секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ.
Наличие шифрованного credentials-файла не помогает, если master key лежит в том же репозитории или печатается при старте. К такому сбою приводит правило: параметризация защищает значения SQL, но имена столбцов, направления сортировки и фрагменты команд требуют белого списка.
Вопрос 12 из 30
Какой рабочий сбой вероятнее всего связан именно с механизмом «Архитектурные компромиссы»? Правильным считается только полностью согласованное утверждение.
Ruby Ruby — Архитектурные компромиссы Копировать
# Обычный запуск проходит. Найдите скрытый риск.
# Идея настройки ролей, выполняется администратором БД:
# GRANT SELECT, INSERT, UPDATE ON orders TO web_app;
# REVOKE DELETE ON audit_events FROM web_app;
p ActiveRecord::Base.connection_db_config.configuration_hash[:username]
Оптимизация проверки подписи через кэш без привязки к токену/сроку действия может повторно принять отозванный доступ. Проблема возникает из-за того, что архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути.
Наличие шифрованного credentials-файла не помогает, если master key лежит в том же репозитории или печатается при старте. Проблема возникает из-за того, что архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути.
Общий суперпользователь базы во всех сервисах превращает SQL-инъекцию одного endpoint в компрометацию всей схемы. Проблема возникает из-за того, что секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ.
Общий суперпользователь базы во всех сервисах превращает SQL-инъекцию одного endpoint в компрометацию всей схемы. Проблема возникает из-за того, что исправление безопасности нужно измерять по пути атаки и накладным расходам; микротест безопасной функции не доказывает защиту всего запроса.
Общий суперпользователь базы во всех сервисах превращает SQL-инъекцию одного endpoint в компрометацию всей схемы. Проблема возникает из-за того, что архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути.
Вопрос 13 из 30
Какой механизм объясняет и обычный, и граничный сценарий «Массовое присваивание атрибутов»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Mass assignment безопасен только при белом списке полей конкретной операции; защита модели не заменяет ограничения прав. Поэтому параметр `role` не попадает в `update!`, потому что разрешены только name и timezone.
Параметризация защищает значения SQL, но имена столбцов, направления сортировки и фрагменты команд требуют белого списка. Поэтому параметр `role` не попадает в `update!`, потому что разрешены только name и timezone.
Секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ. Поэтому параметр `role` не попадает в `update!`, потому что разрешены только name и timezone.
Mass assignment безопасен только при белом списке полей конкретной операции; защита модели не заменяет ограничения прав. Поэтому выбранное направление берётся только из словаря `asc/desc`, а имя поля задано приложением.
Mass assignment безопасен только при белом списке полей конкретной операции; защита модели не заменяет ограничения прав. Поэтому обычный `<%= comment.body %>` выводит пользовательский HTML как текст, а не исполняемый тег.
Вопрос 14 из 30
Какой принцип темы «XSS и CSRF» переносится на другие примеры того же типа? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Исправление безопасности нужно измерять по пути атаки и накладным расходам; микротест безопасной функции не доказывает защиту всего запроса. Из этого следует, что обычный `<%= comment.body %>` выводит пользовательский HTML как текст, а не исполняемый тег.
Rails экранирует вывод шаблонов по умолчанию, CSRF-токен защищает cookie-сессию от межсайтовой команды; `html_safe` и отключение проверки снимают эти гарантии. Из этого следует, что параметр `role` не попадает в `update!`, потому что разрешены только name и timezone.
Rails экранирует вывод шаблонов по умолчанию, CSRF-токен защищает cookie-сессию от межсайтовой команды; `html_safe` и отключение проверки снимают эти гарантии. Из этого следует, что выбранное направление берётся только из словаря `asc/desc`, а имя поля задано приложением.
Rails экранирует вывод шаблонов по умолчанию, CSRF-токен защищает cookie-сессию от межсайтовой команды; `html_safe` и отключение проверки снимают эти гарантии. Из этого следует, что обычный `<%= comment.body %>` выводит пользовательский HTML как текст, а не исполняемый тег.
Архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути. Из этого следует, что обычный `<%= comment.body %>` выводит пользовательский HTML как текст, а не исполняемый тег.
Вопрос 15 из 30
Какое правило Ruby или Rails объясняет поведение в теме «Инъекции»? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Mass assignment безопасен только при белом списке полей конкретной операции; защита модели не заменяет ограничения прав. Наблюдаемое следствие: выбранное направление берётся только из словаря `asc/desc`, а имя поля задано приложением.
Параметризация защищает значения SQL, но имена столбцов, направления сортировки и фрагменты команд требуют белого списка. Наблюдаемое следствие: обычный `<%= comment.body %>` выводит пользовательский HTML как текст, а не исполняемый тег.
Секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ. Наблюдаемое следствие: выбранное направление берётся только из словаря `asc/desc`, а имя поля задано приложением.
Параметризация защищает значения SQL, но имена столбцов, направления сортировки и фрагменты команд требуют белого списка. Наблюдаемое следствие: параметр `role` не попадает в `update!`, потому что разрешены только name и timezone.
Параметризация защищает значения SQL, но имена столбцов, направления сортировки и фрагменты команд требуют белого списка. Наблюдаемое следствие: выбранное направление берётся только из словаря `asc/desc`, а имя поля задано приложением.
Вопрос 16 из 30
Как сформулировать правило блока «Управление секретами» без лишних обещаний? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ. Именно поэтому код читает ключ из credentials и не содержит его буквального значения.
Параметризация защищает значения SQL, но имена столбцов, направления сортировки и фрагменты команд требуют белого списка. Именно поэтому код читает ключ из credentials и не содержит его буквального значения.
Секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ. Именно поэтому выбранное направление берётся только из словаря `asc/desc`, а имя поля задано приложением.
Архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути. Именно поэтому код читает ключ из credentials и не содержит его буквального значения.
Секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ. Именно поэтому параметр `role` не попадает в `update!`, потому что разрешены только name и timezone.
Вопрос 18 из 30
Какое правило Ruby или Rails объясняет поведение в теме «Архитектурные компромиссы»? Правильным считается только полностью согласованное утверждение.
Исправление безопасности нужно измерять по пути атаки и накладным расходам; микротест безопасной функции не доказывает защиту всего запроса. Практическое следствие правила: отдельная роль базы для web-процесса не имеет права изменять таблицу аудита или выполнять административные команды.
Секреты должны поступать из защищённого хранилища, иметь ротацию и не попадать в код, журналы, исключения или клиентский ответ. Практическое следствие правила: отдельная роль базы для web-процесса не имеет права изменять таблицу аудита или выполнять административные команды.
Архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути. Практическое следствие правила: отдельная роль базы для web-процесса не имеет права изменять таблицу аудита или выполнять административные команды.
Архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути. Практическое следствие правила: benchmark сравнивает ограниченный и небезопасный парсер на одном наборе, но итоговая оценка требует профиля реального endpoint.
Архитектурная защита сочетает минимальные права, изоляцию, валидацию и аудит; один фильтр приложения не удерживает все обходные пути. Практическое следствие правила: обычный `<%= comment.body %>` выводит пользовательский HTML как текст, а не исполняемый тег.
Вопрос 21 из 30
Какой вариант решения «Инъекции» останется понятным при сопровождении? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Инъекции Копировать
# Выберите изменение, которое исправляет причину.
directions = { 'oldest' => :asc, 'newest' => :desc }
direction = directions.fetch(params[:order], :desc)
records = Event.order(created_at: direction)
Разделять данные и структуру запроса: значения параметризовать, структуру выбирать из закрытого набора объектов. Такая правка нужна из-за риска: пометка внешней строки `html_safe` превращает хранимый текст в XSS для каждого читателя страницы.
Хранить текст как данные, а разрешённый HTML пропускать через строгий sanitization с минимальным списком тегов/атрибутов. Такая правка нужна из-за риска: интерполяция `params[:sort]` в order остаётся SQL-инъекцией, даже если where построен параметрами.
Разделять данные и структуру запроса: значения параметризовать, структуру выбирать из закрытого набора объектов. Такая правка нужна из-за риска: общий суперпользователь базы во всех сервисах превращает SQL-инъекцию одного endpoint в компрометацию всей схемы.
Создавать отдельные наборы параметров на команды и не разрешать идентификаторы владельца, роли и состояние напрямую. Такая правка нужна из-за риска: интерполяция `params[:sort]` в order остаётся SQL-инъекцией, даже если where построен параметрами.
Разделять данные и структуру запроса: значения параметризовать, структуру выбирать из закрытого набора объектов. Такая правка нужна из-за риска: интерполяция `params[:sort]` в order остаётся SQL-инъекцией, даже если where построен параметрами.
Вопрос 22 из 30
Какое исправление уменьшает риск, не скрывая исходное поведение «Управление секретами»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Ruby Ruby — Управление секретами Копировать
# Выберите изменение, которое исправляет причину.
api_key = Rails.application.credentials.dig(:payments, :api_key)
raise 'payment key is missing' if api_key.nil? || api_key.empty?
PaymentClient.new(api_key: api_key)
Хранить текст как данные, а разрешённый HTML пропускать через строгий sanitization с минимальным списком тегов/атрибутов. Решение адресует следующий дефект: наличие шифрованного credentials-файла не помогает, если master key лежит в том же репозитории или печатается при старте.
Хранить ключ расшифровки отдельно, ограничить доступ процесса, предусмотреть одновременную поддержку старого и нового секрета при ротации. Решение адресует следующий дефект: оптимизация проверки подписи через кэш без привязки к токену/сроку действия может повторно принять отозванный доступ.
Хранить ключ расшифровки отдельно, ограничить доступ процесса, предусмотреть одновременную поддержку старого и нового секрета при ротации. Решение адресует следующий дефект: общий суперпользователь базы во всех сервисах превращает SQL-инъекцию одного endpoint в компрометацию всей схемы.
Сначала подтвердить закрытие уязвимости негативным тестом, затем профилировать полную цепочку и оптимизировать без ослабления инварианта. Решение адресует следующий дефект: наличие шифрованного credentials-файла не помогает, если master key лежит в том же репозитории или печатается при старте.
Хранить ключ расшифровки отдельно, ограничить доступ процесса, предусмотреть одновременную поддержку старого и нового секрета при ротации. Решение адресует следующий дефект: наличие шифрованного credentials-файла не помогает, если master key лежит в том же репозитории или печатается при старте.
Вопрос 24 из 30
Какой вариант решения «Архитектурные компромиссы» останется понятным при сопровождении? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Архитектурные компромиссы Копировать
# Выберите изменение, которое исправляет причину.
# Идея настройки ролей, выполняется администратором БД:
# GRANT SELECT, INSERT, UPDATE ON orders TO web_app;
# REVOKE DELETE ON audit_events FROM web_app;
p ActiveRecord::Base.connection_db_config.configuration_hash[:username]
Разделять данные и структуру запроса: значения параметризовать, структуру выбирать из закрытого набора объектов. После изменения не должен сохраняться риск: общий суперпользователь базы во всех сервисах превращает SQL-инъекцию одного endpoint в компрометацию всей схемы.
Разделять роли по задачам, ограничивать сеть и проверять права в автоматическом развёртывании. После изменения не должен сохраняться риск: общий суперпользователь базы во всех сервисах превращает SQL-инъекцию одного endpoint в компрометацию всей схемы.
Разделять роли по задачам, ограничивать сеть и проверять права в автоматическом развёртывании. После изменения не должен сохраняться риск: оптимизация проверки подписи через кэш без привязки к токену/сроку действия может повторно принять отозванный доступ.
Разделять роли по задачам, ограничивать сеть и проверять права в автоматическом развёртывании. После изменения не должен сохраняться риск: наличие шифрованного credentials-файла не помогает, если master key лежит в том же репозитории или печатается при старте.
Создавать отдельные наборы параметров на команды и не разрешать идентификаторы владельца, роли и состояние напрямую. После изменения не должен сохраняться риск: общий суперпользователь базы во всех сервисах превращает SQL-инъекцию одного endpoint в компрометацию всей схемы.
Вопрос 28 из 30
Что следует добавить в набор проверок по теме «Управление секретами», чтобы поймать редкий отказ? Выберите связку, в которой верны и основной вывод, и его обоснование.
Проверить JSON-path, Arel.sql и find_by_sql: «служебный» интерфейс часто становится внешним позднее. Сценарий подтверждает надёжность решения: хранить ключ расшифровки отдельно, ограничить доступ процесса, предусмотреть одновременную поддержку старого и нового секрета при ротации.
Проверить дампы, APM и аргументы фоновых заданий: секрет может утечь не только через Rails.logger. Сценарий подтверждает надёжность решения: хранить текст как данные, а разрешённый HTML пропускать через строгий sanitization с минимальным списком тегов/атрибутов.
Проверить дампы, APM и аргументы фоновых заданий: секрет может утечь не только через Rails.logger. Сценарий подтверждает надёжность решения: сначала подтвердить закрытие уязвимости негативным тестом, затем профилировать полную цепочку и оптимизировать без ослабления инварианта.
Проверить худший вход и параллельную нагрузку: защитная проверка может стать точкой отказа DoS. Сценарий подтверждает надёжность решения: хранить ключ расшифровки отдельно, ограничить доступ процесса, предусмотреть одновременную поддержку старого и нового секрета при ротации.
Проверить дампы, APM и аргументы фоновых заданий: секрет может утечь не только через Rails.logger. Сценарий подтверждает надёжность решения: хранить ключ расшифровки отдельно, ограничить доступ процесса, предусмотреть одновременную поддержку старого и нового секрета при ротации.
Вопрос 30 из 30
Какую проверку стоит добавить, чтобы не ограничиться счастливым путём «Архитектурные компромиссы»? Правильным считается только полностью согласованное утверждение.
Проверить миграции и фоновые workers: им могут требоваться другие права, но не постоянный суперпользователь. Такой контрпример нужен для решения: создавать отдельные наборы параметров на команды и не разрешать идентификаторы владельца, роли и состояние напрямую.
Проверить вложенные атрибуты и массивы: неверная форма permit может разрешить больше структуры, чем кажется. Такой контрпример нужен для решения: разделять роли по задачам, ограничивать сеть и проверять права в автоматическом развёртывании.
Проверить миграции и фоновые workers: им могут требоваться другие права, но не постоянный суперпользователь. Такой контрпример нужен для решения: разделять роли по задачам, ограничивать сеть и проверять права в автоматическом развёртывании.
Проверить ссылки с `javascript:` и опасные атрибуты: удаление одного тега ещё не означает безопасный HTML. Такой контрпример нужен для решения: разделять роли по задачам, ограничивать сеть и проверять права в автоматическом развёртывании.
Проверить миграции и фоновые workers: им могут требоваться другие права, но не постоянный суперпользователь. Такой контрпример нужен для решения: разделять данные и структуру запроса: значения параметризовать, структуру выбирать из закрытого набора объектов.