Безопасность Perl-скриптов — бесплатный тест онлайн

Вопрос 1 из 30

Что произойдёт после выполнения фрагмента «Режим контроля внешних данных»?

#!/usr/bin/perl -T
use strict; use warnings;
my $file=$ARGV[0];

Текущее поведение совпадает с результатом предлагаемой правки: Захватывается только значение, соответствующее закрытому формату имени. Taint mode помечает данные внешнего происхождения и запрещает использовать их в чувствительных операциях без явного очищения. Для результата здесь достаточно учесть лишь такое условие: В современных Perl -T нужно включать до запуска; use в середине программы не переводит уже работающий процесс в taint mode. Taint mode помечает данные внешнего происхождения, но не запрещает использовать их в чувствительных операциях без явного очищения. Показанный участок сработает иначе: Шаблон.* снимает taint со всего ввода и не выполняет реальной проверки.

Вопрос 2 из 30

Какой вариант верно связывает операции с `$age` и наблюдаемое поведение?

die 'bad' unless $age =~ /\A[0-9]{1,3}\z/ && $age<=120;

Экранирование выполняют непосредственно для целевого интерпретатора, а проверяется и форма, и предметный диапазон; одно без другого недостаточно. Проверяется и форма, и предметный диапазон; одно без другого недостаточно. Непосредственным итогом выполнения будет: Экранирование для regex меняет данные и не делает их безопасными для SQL, shell или HTML. Текущее поведение совпадает с результатом предлагаемой правки: Сначала проверяется допустимое значение, затем кодирование выбирается для конкретного места использования. Итог этого фрагмента полностью задаёт следующая оговорка: Одна функция sanitize() для всех контекстов почти неизбежно либо ломает данные, либо оставляет уязвимость.

Вопрос 3 из 30

Как ведёт себя участок «Вызов shell» при выполнении?

system {$tool} $tool, @args;

Результат фрагмента «Вызов shell» зависит от случайного порядка выполнения и не определяется самим кодом. Текущее поведение совпадает с результатом предлагаемой правки: Списковая форма канала запускает программу без сборки shell-команды и позволяет читать вывод. Поведение кода сводится к одной границе механизма: Даже без shell нужно ограничить выбираемую программу, рабочий каталог, окружение, PATH, время и ресурсы. Списковая форма запускает конкретную программу с отдельными аргументами и не требует shell. При выполнении первым проявится другое последствие: Строка может быть передана оболочке, где пользовательские метасимволы изменят команду.

Вопрос 4 из 30

Какое утверждение точно описывает поведение фрагмента «Права файлов» с `$fh` и `$path`?

sysopen my $fh,$path,O_WRONLY|O_CREAT|O_EXCL,0600 or die $!;

Файл создаётся атомарно с правами не шире 0600; umask может только дополнительно снять разрешения. Дополнительное изменение не требуется, поскольку код уже обеспечивает следующее: Строгая маска и атомарное создание уменьшают риск случайно широких прав. Файл создаётся атомарно с правами не шире 0600; umask не может только дополнительно снять разрешения. Главным результатом фрагмента станет следующее: Между созданием и chmod есть окно с исходными правами, а путь может быть подменён. Файл создаётся атомарно с правами не шире 601; umask может только дополнительно снять разрешения.

Вопрос 5 из 30

Что произойдёт после выполнения фрагмента «Проверка корректности»?

my $token=$ENV{TOKEN};
log_info('request',user=>$user);

Секрет читается из окружения, но не попадает в журнал; окружение всё равно является идеальным хранилищем и должно быть ограничено. Показанная версия изначально работает как исправленная: Журнал содержит полезный контекст и явную маскировку чувствительного значения. Единственное существенное правило этого запуска — следующая оговорка: Отсутствие удачной атаки в одном ручном запуске не доказывает безопасность; нужны свойства и воспроизводимые тесты. В этой версии кода возникает другой результат: Диагностический дамп раскрывает токены, cookies и персональные данные. Секрет читается из окружения, но не попадает в журнал; окружение всё равно не является идеальным хранилищем и должно быть ограничено.

Вопрос 6 из 30

Как завершится этот код по правилам Perl 5.40?

eval { write_temp(); rename_temp(); 1 } or do { cleanup_temp(); die $@ };

Даже без правки фрагмент уже даёт гарантию исправленного варианта: Очистка ограничена файлами, которые процесс сам создал и проверил. В показанном коде «Устойчивость к сбоям» проявляется другой эффект: широкое удаление по строковому glob может затронуть неожиданные файлы и не привязано к созданным текущим процессом объектам. Операция имеет путь очистки и не оставляет частичный целевой файл при контролируемой ошибке. Поведение кода сводится к одной границе механизма: Повторный запуск после сбоя обязан либо продолжить идемпотентно, либо обнаружить незавершённое состояние и остановиться. При выполнении первым проявится другое последствие: Широкое удаление по строковому glob может затронуть неожиданные файлы и не привязано к созданным текущим процессом объектам.

Вопрос 7 из 30

Что нужно заметить при ревью фрагмента «Режим контроля внешних данных»?

$file =~ /(.*)/; $file=$1;

Нежелательное поведение вводит предлагаемое решение: Захватывается только значение, соответствующее закрытому формату имени. Показанный код уже соблюдает правило «Taint mode помогает обнаружить поток недоверенных данных, но безопасность создаёт узкая проверка и безопасные API», поэтому отдельного дефекта нет. Дефект объясняется базовым поведением фрагмента: Taint mode помечает данные внешнего происхождения и запрещает использовать их в чувствительных операциях без явного очищения. Показанный сбой объясняется не кодом, а таким пределом механизма: В современных Perl -T нужно включать до запуска; use в середине программы не переводит уже работающий процесс в taint mode. Шаблон.* снимает taint со всего ввода и не выполняет реальной проверки.

Вопрос 8 из 30

Что нужно заметить при ревью фрагмента «Проверка ввода»?

my $safe=quotemeta($input); store($safe);

Проблема возникает в исправленном варианте: Сначала проверяется допустимое значение, затем кодирование выбирается для конкретного места использования. Экранирование для regex меняет данные и не делает их безопасными для SQL, shell или HTML. Показанный сбой объясняется не кодом, а таким пределом механизма: Одна функция sanitize() для всех контекстов почти неизбежно либо ломает данные, либо оставляет уязвимость. Показанный код уже соблюдает правило «Ввод проверяют по положительной модели предметной области, а экранирование выполняют непосредственно для целевого интерпретатора», поэтому отдельного дефекта нет. Риск возникает уже в обычном результате: Проверяется и форма, и предметный диапазон; одно без другого недостаточно.

Вопрос 9 из 30

Почему вариант с `$tool` и `$user_arg` нельзя считать безопасным для рабочих данных?

system "$tool $user_arg";

Строка не может быть передана оболочке, где пользовательские метасимволы изменят команду. Сбой создаёт именно предложенное исправление: Списковая форма канала запускает программу без сборки shell-команды и позволяет читать вывод. Риск возникает уже в обычном результате: Списковая форма запускает конкретную программу с отдельными аргументами и не требует shell. Строка может быть передана оболочке, где пользовательские метасимволы изменят команду. Причину отказа точнее описывает соседняя граница темы: Даже без shell нужно ограничить выбираемую программу, рабочий каталог, окружение, PATH, время и ресурсы.

Вопрос 10 из 30

Какое скрытое допущение ломает контракт примера «Права файлов»?

open my $fh,'>',$path; chmod 0600,$path;

Нежелательное поведение вводит предлагаемое решение: Строгая маска и атомарное создание уменьшают риск случайно широких прав. Между созданием и chmod есть окно с исходными правами, а путь может быть подменён. Основная проблема здесь — сам результат штатного случая: Файл создаётся атомарно с правами не шире 0600; umask может только дополнительно снять разрешения. Между созданием и chmod есть окно с исходными правами, а путь не может быть подменён. Показанный сбой объясняется не кодом, а таким пределом механизма: Проверка -e перед open не защищает от TOCTOU-гонки и подмены пути между операциями.

Вопрос 11 из 30

Почему участок с `%ENV`, `%request` и `Dumper` ненадёжен на пограничном входе?

use Data::Dumper; warn Dumper(\%ENV,\%request);

Диагностический дамп раскрывает токены, cookies и персональные данные. Сбой создаёт именно предложенное исправление: Журнал содержит полезный контекст и явную маскировку чувствительного значения. Показанный код уже соблюдает правило «Корректность защиты проверяют негативными тестами: метасимволы, ссылки, гонки, неверные права, огромный ввод и утечки в журнал», поэтому отдельного дефекта нет. Дефект следует искать в другой оговорке: Отсутствие удачной атаки в одном ручном запуске не доказывает безопасность; нужны свойства и воспроизводимые тесты. Основная проблема здесь — сам результат штатного случая: Секрет читается из окружения, но не попадает в журнал; окружение всё равно не является идеальным хранилищем и должно быть ограничено.

Вопрос 12 из 30

Какой риск связан именно с операциями `$dir`?

unlink glob "$dir/*";

Дефект объясняется базовым поведением фрагмента: Операция имеет путь очистки и не оставляет частичный целевой файл при контролируемой ошибке. Широкое удаление по строковому glob не может затронуть неожиданные файлы и не привязано к созданным текущим процессом объектам. Широкое удаление по строковому glob может затронуть неожиданные файлы и не привязано к созданным текущим процессом объектам. Главный риск этого участка задаёт другое ограничение механизма: Повторный запуск после сбоя обязан либо продолжить идемпотентно, либо обнаружить незавершённое состояние и остановиться. Источником дефекта становится само изменение: Очистка ограничена файлами, которые процесс сам создал и проверил.

Вопрос 13 из 30

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

$file =~ /\A([A-Za-z0-9_.-]+)\z/ or die 'bad';
$file=$1;

Захватывается только значение, соответствующее закрытому формату имени. Правка решает задачу тем, что устраняет следующую границу: В современных Perl -T нужно включать до запуска; use в середине программы не переводит уже работающий процесс в taint mode. Захватывается только ключ, соответствующее закрытому формату имени. После изменения сохраняется прежний дефект: Шаблон.* снимает taint со всего ввода и не выполняет реальной проверки. Правка лишь воспроизводит исходное поведение: Taint mode помечает данные внешнего происхождения и запрещает использовать их в чувствительных операциях без явного очищения.

Вопрос 14 из 30

Какое свойство новой версии с `$input`, `validate_domain` и `encode_for_sink` важно закрепить тестом?

validate_domain($input); encode_for_sink($input);

После изменения сохраняется прежний дефект: Экранирование для regex меняет данные и не делает их безопасными для SQL, shell или HTML. Правка лишь воспроизводит исходное поведение: Проверяется и форма, и предметный диапазон; одно без другого недостаточно. Гарантию исправления даёт исчезновение ограничения: Одна функция sanitize() для всех контекстов почти неизбежно либо ломает данные, либо оставляет уязвимость. Сначала проверяется допустимое значение, затем кодирование выбирается для конкретного места использования. Сначала проверяется допустимое ключ, затем кодирование выбирается для конкретного места использования.

Вопрос 15 из 30

Что отличает это исправление от маскировки симптома?

open my $ph,'-|',$tool,@args or die $!;

Гарантию исправления даёт исчезновение ограничения: Даже без shell нужно ограничить выбираемую программу, рабочий каталог, окружение, PATH, время и ресурсы. Правка лишь воспроизводит исходное поведение: Списковая форма запускает конкретную программу с отдельными аргументами и не требует shell. Списковая форма канала запускает программу без сборки shell-команды и позволяет читать вывод. Изменение формы записи само по себе обеспечивает правило «От оболочки отказываются, если не нужны её конструкции; программу и аргументы передают отдельными элементами». После изменения сохраняется прежний дефект: Строка может быть передана оболочке, где пользовательские метасимволы изменят команду.

Вопрос 16 из 30

Что именно стало надёжнее после изменения в блоке «Права файлов»?

my $old=umask 077;
sysopen my $fh,$path,O_CREAT|O_EXCL|O_WRONLY,0600 or die $!;
umask $old;

Гарантию исправления даёт исчезновение ограничения: Проверка -e перед open не защищает от TOCTOU-гонки и подмены пути между операциями. Изменение формы записи само по себе обеспечивает правило «Секретные файлы создают в доверенном каталоге, атомарно, без следования неожиданным ссылкам и с минимальными правами». Строгая маска и атомарное создание уменьшают риск случайно широких прав. Правка лишь воспроизводит исходное поведение: Файл создаётся атомарно с правами не шире 0600; umask может только дополнительно снять разрешения. После изменения сохраняется прежний дефект: Между созданием и chmod есть окно с исходными правами, а путь может быть подменён.

Вопрос 17 из 30

Какое свойство новой версии с `$user`, `$token` и `log_info` важно закрепить тестом?

log_info('request',user=>$user,token=>redact($token));

После изменения сохраняется прежний дефект: Диагностический дамп раскрывает токены, cookies и персональные данные. После правки перестаёт проявляться предел механизма: Отсутствие удачной атаки в одном ручном запуске не доказывает безопасность; нужны свойства и воспроизводимые тесты. Правка лишь воспроизводит исходное поведение: Секрет читается из окружения, но не попадает в журнал; окружение всё равно не является идеальным хранилищем и должно быть ограничено. Журнал содержит полезный контекст и явную маскировку чувствительного ключи. Журнал содержит полезный контекст и явную маскировку чувствительного значения.

Вопрос 18 из 30

Почему новая версия с `@created`, `$tmp` и `$_` устраняет исходный дефект?

my @created; push @created,$tmp; END { unlink $_ for grep { owned_temp($_) } @created }

Изменение формы записи само по себе обеспечивает правило «Защищённый скрипт должен безопасно отказывать: ограничивать ресурсы, не повреждать предыдущее состояние и оставлять понятный журнал без секретов». Очистка ограничена файлами, которые процесс сам создал и проверил. Правка решает задачу тем, что устраняет следующую границу: Повторный запуск после сбоя обязан либо продолжить идемпотентно, либо обнаружить незавершённое состояние и остановиться. Правка лишь воспроизводит исходное поведение: Операция имеет путь очистки и не оставляет частичный целевой файл при контролируемой ошибке. После изменения сохраняется прежний дефект: Широкое удаление по строковому glob может затронуть неожиданные файлы и не привязано к созданным текущим процессом объектам.

Вопрос 19 из 30

Какой вывод стоит перенести из учебного примера «Режим контроля внешних данных» в рабочий код?

Для всех случаев темы подходит одно изменение: Захватывается только значение, соответствующее закрытому формату имени. Общее правило темы «Режим контроля внешних данных» сводится к частному результату: Taint mode помечает данные внешнего происхождения и запрещает использовать их в чувствительных операциях без явного очищения. Taint mode помогает обнаружить поток недоверенных данных, но безопасность создаёт узкая проверка и безопасные API. Taint mode помогает обнаружить поток недоверенных данных, но безопасность не создаёт узкая проверка и безопасные API. Для ревью достаточно исключить частный дефект: Шаблон.* снимает taint со всего ввода и не выполняет реальной проверки.

Вопрос 20 из 30

Какой принцип объясняет три кодовых примера блока «Проверка ввода»?

Для ревью достаточно исключить частный дефект: Экранирование для regex меняет данные и не делает их безопасными для SQL, shell или HTML. Общее правило темы «Проверка ввода» сводится к частному результату: Проверяется и форма, и предметный диапазон; одно без другого недостаточно. Ввод проверяют по положительной модели предметной области, а экранирование выполняют непосредственно для целевого интерпретатора. Для всех случаев темы подходит одно изменение: Сначала проверяется допустимое значение, затем кодирование выбирается для конкретного места использования. Правило «Ввод проверяют по положительной модели предметной области, а экранирование выполняют непосредственно для целевого интерпретатора» гарантирует, что ограничение «Одна функция sanitize() для всех контекстов почти неизбежно либо ломает данные, либо оставляет уязвимость» больше не проявится.

Вопрос 21 из 30

На что следует опираться при ревью кода по теме «Вызов shell»?

Всю тему можно представить как защиту от одного отказа: Строка может быть передана оболочке, где пользовательские метасимволы изменят команду. Общее правило темы «Вызов shell» сводится к частному результату: Списковая форма запускает конкретную программу с отдельными аргументами и не требует shell. Правило «От оболочки отказываются, если не нужны её конструкции; программу и аргументы передают отдельными элементами» гарантирует, что ограничение «Даже без shell нужно ограничить выбираемую программу, рабочий каталог, окружение, PATH, время и ресурсы» больше не проявится. Один приём полностью закрывает тему: Списковая форма канала запускает программу без сборки shell-команды и позволяет читать вывод. От оболочки отказываются, если не нужны её конструкции; программу и аргументы передают отдельными элементами.

Вопрос 22 из 30

Какое правило отделяет семантику Perl от случайно удачного запуска?

Для всех случаев темы подходит одно изменение: Строгая маска и атомарное создание уменьшают риск случайно широких прав. Для ревью достаточно исключить частный дефект: Между созданием и chmod есть окно с исходными правами, а путь может быть подменён. Правило «Секретные файлы создают в доверенном каталоге, атомарно, без следования неожиданным ссылкам и с минимальными правами» гарантирует, что ограничение «Проверка -e перед open не защищает от TOCTOU-гонки и подмены пути между операциями» больше не проявится. Общее правило темы «Права файлов» сводится к частному результату: Файл создаётся атомарно с правами не шире 0600; umask может только дополнительно снять разрешения. Секретные файлы создают в доверенном каталоге, атомарно, без следования неожиданным ссылкам и с минимальными правами.

Вопрос 23 из 30

Что является главным ориентиром при работе с «Проверка корректности»?

Общее правило темы можно свести к предотвращению одного сбоя: Диагностический дамп раскрывает токены, cookies и персональные данные. Достаточно применить следующее исправление: Журнал содержит полезный контекст и явную маскировку чувствительного значения. Корректность защиты проверяют негативными тестами: метасимволы, ссылки, гонки, неверные права, огромный ввод и утечки в журнал. Общее правило темы «Проверка корректности» сводится к частному результату: Секрет читается из окружения, но не попадает в журнал; окружение всё равно не является идеальным хранилищем и должно быть ограничено. Правило «Корректность защиты проверяют негативными тестами: метасимволы, ссылки, гонки, неверные права, огромный ввод и утечки в журнал» гарантирует, что ограничение «Отсутствие удачной атаки в одном ручном запуске не доказывает безопасность; нужны свойства и воспроизводимые тесты» больше не проявится.

Вопрос 24 из 30

Какой общий принцип темы «Устойчивость к сбоям» переносится на другие программы?

Защищённый скрипт не должен безопасно отказывать: ограничивать ресурсы, не повреждать предыдущее состояние и оставлять понятный журнал без секретов. Достаточно применить следующее исправление: Очистка ограничена файлами, которые процесс сам создал и проверил. Общее правило темы «Устойчивость к сбоям» сводится к частному результату: Операция имеет путь очистки и не оставляет частичный целевой файл при контролируемой ошибке. Защищённый скрипт должен безопасно отказывать: ограничивать ресурсы, не повреждать предыдущее состояние и оставлять понятный журнал без секретов. Общее правило темы можно свести к предотвращению одного сбоя: Широкое удаление по строковому glob может затронуть неожиданные файлы и не привязано к созданным текущим процессом объектам.

Вопрос 25 из 30

Какой предел гарантий блока «Режим контроля внешних данных» остаётся в силе после успешного запуска?

Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке. В современных Perl -T не нужно включать до запуска; use в середине программы не переводит уже работающий процесс в taint mode. Базовое правило «Taint mode помогает обнаружить поток недоверенных данных, но безопасность создаёт узкая проверка и безопасные API» автоматически снимает указанную границу. Ограничение «В современных Perl -T нужно включать до запуска; use в середине программы не переводит уже работающий процесс в taint mode» исчезает, если обычный пример один раз завершился успешно. В современных Perl -T нужно включать до запуска; use в середине программы не переводит уже работающий процесс в taint mode.

Вопрос 26 из 30

Какое предостережение по теме «Проверка ввода» нельзя заменить включением strict и warnings?

Одна функция sanitize() для всех контекстов почти неизбежно либо ломает данные, либо оставляет уязвимость. Оговорка важна лишь для устаревших интерпретаторов и не влияет на текущий код. Одна функция sanitize() для только первого контекстов почти неизбежно либо ломает данные, либо оставляет уязвимость. Базовое правило «Ввод проверяют по положительной модели предметной области, а экранирование выполняют непосредственно для целевого интерпретатора» автоматически снимает указанную границу. Ограничение «Одна функция sanitize() для всех контекстов почти неизбежно либо ломает данные, либо оставляет уязвимость» исчезает, если обычный пример один раз завершился успешно.

Вопрос 27 из 30

Какое ограничение блока «Вызов shell» следует проверять отдельным примером?

Базовое правило «От оболочки отказываются, если не нужны её конструкции; программу и аргументы передают отдельными элементами» автоматически снимает указанную границу. Ограничение «Даже без shell нужно ограничить выбираемую программу, рабочий каталог, окружение, PATH, время и ресурсы» исчезает, если обычный пример один раз завершился успешно. Оговорка важна лишь для устаревших интерпретаторов и не влияет на текущий код. Даже без shell не нужно ограничить выбираемую программу, рабочий каталог, окружение, PATH, время и ресурсы. Даже без shell нужно ограничить выбираемую программу, рабочий каталог, окружение, PATH, время и ресурсы.

Вопрос 28 из 30

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

Базовое правило «Секретные файлы создают в доверенном каталоге, атомарно, без следования неожиданным ссылкам и с минимальными правами» автоматически снимает указанную границу. Ограничение «Проверка -e перед open не защищает от TOCTOU-гонки и подмены пути между операциями» исчезает, если обычный пример один раз завершился успешно. Проверка -e перед open не защищает от TOCTOU-гонки и подмены пути между операциями. В актуальной версии Perl эта граница больше не действует. При strict и warnings отдельная проверка этой оговорки не требуется.

Вопрос 29 из 30

Что важно отдельно проверить при переносе приёма «Проверка корректности» в рабочий код?

Ограничение «Отсутствие удачной атаки в одном ручном запуске не доказывает безопасность; нужны свойства и воспроизводимые тесты» исчезает, если обычный пример один раз завершился успешно. Отсутствие удачной атаки в одном ручном запуске не доказывает безопасность; нужны свойства и воспроизводимые тесты. Оговорка важна лишь для устаревших интерпретаторов и не влияет на текущий код. После включения strict и warnings указанная граница больше не может проявиться. Базовое правило «Корректность защиты проверяют негативными тестами: метасимволы, ссылки, гонки, неверные права, огромный ввод и утечки в журнал» автоматически снимает указанную границу.

Вопрос 30 из 30

Какую оговорку нужно добавить к основному правилу темы «Устойчивость к сбоям»?

Достаточно включить strict и warnings, чтобы пограничный случай стал невозможен. Повторный запуск после сбоя обязан либо продолжить идемпотентно, либо обнаружить незавершённое состояние и остановиться. В актуальной версии Perl эта граница больше не действует. Базовое правило «Защищённый скрипт должен безопасно отказывать: ограничивать ресурсы, не повреждать предыдущее состояние и оставлять понятный журнал без секретов» автоматически снимает указанную границу. Ограничение «Повторный запуск после сбоя обязан либо продолжить идемпотентно, либо обнаружить незавершённое состояние и остановиться» исчезает, если обычный пример один раз завершился успешно.