2002-10-30 18:45:49 UTC
Как известно, — безопасность никогда не бывает лишней. Здесь я хотел бы поделиться некоторыми соображениями о дырках, которые могут привести к неработоспособности вашего сайта, раскрытию конфедициальной информации(паролей например) и т.д. В основном эти соображения будут касаться работы с парсером, однако и при работе с другими технологиями они тоже остаются в силе.
Первое, и самое главное — никогда не храните конфидециальную информацию в пределах веб-пространства. Основные кандидаты на то, чтобы не храниться в пределах веб-пространства — это конфигурационный auto.p и файлы .htpasswd веб-сервера Apache, в которых хранятся пароли. Тут следует особо отметить что, обычно конфигурационный auto.p держат рядом с самим скриптом парсера parser3.cgi и даже если физически ваш каталог /cgi-bin/ (название может быть другое), т.е. тот откуда разрешен запуск CGI скриптов, расположен вне веб-пространства, все равно он в него отображается и следовательно при неправильном конфигурировании можно получить доступ из веб к файлам которые в нем хранятся. Короче не храните конфигурационный auto.p рядом с парсером.
Где же его хранить? Разумеется где угодно, но вне веб-пространства, однако учтите, что если вы его храните не рядом с парсером, будьте добры, в конфигурационном методе @conf[filespec], определяемом в этом файле, вместо filespec в качастве передаваемого параметра писать полный путь до конфигурационного auto.p в файловой системе вашего веб-сервера, типа так: @conf[/path/to/auto.p]. Кроме того в этом случае не забудьте установить переменную окружения CGI_PARSER_CONFIG с путём к auto.p что-то вроде того: SetEnv CGI_PARSER_CONFIG /path/to/auto.p. Эта переменная устанавливается в .htaccess и для этого необходимо наличие mod_env.
Чего же такого конфидециального в этом конфигурационном auto.p, что ему уделяется такое особое внимание? В нём удобно (и нужно) определять переменную(может быть несколько если необходимо работать с несколькими БД) содержащую строку подключения к вашей БД и соответственно в этой строке есть такие конфидециальные данные, как имя пользователя и пароль для подключения к БД. Далее эта строка может использоваться в операторе ^connect вызов которого, может находится и в файлах находящихся в веб-пространстве и в этом случае даже если злоумышленнику удастся получить текст этого файла, он все равно не узнает ваши данные для доступа к БД.
Далее стоит не забывать про установку запрета на доступ к файлам с расширением .p из интернета:
<Files ~ "\.p$"> Order allow,deny Deny from all </Files>
И из этой же оперы — стоит запретить листинг каталога(если это ещё не сделано), если там нет файла по-умолчанию: Options -Indexes.
Если хочется совсем уж обезопасить себя от доступа к исходникам сайта из веб, можно сделать на весь сайт одну страницу, к которой направлять все запросы, а весь код реализовывать в классах, которые могут находиться и вне веб-пространства, парсер ведь может читать файлы и не находящиеся в веб-пространстве. Кстати у меня так и сделано.
Идем дальше. На этот раз про отправку данных через формы. Не стоит думать, что данные в скрытых(да и не только) полях форм не будет никто менять. Некоторой защитой от этого может служить проверка переменной окружения HTTP_REFERER которая содержит адрес страницы, с которой производилась отправка данных из формы. Если эта страница не принадлежит нашему сайту, — не принимать данные с неё. Здесь же, — если вы из какого-либо поля формы ожидаете получить число, стоит делать явные преобразования значений т.е. вместо $form:number_field писать что-то типа ^form:number_field.int(0) или ^form:number_field.double(0). Если так не делать то, цитата из доки по 2-му парсеру: ...любой подрастающий хакер сотрет все ваши данные раньше, чем вы успеете нажать на Reset.
Такие вот простенькие соображения. Если у вас есть возражения и дополнения, пишите мылом.