Защита веб-приложений

HTTML::Scrubberhttp://search.cpan.org/~podmaster/HTML-Scrubber-0.08/Scrubber.pm

HTML::Detoxifierhttp://search.cpan.org/~pwalton/HTML-Detoxifier-0.02/lib/HTML/Detoxifier.pm

HTML::TagFilterhttp://search.cpan.org/~wross/HTML-TagFilter-1.03/TagFilter.pm

14.

Не провоцируйте взломщика к дальнейшим действиям – не говорите, в какой строке и в каком файле произошла ошибка. Не цитируйте сообщений интерпретатора, не показывайте SQL-запросы. Используйте mod_rewrite http://httpd.apache.org/docs/2.0/rewrite/, это не только красивые URL'ы, это дополнительное сокрытие деталей реализации. Лучше тихо сложите подробности ситуации в лог, потом сами посмотрите, а пользователя не стоит грузить непонятными дампами. Скажите ему, что произошла ошибка, чтобы он проверил вводимые данные, попробовал перезалогиниться, пусть он, наконец, обратится в суппорт.

15.

Не доверяйте никому: неавторизованному проходящему мимо серферу, пользователю и даже администратору. Почему? Любая функция, даже редко используемая или которая только для администратора должна быть крепко защищена не хуже других. Представьте, админ тоже человек, он может забыть разлогиниться, или он может просто оказаться недобросовестным и сам попытаться искать какой-нибудь SQL-Injection в админке, рассчитывая на то, что, ну, уж админу-то вроде доверять должны…

16.

В ряде случаев вам не удастся полноценно восстановить картину действий пользователей по логам Apache. Ведите собственный журнал безопасности. Разумеется, для экономии хранить в нём следует лишь критические действия пользователей, такие как регистрация, вход/выход, смена пароля, неудачные попытки входа, поведение, похожее на перебор паролей или поиск уязвимостей, IP-адреса (и Proxy, если есть), User-Agent'ы, дату/время и тому подобное. Это позволит намного удобнее анализировать действия и реагировать на инциденты эффективнее.

17.

Дырка снаружи на порядок хуже, чем та, которой может воспользоваться только авторизованный пользователь. Авторизованных всегда меньше, и они просто по определению должны в подавляющем большинстве быть заинтересованы в том, чтобы не навредить. А вот несвязанных с системой злонамеренных людей может быть больше. Им наплевать, что своими действиями они могут уронить сервер, уничтожить чужой труд. Обращайте повышенное внимание к тому, что можно сделать без авторизации.

18.

Если вы считаете, что ЭТОГО никто никогда не сделает или не додумается, и не станете полноценно от ЭТОГО защищаться, знайте: рано или поздно найдется такой маньяк, который обязательно сделает именно ЭТО. Либо сложатся обстоятельства, которые вы не обрабатываете, так как считаете маловероятными.

19.

Загрузка файлов на сервер.

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

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

Не плохо бы заодно проверять сигнатуры файлов. Если прислали с расширением jpg, то и по сигнатуре это должен быть строго JPEG, если zip – то ZIP и ничто иное, иначе отказывать. Разумеется, это касается лишь тех форматов, у которых есть стандартная обязательная сигнатура. Вспомните, вам наверное хотя бы раз на форумах попадался какой-нибудь URL с комментарием вроде «скачайте и смените расширение на rar» – скорее всего это обманутый сервер, сохранивший файл, не проверив сигнатуру. На UNIX-подобных системах для автоматической проверки есть утилита file, по нему есть manual. Если формат редкий, его придется проверить вручную. Описания форматов ищите на сайтах вроде Wotsit.org http://www.wotsit.org/.

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

В папке, куда попадают загруженные файлы не должны быть включены SSI, PHP, Options ExecCGI, и прочее. Как вариант: отдавайте файлы не вживую, а через скрипт, это позволит вам собрать больше информации и создаст лучшие условия для принятия решений на лету.