perlsec - Интернет в облаке

ПРОГРАММА:

ИМЯ

perlsec - безопасность Perl

ОПИСАНИЕ

Perl разработан, чтобы упростить безопасное программирование даже при работе с дополнительными
привилегии, такие как программы setuid или setgid. В отличие от большинства оболочек командной строки, которые
основанный на нескольких проходах подстановки в каждой строке скрипта, Perl использует более
обычная схема оценки с меньшим количеством скрытых загвоздок. Кроме того, поскольку
язык имеет больше встроенных функций, он может меньше полагаться на внешние (и, возможно,
ненадежные) программы для достижения своих целей.

БЕЗОПАСНОСТЬ УЯЗВИМОСТЕЙ Контакт ИНФОРМАЦИЯ

Если вы считаете, что нашли уязвимость в системе безопасности Perl, напишите нам по электронной почте.
[электронная почта защищена] с подробностями. Это указывает на закрытую подписку,
неархивированный список рассылки. Пожалуйста, используйте этот адрес только для проблем безопасности в Perl
core, а не для модулей, независимо распределенных на CPAN.

БЕЗОПАСНОСТЬ МЕХАНИЗМЫ И ОБЕСПОКОЕННОСТЬ

зараза Режим
Perl автоматически включает набор специальных проверок безопасности, называемых зараза Режим, когда это
обнаруживает, что его программа работает с разными реальными и эффективными идентификаторами пользователя или группы. В
бит setuid в разрешениях Unix - это режим 04000, бит setgid - режим 02000; либо, либо оба
может быть установлен. Вы также можете явно включить режим заражения, используя -T флаг командной строки.
Этот флаг сильно предлагается для серверных программ и любой программы, запускаемой от имени
кто-то другой, например сценарий CGI. После включения режима заражения он остается включенным до конца
ваш сценарий.

В этом режиме Perl принимает особые меры предосторожности, называемые зараза проверки чтобы предотвратить оба
очевидные и тонкие ловушки. Некоторые из этих проверок достаточно просты, например, проверка
что каталоги пути не доступны для записи другим лицам; осторожные программисты всегда использовали
такие проверки. Однако другие проверки лучше всего поддерживаются самим языком, и
именно эти проверки особенно способствуют повышению безопасности Perl-программы с установленным идентификатором.
чем соответствующая программа C.

Вы не можете использовать данные, полученные извне вашей программы, чтобы повлиять на что-то еще за пределами вашей программы.
ваша программа - по крайней мере, не случайно. Все аргументы командной строки, окружение
переменные, информация о локали (см. perllocale), результаты определенных системных вызовов
(«readdir ()», «readlink ()», переменная «shmread ()», сообщения, возвращаемые
"msgrcv ()", поля пароля, gcos и оболочки, возвращаемые вызовом "getpwxxx ()"), и
все входные файлы помечаются как «испорченные». Испорченные данные нельзя использовать напрямую или
косвенно в любой команде, которая вызывает суб-оболочку, или в любой команде, которая изменяет
файлы, каталоги или процессы, после Исключения:

· Аргументы для «печати» и «системной записи»: проверено на наличие порчи.

· Символьные методы

$ obj -> $ method (@args);

и символические подссылки

& {$ foo} (@ args);
$ foo -> (@ args);

не проверяются на загрязнение. Это требует особой осторожности, если вы не хотите
внешние данные, чтобы повлиять на ваш поток управления. Если вы внимательно не ограничите то, что эти
символические значения, люди могут вызывать функции внешнюю ваш код Perl, например
POSIX :: system, и в этом случае они могут запускать произвольный внешний код.

· Хеш-ключи никогда испорченный.

Из соображений эффективности Perl придерживается консервативного взгляда на то, не испорчены ли данные. Если
выражение содержит испорченные данные, любое подвыражение может считаться испорченным, даже если
значение подвыражения не зависит от испорченных данных.

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

Например:

$ arg = сдвиг; # $ arg испорчен
$ hid = $ arg. 'бар'; # $ hid также испорчен
$ line = <>; # Испорченный
$ line = ; # Также испорченный
открой FOO, «/ home / me / bar» или умри $ !;
$ line = ; # Все еще испорчен
$ path = $ ENV {'ПУТЬ'}; # Испорченный, но см. Ниже
$ data = 'abc'; # Не испорчен

система "echo $ arg"; # Ненадежный
система "/ bin / echo", $ arg; # Считается небезопасным
# (Perl не знает о / bin / echo)
система "echo $ hid"; # Ненадежный
система "echo $ data"; # Небезопасен, пока не установлен PATH

$ path = $ ENV {'ПУТЬ'}; # $ path теперь испорчен

$ ENV {'ПУТЬ'} = '/ бен:/ USR / бен';
удалить @ENV {'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};

$ path = $ ENV {'ПУТЬ'}; # $ path теперь НЕ испорчен
система "echo $ data"; # Теперь безопасно!

open (FOO, "<$ arg"); # OK - файл только для чтения
open (FOO, "> $ arg"); # Не нормально - пытаюсь написать

open (FOO, "echo $ arg |"); # Не хорошо
open (FOO, "- |")
или exec 'echo', $ arg; # Также не ОК

$ shout = `echo $ arg`; # Небезопасно, $ shout испорчен

отменить связь с $ data, $ arg; # Ненадежный
umask $ arg; # Ненадежный

exec "echo $ arg"; # Ненадежный
exec "эхо", $ arg; # Ненадежный
exec "sh", '-c', $ arg; # Очень небезопасно!

@files = <*. c>; # небезопасно (использует readdir () или аналогичный)
@ файлы = glob ('*. c'); # небезопасно (использует readdir () или аналогичный)

# В любом случае результаты glob испорчены, поскольку список
# имена файлов поступают извне программы.

$ bad = ($ arg, 23); # $ bad будет испорчен
$ arg, `истина`; # Небезопасно (хотя на самом деле это не так)

Если вы попытаетесь сделать что-то небезопасное, вы получите фатальную ошибку, например,
«Небезопасная зависимость» или «Небезопасная $ ENV {PATH}».

Исключением из принципа «одно испорченное значение портит все выражение» является
тернарный условный оператор "?:". Поскольку код с тернарным условным

$ result = $ tainted_value? «Незапятнанный»: «Также незапятнанный»;

эффективно

if ($ tainted_value) {
$ result = "Неокрашенный";
} Еще {
$ result = "Также нетронутый";
}

нет смысла испортить $ result.

Отмывание и обнаружения испорченный Данные
Чтобы проверить, содержит ли переменная испорченные данные и чье использование, таким образом, вызовет
Сообщение «Небезопасная зависимость», вы можете использовать функцию «tainted ()» Scalar :: Util.
модуль, доступный в вашем ближайшем зеркале CPAN и включенный в Perl, начиная с
выпуск 5.8.0. Или вы можете использовать следующую функцию is_tainted ().

саб is_tainted {
местный $ @; # Не загрязняйте ценность вызывающего абонента.
возвращение ! eval {eval ("#". substr (join ("", @_), 0, 0)); 1};
}

Эта функция использует тот факт, что наличие испорченных данных где-либо в пределах
выражение делает все выражение испорченным. Было бы неэффективно для каждого
оператор, чтобы проверить каждый аргумент на испорченность. Вместо этого, немного более эффективный и
используется консервативный подход: если любое испорченное значение было получено в пределах одного и того же
выражение, все выражение считается испорченным.

Но проверка на нечистоту дает вам лишь некоторые возможности. Иногда нужно просто очистить
испорченность данных. Значения можно не испортить, используя их в качестве ключей в хэше; иначе
единственный способ обойти механизм заражения - это ссылаться на подшаблоны из обычного
совпадение выражения. Perl предполагает, что если вы ссылаетесь на подстроку, используя $ 1, $ 2 и т. Д. В
незапятнанный шаблон, что вы знали, что делаете, когда писали этот шаблон. Что
означает использовать немного мысли - не просто слепо ничего не очищайте, иначе вы победите
весь механизм. Лучше проверить, что переменная содержит только хорошие символы (для
определенные значения «хорошо»), а не проверять, есть ли в нем плохие символы. Это
потому что слишком легко пропустить плохих персонажей, о которых вы никогда не думали.

Вот тест, чтобы убедиться, что данные не содержат ничего, кроме символов "слова".
(буквы, цифры и подчеркивания), дефис, знак at или точка.

if ($ data = ~ /^([-\@\w.pting+)$/) {
$ data = $ 1; # $ data теперь не поврежден
} Еще {
die "Плохие данные в '$ data'"; # записать это где-нибудь
}

Это довольно безопасно, потому что "/ \ w + /" обычно не соответствует метасимволам оболочки и не соответствует
точка, тире или at будет означать что-то особенное для оболочки. Использование "/.+ / "будет
был небезопасен в теории, потому что пропускает все, но Perl не проверяет
что. Урок состоит в том, что, не раскрашивая, вы должны быть чрезвычайно осторожны со своим
узоры. Отмывание данных с использованием регулярных выражений - это Важно механизм неокрашивания
грязные данные, если вы не используете описанную ниже стратегию для создания дочернего элемента меньшего
привилегия.

В примере $ data не удаляется, если действует "использовать локаль", потому что символы
совпадающие с "\ w", определяются локалью. Perl считает, что определения локали
ненадежны, поскольку содержат данные извне программы. Если вы пишете
программа с поддержкой локали и хочет отмыть данные с помощью регулярного выражения, содержащего "\ w",
в том же блоке перед выражением поставьте «no locale». См. «БЕЗОПАСНОСТЬ» в perllocale
для дальнейшего обсуждения и примеров.

Коммутаторы On "#!" линия
Когда вы создаете исполняемый файл сценария, чтобы его можно было использовать в качестве команды, система
будет передавать переключатели на perl из сценария #! линия. Perl проверяет, что любая командная строка
переключатели, присвоенные сценарию setuid (или setgid), фактически совпадают с переключателями, установленными в #! линия.
В некоторых Unix и Unix-подобных средах на #! линия, так что вы можете
в таких системах нужно использовать что-то вроде "-wU" вместо "-w -U". (Эта проблема
должен возникать только в Unix или Unix-подобных средах, которые поддерживают #! и setuid или setgid
скрипты.)

зараза Режим и @ИНК
Когда действует режим заражения ("-T"), символ "." каталог удаляется из @INC, а
переменные среды «PERL5LIB» и «PERLLIB» игнорируются Perl. Вы все еще можете отрегулировать
@INC извне программы с помощью параметра командной строки "-I", как описано в
perlrun. Две переменные среды игнорируются, потому что они скрыты, а пользователь
запуск программы может не знать, что они установлены, тогда как параметр "-I" явно
видимый и, следовательно, разрешенный.

Другой способ изменить @INC без изменения программы - использовать прагму "lib",
например:

perl -Mlib = / foo программа

Преимущество использования «-Mlib = / foo» перед «-I / foo» состоит в том, что первое автоматически
Удалите все повторяющиеся каталоги, в то время как последние не будут.

Обратите внимание, что если в @INC добавлена ​​испорченная строка, будет сообщено о следующей проблеме:

Небезопасная зависимость в require при работе с ключом -T

Уборка Up Ваша Тропа
Для сообщений «Небезопасный $ ENV {PATH}» вам необходимо установить $ ENV {'PATH'} на известное значение, и
каждый каталог в пути должен быть абсолютным и не разрешенным для записи другими лицами, кроме его владельца и
группа. Вы можете быть удивлены, получив это сообщение, даже если путь к вашему исполняемому файлу
полностью квалифицирован. Это сгенерирован, потому что вы не указали полный путь к
программа; вместо этого он создается, потому что вы никогда не устанавливали переменную среды PATH или
вы не настроили его на что-то безопасное. Поскольку Perl не может гарантировать, что
рассматриваемый исполняемый файл сам не собирается развернуться и выполнить какую-то другую программу
это зависит от вашего PATH, он гарантирует, что вы установили PATH.

PATH - не единственная переменная среды, которая может вызвать проблемы. Потому что некоторые
оболочки могут использовать переменные IFS, CDPATH, ENV и BASH_ENV, Perl проверяет, что они
либо пустым, либо незапятнанным при запуске подпроцессов. Вы можете добавить что-то вроде
это к вашим скриптам проверки сети и заражения.

удалить @ENV {qw (IFS CDPATH ENV BASH_ENV)}; # Сделать% ENV безопаснее

Также возможны проблемы с другими операциями, которым все равно,
используйте испорченные значения. Разумно используйте тесты файлов при работе с любым пользователем -
предоставленные имена файлов. По возможности открывайте и т. Д. после правильно отбрасывая любые специальные
привилегии пользователя (или группы!). Perl не мешает вам открывать испорченные имена файлов для
читая, так что будьте осторожны при распечатке. Механизм заражения предназначен для предотвращения
глупые ошибки, чтобы не избавиться от необходимости думать.

Perl не вызывает оболочку для раскрытия подстановочных знаков, когда вы передаете "system" и "exec".
явные списки параметров вместо строк с возможными подстановочными знаками оболочки в них.
К сожалению, функции open, glob и backtick не предоставляют такой альтернативы.
соглашение о вызовах, поэтому потребуется больше уловок.

Perl предоставляет достаточно безопасный способ открыть файл или канал из setuid или setgid.
программа: просто создайте дочерний процесс с ограниченными привилегиями, который выполняет грязную работу за
ты. Во-первых, разветвите дочерний элемент, используя специальный "открытый" синтаксис, который соединяет родительский и
ребенок у трубы. Теперь дочерний элемент сбрасывает свой набор идентификаторов и любые другие атрибуты процесса,
такие как переменные среды, umasks, текущие рабочие каталоги, назад к оригиналам или
известные безопасные значения. Затем дочерний процесс, у которого больше нет специальных разрешений,
выполняет "open" или другой системный вызов. Наконец, ребенок передает данные, которые ему удалось
доступ к родителю. Поскольку файл или канал был открыт в дочернем элементе во время работы
с меньшими привилегиями, чем родитель, его не обмануть
не должен.

Вот способ разумно безопасно делать обратные кавычки. Обратите внимание, как "exec" не вызывается с
строка, которую оболочка может расширять. Это, безусловно, лучший способ назвать то, что
может подвергаться экранированию оболочки: просто никогда не вызывайте оболочку.

использовать английский;
die "Не могу форк: $!" если не указано иное ($ pid = open (KID, "- |"));
if ($ pid) {# родитель
в то время как ( ) {
# сделай что-нибудь
}
закрыть KID;
} Еще {
мой @temp = ($ EUID, $ EGID);
мой $ orig_uid = $ UID;
мой $ orig_gid = $ GID;
$ EUID = $ UID;
$ EGID = $ GID;
# Отбросить привилегии
$ UID = $ orig_uid;
$ GID = $ orig_gid;
# Убедитесь, что привилегии действительно пропали
($ EUID, $ EGID) = @temp;
die "Не могу отказаться от привилегий"
если только $ UID == $ EUID && $ GID eq $ EGID;
$ ENV {ПУТЬ} = "/ бен:/ USR / бен"; # Минимальный ПУТЬ.
# Рассмотрите возможность еще большей дезинфекции окружающей среды.
exec 'myprog', 'arg1', 'arg2'
or die "не могу выполнить myprog: $!";
}

Аналогичная стратегия будет работать для расширения подстановочных знаков с помощью "glob", хотя вы можете использовать
"readdir" вместо этого.

Проверка на заражение наиболее полезна, когда, хотя вы уверены, что не написали
программа для раздачи фермы, вы не обязательно доверяете тем, кто в конечном итоге ее не использует
чтобы попытаться заставить его сделать что-нибудь плохое. Это такая проверка безопасности, которая
полезно для программ с установленным идентификатором и программ, запущенных от чьего-либо имени, например CGI
программ.

Однако это сильно отличается от того, чтобы даже не доверять писателю кода, чтобы он не пытался
делать что-то злое. Такое доверие необходимо, когда кто-то передает вам программу.
вы никогда раньше не видели и говорит: «Вот, запустите это». Для такой безопасности вы можете
хочу проверить модуль Safe, входящий в стандартную поставку Perl. Этот
модуль позволяет программисту настраивать специальные отсеки, в которых все системные операции
попадают в ловушку, и доступ к пространству имен тщательно контролируется. Безопасным не следует считать
пуленепробиваемый: он не помешает внешнему коду создавать бесконечные циклы,
выделять гигабайты памяти или даже злоупотреблять ошибками Perl, чтобы вызвать сбой интерпретатора хоста
или вести себя непредсказуемо. В любом случае лучше полностью избегать, если вы
действительно озабочен безопасностью.

Безопасность. ошибки
Помимо очевидных проблем, связанных с наделением систем особыми привилегиями
гибкие, как сценарии, во многих версиях Unix сценарии set-id по своей сути небезопасны
с самого начала. Проблема заключается в состоянии гонки в ядре. Между временем
ядро открывает файл, чтобы узнать, какой интерпретатор запустить и когда (now-set-id)
интерпретатор поворачивается и повторно открывает файл, чтобы интерпретировать его, рассматриваемый файл может
изменились, особенно если в вашей системе есть символические ссылки.

К счастью, иногда эту "фичу" ядра можно отключить. К сожалению, есть
два способа отключить его. Система может просто объявить вне закона скрипты с любым установленным битом set-id,
что не очень помогает. С другой стороны, он может просто игнорировать биты set-id в скриптах.

Однако, если функция сценария set-id ядра не отключена, Perl будет громко жаловаться.
что ваш сценарий set-id небезопасен. Вам нужно будет либо отключить идентификатор набора ядра
скрипт или поместите вокруг скрипта оболочку C. Обертка AC - это просто скомпилированный
программа, которая ничего не делает, кроме вызова вашей программы на Perl. Скомпилированные программы не
из-за ошибки ядра, которая поражает сценарии set-id. Вот простая обертка, написанная
в C:

#define REAL_PATH "/ путь / к / скрипту"
основной (ac, av)
char ** av;
{
execv (REAL_PATH, av);
}

Скомпилируйте эту оболочку в двоичный исполняемый файл, а затем сделайте it а не ваш сценарий
setuid или setgid.

В последние годы поставщики начали поставлять системы, свободные от этой врожденной ошибки безопасности.
В таких системах, когда ядро ​​передает имя сценария set-id для открытия в
интерпретатор, вместо того, чтобы использовать имя пути, на которое может вмешиваться, он вместо этого передает
/ dev / fd / 3. Это специальный файл, уже открытый в скрипте, поэтому не может быть
условие гонки для использования злыми скриптами. В этих системах Perl должен быть скомпилирован
с "-DSETUID_SCRIPTS_ARE_SECURE_NOW". В Настроить программа, собирающая Perl, пытается
выясните это сами, поэтому вам никогда не придется указывать это самостоятельно. Самый
современные выпуски SysVr4 и BSD 4.4 используют этот подход, чтобы избежать гонки ядра
состояние.

Защищающий Ваша Программы
Есть несколько способов скрыть исходный код ваших программ Perl с разными уровнями.
«безопасности».

Но прежде всего вы не может отнять разрешение на чтение, потому что исходный код должен
быть читаемым для компиляции и интерпретации. (Это не значит, что компьютерная графика
исходный код скрипта, тем не менее, доступен для чтения людям в Интернете.) Итак, вы должны оставить
разрешения на социально-дружественном уровне 0755. Это позволяет людям в вашей локальной системе
видеть только ваш источник.

Некоторые ошибочно считают это проблемой безопасности. Если ваша программа небезопасна
вещи, и полагается на людей, не знающих, как использовать эту незащищенность, это не
безопасный. Часто кто-то может определить небезопасные вещи и воспользоваться
их без просмотра источника. Безопасность через безвестность, имя для сокрытия вашего
ошибки вместо того, чтобы их исправлять, на самом деле мало безопасны.

Вы можете попробовать использовать шифрование с помощью фильтров источника (Filter :: * из CPAN или
Filter :: Util :: Call и Filter :: Simple начиная с Perl 5.8). Но взломщики могли бы
расшифровать это. Вы можете попробовать использовать компилятор и интерпретатор байтового кода, описанные ниже, но
взломщики могут его декомпилировать. Вы можете попробовать использовать компилятор нативного кода
описано ниже, но взломщики могут его разобрать. Эти позы разной степени
трудностей для людей, желающих разобраться в вашем коде, но никто не может окончательно скрыть это
(это верно для любого языка, а не только для Perl).

Если вас беспокоит, что люди извлекают выгоду из вашего кода, то суть в том, что
только ограничительная лицензия не даст вам правовой защиты. Лицензируйте свое программное обеспечение и
приправьте его угрожающими заявлениями типа "Это неопубликованное проприетарное программное обеспечение
XYZ Corp. Ваш доступ к нему не дает вам разрешения на его использование, бла-бла-бла ».
следует обратиться к юристу, чтобы убедиться, что формулировка вашей лицензии останется в силе в суде.

Unicode
Юникод - это новая и сложная технология, и можно легко упустить из виду определенную безопасность.
подводные камни. См. Perluniintro для обзора и perlunicode для деталей, а также «Безопасность
Применение Unicode »в perlunicode, в частности, для обеспечения безопасности.

алгоритмический Многогранность нападки
Некоторые внутренние алгоритмы, используемые в реализации Perl, можно атаковать, выбрав
входные данные следует осторожно использовать, чтобы отнимать большое количество времени или пространства, либо и того, и другого. Это может
привести к так называемому Отказ of Сервис (DoS) атаки.

· Алгоритм хеширования - алгоритмы хеширования, подобные тому, который используется в Perl, хорошо известны как
уязвимы для коллизионных атак на их хэш-функцию. Такие атаки включают
создание набора ключей, которые попадают в одно и то же ведро, что приводит к неэффективности
поведение. Такие атаки часто зависят от обнаружения начального числа используемой хеш-функции.
для сопоставления ключей с ведрами. Затем это семя используется для перебора набора ключей, который может
использоваться для организации атаки отказа в обслуживании. В Perl 5.8.1 были внесены изменения в
укрепить Perl для таких атак, а позже, в Perl 5.18.0, эти функции были
усилена и добавлена ​​дополнительная защита.

На момент написания этой статьи Perl 5.18.0 считался хорошо защищенным от
атаки алгоритмической сложности на его хеш-реализацию. Во многом это связано с
следующие меры смягчают атаки:

Рандомизация хеш-начального числа
Чтобы невозможно было узнать, какое семя генерировать набор ключей атаки
для этого начального числа случайным образом инициализируется при запуске процесса. Это может быть отменено
используя переменную среды PERL_HASH_SEED, см. «PERL_HASH_SEED» в perlrun.
Эта переменная среды контролирует, как фактически хранятся элементы, а не то, как они
представлен через «ключи», «значения» и «каждый».

Рандомизация обхода хэша
Независимо от того, какое начальное число используется в хэш-функции, «ключи», «значения» и
"каждый" возвращает элементы в случайном порядке по хешам. Изменение хеша путем вставки
изменит порядок итерации этого хэша. Это поведение может быть отменено
используя hash_traversal_mask () из Hash :: Util или используя PERL_PERTURB_KEYS
переменную окружения, см. «PERL_PERTURB_KEYS» в perlrun. Обратите внимание, что эта функция
контролирует "видимый" порядок ключей, а не фактический порядок, в котором они хранятся
дюйм

Нарушение порядка ведра
Когда элементы сталкиваются в заданном хеш-ведре, порядок, в котором они хранятся в цепочке
больше не предсказуемо в Perl 5.18. Это имеет намерение усложнить задачу
наблюдать за столкновением. Это поведение можно изменить, используя
Переменная среды PERL_PERTURB_KEYS, см. «PERL_PERTURB_KEYS» в perlrun.

Новая функция хеширования по умолчанию
Хеш-функция по умолчанию была изменена с целью усложнить ее
чтобы вывести хэш-семя.

Альтернативные хеш-функции
Исходный код включает несколько алгоритмов хеширования на выбор. В то время как мы
полагаем, что хеш Perl по умолчанию устойчив к атакам, мы включили хеш
использовать Siphash как альтернативный вариант. На момент выпуска Perl 5.18.0
Считается, что сифаш обладает криптографической стойкостью. Это не по умолчанию, поскольку
он намного медленнее, чем хэш по умолчанию.

Без компиляции специального Perl невозможно добиться того же поведения, что и
любые версии до Perl 5.18.0. Самый близкий из них - это установить
PERL_PERTURB_KEYS в 0 и установка PERL_HASH_SEED на известное значение. Мы не
рекомендуйте эти настройки для производственного использования из-за вышеуказанных соображений безопасности.

Perl и никогда гарантированный любое заказ of хэш ключи, и заказ уже
несколько раз менялся за время существования Perl 5. Кроме того, порядок хеш-ключей
всегда влиял и продолжает зависеть от порядка размещения и истории
изменений, внесенных в хэш за время его существования.

Также обратите внимание, что хотя порядок элементов хеш-функции может быть случайным, этот "псевдо-
заказ "следует использоваться для таких приложений, как случайное перемешивание списка (используйте
"List :: Util :: shuffle ()" для этого, см. List :: Util, стандартный базовый модуль начиная с Perl.
5.8.0; или модуль CPAN «Алгоритм :: Числовые :: Перемешать»), или для генерации
перестановки (используйте, например, модули CPAN "Algorithm :: Permute" или
«Алгоритм :: FastPermute») или для любых криптографических приложений.

Связанные хэши могут иметь собственные атаки на упорядочение и алгоритмическую сложность.

· Регулярные выражения. Механизм регулярных выражений Perl называется NFA (Non-
детерминированный конечный автомат), что, среди прочего, означает, что он может скорее
легко потребляют большое количество времени и пространства, если регулярное выражение может
совпадают несколькими способами. Тщательная обработка регулярных выражений может помочь, но вполне
часто мало что можно сделать (книга "Освоение регулярных выражений"
обязательное чтение, см. perlfaq2). Perl проявляет нехватку места
заканчивается память.

· Сортировка - алгоритм быстрой сортировки, используемый в Perls до версии 5.8.0 для реализации Сортировать()
function очень легко обмануть и заставить работать некорректно, так что на это уходит много времени.
Начиная с Perl 5.8.0, по умолчанию используется другой алгоритм сортировки - mergesort.
Сортировка слиянием не может работать неправильно ни на одном входе.

Видетьhttp://www.cs.rice.edu/~scrosby/hash/> для получения дополнительной информации и любой информатики
учебник по алгоритмической сложности.

Используйте perlsec онлайн с помощью сервисов onworks.net