либо с использованием более легкого, чем CGI.pm модуля Котерова:
Необходимо четко следить, чтобы доступ к базе производился только приложением со всеми должными проверками и фильтрациями. Надо отфаерволлить базу от любых подключений, кроме локального (если база и приложение на одном сервере), либо кроме локального и только того, на котором находится приложение. Это избавит вас от необходимости проверять данные при чтении из базы (потому что они попали в нее гарантированно только от вашего приложения и проверены/профильтрованы им), кроме того, эффективнее проверять один раз при добавлении/изменении, а не каждый раз при чтении.
Доступ к приложению всем либо конкретным пользователям можно дать только с определённых IP или подсетей.
Можно устроить блокировку доступа к веб-приложению по выходным, в отпуске либо по определённым дням, в течении которых доступ к приложению совершенно точно никому не нужен. Если приложение полностью не доступно, то и сломать его не получится. Это лучше, чем оно могло бы быть поломано всегда. Правило применимо только к специфическим приложениям, которые крутятся, скажем, на предприятиях, работающих с понедельника по пятницу, а в выходные не работающих. Причём для исключения человеческого фактора (типа, забыли погасить сервер) можно назначить в кроне задание выключиться в пятницу вечером, а в BIOS Setup – включиться в понедельник утром. Ведь ни для кого не секрет, что лучше всего сервер защищён только выключенным состоянием :) Естественно, идея выключенного сервера годна лишь для такого сервера, где кроме защищаемого веб-приложения ничего не крутится (в первую очередь в голову приходит пример с официальным сайтом, который должен работать круглосуточно. Если у вас именно так, то укладывать веб-приложение вместе с сайтом нельзя и надо решать иначе, например временным пятничным выпиливанием VirtualHost приложения из конфига apache и его же понедельничным возвращением назад).
Кривые скрипты по соседству могут свести на нет все ваши старания. Например, форум стороннего производителя. Скажем, в нём нашли уязвимости, а вы обратили внимание о новости слишком поздно – это угроза. Либо галерея картинок, писаная начинающими ради уникальных фич, но без полноценного учёта безопасности – тоже яркий пример. Если ваш проект настолько крут и важен, что вы боитесь за него из-за соседей на shared-хостинге, просто возьмите себе VPS или даже DS. Тогда вас будет труднее положить, у вас будет больше производительности и не будет таких соседей, которых стоит бояться на shared-хостинге.
К младшему брату, языку PHP, существует интересный патч под названием suhosin http://www.hardened-php.net/suhosin/. Он добавляет к языку довольно мощные инструменты защиты скриптов. Прочитайте список возможностей http://www.hardened-php.net/suhosin/a_feature_list.html. Это превосходный источник идей, которые вы можете реализовать на Perl для защиты собственных проектов.
Существует опасность при появлении NULL-байта в строке, полученной от пользователя. Это символ, числовой код которого равен нулю. Сразу же приведу пример, где это очень наглядно видно:
Когда пользователь передал в программу на Perl строку, в середине которой имеется нулевой байт, вся строка попадает в переменную как есть. То есть всё, что идёт до нулевого байта, сам нулевой байт и всё, что после, будет сохранено в строке. Как только вы попытаетесь открыть файл с именем, хранящемся в такой переменной, нулевой байт будет означать конец строки, потому что Perl написан на языке C, а для языка C нулевой байт – это как раз символ окончания строки. Поэтому имя открываемого файла в конечном счёте будет воспринято внутренней сишной природой перла как строка до нулевого байта, остаток байт в перловой строке будет проигнорирован.
Представьте себе, что вы написали защиту, которая опирается на проверку строки от пользователя с помощью регулярного выражения. Вы хотите, чтобы это был исключительно текстовый файл. Вы сравниваете строку с выражением /\.txt$/ и считаете, что на этом задача решена. Однако пользователь может передать вам строку ”config.pl\x00.txt“. Такая строка пройдёт проверку, ведь у неё в конце по версии перлового представления строк есть фрагмент .txt, а какой файл откроется на самом деле, вы уже догадались? :)
Уязвимость чинится очень просто: как только вам передали имя файла, нулевой байт вырезается ($str =~ s/\0//g;) а лучше сразу фильтровать всё, кроме алфавитно-цифровых символов, точек, минусов, подчёркиваний, словом, всего того, из чего может состоять имя файла, который допустимо открыть.
-T
Не доверять пользователю. Если вы попытаетесь использовать данные от пользователя напрямую (Cookie, переменные окружения, параметры, переданные по CGI, ввод с клавиатуры и т.п.), Perl выдаст предупреждение о том, что такие данные требуется отфильтровать. Например, с помощью регулярного выражения выполняется извлечение, и только использование результата такого извлечения пройдёт без предупреждения.
-w
Показывать предупреждения о проблемах, которые не фатальны, с которыми скрипт работать будет, но обратить внимание на которые стоит как с точки зрения аккуратного программирования, так и с точки зрения безопасности. Одно из самых полезных предупреждений, на мой взгляд, использование переменной, которой ничего не присвоено, то есть то же, что и undef. Проверить неопределённость переменной можно так: defined($var). Когда вы добьетесь чистого выполнения скрипта без предупреждений с ключом -w в самых разных условиях, которые только сумеете придумать, вы как минимум теоретически усилите безопасность скрипта.
-W
То же, что и -w, только Perl покажет больше предупреждений, часть из которых совсем уж незначительна. Например, часто можно видеть, как при -W Perl ругается даже на собственные модули из коробки! Это, безусловно, отвлекает. С этим особо нечего поделать. Тут придётся либо на время наведения железного порядка у себя в скрипте смириться и игнорировать их, либо принять участие в улучшении чужого модуля – сообщество программистов будет вам признательно :) Только перед тем, как чинить чужое, убедитесь что у вас именно последняя версия модуля.
-X
Заткнуть Perl от любых предупреждений. Сообщения о фатальных ошибках при этом останутся. Этот ключ полезно использовать тогда, когда вы знаете о проблемах, отложили их починку, но хотите, чтобы в логах веб-сервера не было предупреждений. Не обязательно так делать, это всего лишь способ не засорять логии тем, о чём вы и так в курсе (представляете, что будет, если Warning выдаётся во фрагменте кода с большими циклами? Так что это ещё и экономия места на диске с логами, может быть важно для стартапов). Также это снизит нагрузку на диск при интенсивной ругани Perl-а предупреждениями.
Однако, это палка о двух концах. С одной стороны вы не видите известные проблемы (и это скорее хорошо, если исправить их запланировано), с другой – не видите и те, о которых не знаете. Это опять же касается стартапов, где может не быть лёгкой возможности подставить сервер с отлаживаемой версией под реальную нагрузку. Вам придётся принять решение, что для вас важнее: производительность с -X или возможность зафиксировать максимум предупреждений в логах на боевой машине и некоторое падение производительности с -w или даже -W.
Это уже не просто совет, это настоятельная рекомендация. Модуль очень полезный, он заставляет вас писать более строго.
Варианты:
• strict vars
Без этого вы используете переменную без объявления, считая, что Perl создаёт её автоматически. С этим вариантом вы должны объявить каждую переменную (массив, хеш… абсолютно всё).