Защищенность секретных файлов
Настройки скрипта, пароли и другая секретная информация, как правило, хранится не в теле программы (хотя случается и такое), а в отдельных файлах, зачастую помещенных в тот же самый каталог, в котором расположены скрипты или web-страницы. Это значит, что их содержимое можно просмотреть в экране браузера, - стоит только узнать требуемое имя и сформировать соответствующий URI.
Единственная проблема, стоящая перед злоумышленником, - узнать полный путь к этим файлам. Если просмотр www-директорий сервера запрещен (что вовсе не факт!), остается действовать последовательным перебором. При условии, что файлы имеют осмысленные имена (как часто и бывает) перебор не будет слишком долгим. К тому же, используя общедоступные скрипты, не все web – мастера изменяют имена секретных и конфигурационных файлов. Наконец, получить содержимое директорий можно и через ошибки реализации других сетевых служб и самого сервера.
Словом, никогда не стоит надеяться, что злоумышленник не сможет выкрасть секретный файл только потому, что не знает его имени. Гораздо надежнее разместить его так, чтобы web-клиенты не имели к нему никакого доступа (скрипту, исполняющемуся с привилегиями локального пользователя, это не причинит никаких проблем, и он по-прежнему сможет читать и писать в такой файл). Другое возможное решение – сконфигурировать web-сервер так, чтобы он не видел эти файлы или запрещал к ним доступ.
Оба способа требуют для своей реализации определенных привилегий, которые предоставляются не всеми провайдерами (и очень немногими службами бесплатного хостига), – тогда приходится помещать секретную информацию в сам Perl-скрипт. При отсутствии ошибок реализации и конфигурации WEB-сервера клиент никогда не увидит содержимое скрипта, а только результат его работы. Напротив, сам скрипт может работать с самим собой как с обычным текстовым файлом. Для этой цели удобно использовать лексему DATA, доступную через одноименный дескриптор.
Такой прием обеспечивает достаточно высокую защищенность секретных данных, но срабатывает не всегда, – случается, что сервер в силу определенных обстоятельств отображает не результат работы, а содержимое скрипта. Забавно, что для исправления такой ошибки разработчикам Microsoft Internet Information Server пришлось выпустить три (!) следующих одна за другой заплатки, прежде чем проблема была решена.
Сперва обнаружилось, что точка, добавленная к имени скрипта, вместо запуска приводила к отображению его содержимого. Это быстро исправили, впопыхах не вспомнив, что ту же самую точку можно представить и в виде шестнадцатеричного кода, предваренного символом процента. Пришлось вслед за первым выпускать второй пакет, а за ним еще и третий, поскольку выяснилось, что обращение к файлу по альтернативному короткому имени так же приводит к показу его содержимого. И до сих пор ни у кого нет полной уверенности, что выловлены все ошибки и завтра не откроется какая-нибудь новая.
Всегда следует учитывать угрозу просмотра секретного файла и противостоять ей. Это вовсе не так трудно, как может показаться!
Основным объектом охоты злоумышленников обычно становятся пароли, а их легко зашифровать встроенной в Perl функцией crypt. Строго говоря, crypt
пароли не шифрует, а хеширует, подвергая их необратимому преобразованию, поэтому, даже получив доступ к секретному файлу, злоумышленник не сможет восстановить ни один пароль иначе, чем тупым перебором всех возможных вариантов.
Упрощенный пример программы аутентификации с использованием функции crypt приведен ниже (в нем не используются привязка - salt, поэтому, одинаковые пароли будет иметь идентичные хеши, что в сотни раз ослабляет стойкость защиты ко взлому лобовым перебором).
Внимание: в некоторых реализациях Perl функция crypt возвращает переданную ей строку без каких бы то ни было изменений. Проверьте, как ведет себя ваша версия Perl! В крайнем случае придется создавать собственную реализацию Perl (в этом помогут исходные тесты UNIX-подобных операционных систем).
print "Password:"; #запрос пароля пользователя
$passwd=<>;
chop $passwd; #удаление символа \n
$encrypt=crypt($paswsd,"sl"); #вычисления хеша пароля
open (fh,"passwd") || die; #открытие файла паролей
while($pass=<fh>){ #поиск подходящего пароля
chop $pass; #удаление символа \n
if ($pass eq $encrypt){ #подходящий пароль?
print "Password ok\n";
$flag=1; #пароль найден, установить флаг
break; #и выйти из цикла
}
}
if (!$flag) # если пароль не найден - выход
{print "BAD password!\n"; die;}
Использование необратимого шифрования даже при наличии других ошибок реализации и неправильном администрировании сервера чрезвычайно затрудняет атаку, делая ее практически неосуществимой. Во всяком случае, взломщику понадобится весьма сильная мотивация, чтобы тратить свое время на такую защиту. Хакеры, как и угонщики, редко охотятся за какой-то одной, конкретно выбранной машиной, - они скорее найдут растяпу, забывшего ключи в замке зажигания, чем будут ювелирно нейтрализовать сложную систему сигнализации.
