Обратите внимание на готовые модули для чистки HTML:
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
к тому, что можно сделать без авторизации.
Лучше задать список разрешенных расширений файлов, чем задавать список запрещенных. Если какое-либо расширение будет забыто, пользователи пожалуются, что не смогли загрузить файл с таким расширением. Это гораздо лучше, чем некто сумеет загрузить нечто нехорошее (что-то, что вы забыли запретить).
Для архивов, скриптов, исполняемых, документов и других подобных файлов обязательна антивирусная проверка. Многие любят перекладывать это на плечи пользователя, скачивающего файлы. Почему бы не уменьшить проблему прямо при загрузке? Понимаю, что это не решает всех проблем, ведь можно написать новый вирус и положить его исключительно на атакуемый сервер (чтобы в антивирусные базы не сразу попал), но это не означает, что можно пренебрегать возможностью организовать автоматическое отсеивание известных вирусов.
Не плохо бы заодно проверять сигнатуры файлов. Если прислали с расширением jpg, то и по сигнатуре это должен быть строго JPEG, если zip то ZIP и ничто иное, иначе отказывать. Разумеется, это касается лишь тех форматов, у которых есть стандартная обязательная сигнатура. Вспомните, вам наверное хотя бы раз на форумах попадался какой-нибудь URL с комментарием вроде «скачайте и смените расширение на rar» скорее всего это обманутый сервер, сохранивший файл, не проверив сигнатуру. На UNIX-подобных системах для автоматической проверки есть утилита file, по нему есть manual. Если формат редкий, его придется проверить вручную. Описания форматов ищите на сайтах вроде Wotsit.orghttp://www.wotsit.org/ .
Ко временной папке, куда будут загружаться файлы перед обработкой или проверкой не должно быть доступа. Когда загрузка завершена, сделайте (если требуется) необходимые действия, преобразования и тому подобное, и только затем перемещайте в доступное извне место.
В папке, куда попадают загруженные файлы не должны быть включены SSI, PHP, Options ExecCGI, и прочее. Как вариант: отдавайте файлы не вживую, а через скрипт, это позволит вам собрать больше информации и создаст лучшие условия для принятия решений на лету.
При сохранении файла из его имени необходимо удалить все спецсимволы. Я (если не требуется иное) предпочитаю в имени делать следующее:
перегнать русский в транслит,
оставить латиницу и цифры,
остальное заменить знаками подчеркивания
и заменить подряд идущие подчеркивания на одно
Это можно сделать примерно так:
Во избежание злоупотребления возможностью загрузки файлов надо ввести квоты и назначить максимальный размер файла. Отказывайтесь обрабатывать запрос, если клиент умалчивает о размере данных (не передает поле CONTENT_LENGTH).
Не давайте закачивать или управлять файлами за пределами строго определенных директорий. Остерегайтесь приема полных путей и символов конвейера ( | ) и перенаправления ввода/вывода (<, <<, >, >>). Там, где можно обойтись без обращения к оболочке, потенциально безопаснее так и сделать.
Правило: трижды убедитесь в том, что глобальные переменные обнуляются перед использованием.
Информацию, которую вы не хотите отдавать на индексирование роботам-паукам, можно обозначить тегом noindex:
Всю страницу можно пометить как неиндексируемую, добавив в заголовок HTTP-ответа:
Аналог этого поля в HTML:
Еще один вариант не индексировать страницу средствами HTML:
Запретить роботам переходить по ссылкам на странице:
Используйте robots.txthttp://robotstxt.org.ru/ . Пустой robots.txt лучше, чем его отсутствие, так как роботы в любом случае его запрашивают. Ни к чему захламлять логи веб-сервера ложными ошибками 404. Это касается и файла favicon.icohttp://favicon.ru/faq/ . Если у вас его до сих пор нет, может пришла пора его создать? Пустой robots.txt равносилен заявлению «индексировать можно все».
Это модуль, который позволяет создавать правила проверки запросов до того, как они обработаются скриптами, и фильтрации ответов после отработки скриптов.
Например, можно раз и навсегда защититься от SQL-Injection в параметре с именем id, если вы будете придерживаться правила использовать его только для передачи числа, то есть создадите правило, что id в запросе должно быть числом и ничем иным. Можно также указать диапазон допустимых символов в запросе. Используя регулярные выражения можно добиться достаточно гибкой фильтрации. Модуль умеет произвольно реагировать на несоблюдение правил, его можно, к примеру, настроить так, чтобы злоумышленник после нескольких неудачных попыток сломать сайт банился бы по IP или ему показывалась заданная страница. Приятная особенность: mod_security умеет фильтровать и вести логи POST-запросов.