?

Log in

No account? Create an account
Записи Лента друзей Календарь Инфо Записки на крышке ноутбука Назад Назад Вперед Вперед
Дом приходящего солнца
Олежкины записи
olejka
olejka
PHP: Советы по безопасности для параноиков
Долго рылся, но не смог найти внятную информацию по безопасности PHP, собранную в одном большом документе. А раз так, решил собрать все, что у меня есть, и кинуть клич - КТО МОЖЕТ ЧТО ЕЩЕ ПОСОВЕТОВАТЬ?

Никогда не доверяйте входящим данным из внешнего источника

  • Ни один внешний источник не является 100% надежным по определению. Абсолютно все данные должны быть проверены на легальность а также отформатированы в соответствии с ожидаемым типом.
  • Старайтесь избегать upload-ов! Если же согласно вашему проекту, файлы должны заливаться на сервер, максимально изолируйте место "залива" - никакого чтения оттуда, и уж тем более никакого запуска на исполнение (аттрибуты спасут только в Linux-е).
  • Никаких cookie!!! В конце концов, они же могут быть просто тупо отключены.


Не используйте сторонние большие пакеты

  • Надежность любой системы обратно пропорциональна ее сложности. Зачем тянуть за собой огромные хвосты неизвестно чего делающего кода ради одной-единственной фичи?
  • Чем популярнее пакет, тем более он изучен хакерами. А пакетов без дырок не бывает по определению. Пример - пакет phpCOIN, во всех версиях имеющая дырку в виде возможности подключения внешнего инклюда (http://[target]/[path]/config.php?_CCFG[_PKG_PATH_DBSE]=http://[location]). И ведь ее проглядели даже разрабочтики, а вы бы сами ее нашли?
  • Нужно пройтись по коду и выкосить все неиспользуемое и просто подозрительное, и регулярно следить за патчами для использованных библиотек. Короче говоря, поддержка чужого кода, что суть трата времени и сил. Оно вам надо?


Безопасность файлов данных
Сильное средство php - работа напрямую с внешними файлами, но оно же является и самой серьезной потенциальной дыркой.

  • Ни один из файлов, открываемых в вашем коде, не должен находится в каталоге, открытом для веб-сервера! Если есть необходимость в такой операции, значит вы выбрали неудачный метод решения вашей задачи.
  • Если имя файла используется в качестве параметра, он может быть только внутренним! Если хотя бы где-то он торчит наружу - это огромная распахнутая дверь для хакеров. Но даже внутренние параметры неплохо проверять в соответствующих функциях.
  • Использование абсолютных путей в именах файлов должно быть запрещено! Выделите изолированный каталог для своих файлов данных.
  • Очищайте имена файлов от любых служебных символов или скрытых команд (например, трюк с "..\" может вывезти наружу из любого каталога windows).
  • Помните, что стандартные файловые операции fopen в php понимают веб-префиксы http, ftp, и т.д. А это означает, что любая операция ввода-вывода потенциально может быть перенаправлена абсолютно куда угодно! Чтобы закрыть эту дыру, в файле .htaccess в корне сайта допишите php_value allow_url_fopen 0 либо запретите URL fopen wrapper для всех клиентов при помощи директивы php_admin_value
  • Символы возврата каретки CR/LF ("\r\n") позволяют не только подставить url вместо имени файла, но и составить полноценный HTTP-запрос. Например, можно использовать для рассылки спама через почтовый сервер:

    GET / HTTP/1.0
    HELO mailserver.com
    MAIL FROM:
    RCPT TO:
    DATA
    Get a spam!
    .
    QUIT



Обработка ошибок
Помните, что по умолчанию все ошибки php выдает в браузер, причем вместе с технической информацией - полным путем к модулю и номером строки. Как только такая информация попадает в руки хакеру, он получает бесценную информацию: расположение ваших модулей на php и факт наличия php вообще. А также, что где-то есть "сопля", через которую можно попытаться влезть своим кодом.

  • Не забывайте, что по окончании отладки и запуски продуктивного приложения, отображение ошибок должно быть выключено! (Директива display_errors в php.ini)
  • Если ошибки возникнут, отловить их можно будет по логам. Для этого использовать директиву log_errors в php.ini. Уровень детализации лога настраивается директивой error_reporting.
  • Идеально, если ваш код будет отлавливать ошибки сам, и сам решать, как ему поступить (просто записать в лог, сбросить сессию, сохранить или наоборот уничтожить данные, и т.д.). Для этого напишите свою собственную функцию, которую нужно будет зарегистрировать как обработчик ошибок используя функцию set_error_handler().


Обращения к операционной системе

  • Здесь правилоо простое - ИХ НЕ ДОЛЖНО БЫТЬ! Неужели никак нельзя обойтись без system(), exec(), passthru() или popen()?? Подумайте, посмотрите на ваш проект еще раз..
  • Любая команда, если она не прописана жестко, а передается в виде параметра - дыра в безопасности. И никакие стандартные escapeshellarg() или escapeshellcmd() не могут полностью избавить вас от всех возможных трюков, призванных заставить систему выполнить что-то совсем отличное от того, что хотели вы.


Кто что еще посоветует?

Tags:

3 комментариев или Написать комментарий
Comments
bananan From: bananan Date: April 18th, 2007 08:20 am (UTC) (Ссылка)
Oleg, prichem tut php?

Pochti vse - eto obschie sovety dlya programmirovaniya web, primenimye sobstvenno k lubomu yazyku. Za redkim isklucheniem.

Obrabotka oshibok i vhodnyh parametrov - eto, prostite, azbuka.

Nekotorye sovety: izbeganie uploadov i cookie - bolshe pohozhi na isteriku.

Konechno, lameram luchse ne ispolzovat veschi, esli oni ne znaut kak oni rabotaut. Eto sobstvenno mojno prochest mejdu strok v kajdom takom sovete.

olejka From: olejka Date: April 18th, 2007 12:49 pm (UTC) (Ссылка)
Потому что анализ был в применении к php, и решений этих проблем в рамках php (если таковые есть). Естественно, вещи азбучные и общие тоже есть - хотелось собрать побольше. Но, видимо, больше не захочется.
bananan From: bananan Date: April 18th, 2007 04:03 pm (UTC) (Ссылка)
"Но, видимо, больше не захочется."

Так не нравится язык? Или ты принял фразу про ламеров на свой счет? :)

Извини, если у тебя создалось такое впечатление.
3 комментариев или Написать комментарий