Проверенные способы защиты PHP. PHP уязвимость и защита от PHP инъекций

Получает внешний фид и разбирает его на данные (парсит его).

Функция нужна, чтобы получить RSS фид в виде SimplePie объекта и закэшировать результат.

Для получения и парсинга фида fetch_feed() использует популярный класс SimplePie . Фид кэшируется и кэш в последствии обновляется каждые 12 часов.

Данные кэшируются в базу данных во временные опции . Если установлен плагин постоянного объектного кэширования, то функция будет кэшировать не в БД, а в хранилище для объектного кэша.

Возвращает

SimplePie/WP_Error. SimplePie объект данных о фиде или объект WP_Error в случае ошибки.

Использование

$feed = fetch_feed($uri); $uri(строка) (обязательный) Ссылка (УРЛ) на фид который нужно получить. В результате по этой ссылке будет получен создан объект (массив) SimplePie.
По умолчанию: нет

Примеры

#1. Получим последние 5 записей из фида у внешнего сайта

Пример, который получает и выводит на экран ссылки на существующий RSS фид. В примере мы ограничиваем вывод только 5-ю последними записями в фиде.

Поcледние новости с блога blog.ru

get_item_quantity(5); // Создаем массив всех записей фида, начиная с первой записи (0 - начало) $rss_items = $rss->get_items(0, $maxitems); } ?>

Нет записей."; } else { // Пробегаемся по массиву и выводим ссылку на каждую запись foreach ($rss_items as $item) { ?>
• get_permalink()); ?>" title="get_date("j F Y | g:i a"); ?>" > get_title()); ?>

#2 Еще один приме: получим 5 записей фида стороннего сайта

Прочитаем фид http://mysite.ru/feed/ и получим из него первые 5 записей.

Include_once(ABSPATH . WPINC . "/feed.php"); $rss = fetch_feed("http://mysite.ru/feed/"); $rss_items = $rss->get_items(0, $rss->get_item_quantity(5)); if (! $rss_items) { echo "no items"; } else { foreach ($rss_items as $item) { echo "

get_permalink() . "">" . $item->get_title() . "

"; } }

Управление временем жизни кэша фидов

Результат получения фида кэшируется на 12 часов. Чтобы изменить время кэша для функции fetch_feed() , нужно использовать хук wp_feed_cache_transient_lifetime .

Add_filter("wp_feed_cache_transient_lifetime", "speed_up_feed", 10, 2); function speed_up_feed($interval, $url) { if("http://mysite.ru/feed/" == $url) return 3600; // 1 час return $interval; }

Отключение кэширования на время разработки

По ходу манипуляций с фидом, необходимо отключить кэширования, а то оно будет сильно мешать. Сделать это можно через хук wp_feed_options

## отключаем кэширование фидов. Только если включен режим разработки WP_DEBUG if(defined("WP_DEBUG") && WP_DEBUG){ add_action("wp_feed_options", function(&$feed){ $feed->enable_cache(false); }); }

ВАЖНО! Обязательно отключите этот код на рабочем сайте. Потому что он может увеличить скорость загрузки страниц сайта в разы!

Кэширование фидов не работает с включенной константой WP_DEBUG

Имейте ввиду, что если включена константа WP_DEBUG , то фид не кэшируется. Срабатывает такой код ядра:

Function do_not_cache_feeds(&$feed) { $feed->enable_cache(false); } if (defined("WP_DEBUG") && WP_DEBUG) add_action("wp_feed_options", "do_not_cache_feeds");

Кэширование в браузере

Также обратите внимание, что кэширование может происходить в браузере, чтобы его обойти обновляйте страницу через ctrl + F5. Или можно добавить такой хук:

## отключим кэширование в барузере для запросов фидов add_filter("wp_headers", function($headers){ if(!empty($GLOBALS["wp"]->query_vars["feed"])){ unset($headers["ETag"], $headers["Last-Modified"]); } return $headers; });

Очистка кэша всех фидов в WordPress

Для запуска кода, нужно добавить в URL параметр?clear_feeds_cache .

## Очистка кэша всех фидов в WordPress if(isset($_GET["clear_feeds_cache"])){ global $wpdb; $cleared = $wpdb->query("DELETE FROM $wpdb->options WHERE option_name LIKE "\_transient%\_feed\_%""); die(var_dump(!!$cleared)); }

Заметка: если на сайте включено объектное кэширование, то этот код не сработает...

Заметки

Список изменений

С версии 2.8.0

Введена.

Код fetch feed : wp-includes/feed.php WP 5.3.2

set_sanitize_class("WP_SimplePie_Sanitize_KSES"); // We must manually overwrite $feed->sanitize because SimplePie"s // constructor sets it before we have a chance to set the sanitization class $feed->sanitize = new WP_SimplePie_Sanitize_KSES(); $feed->set_cache_class("WP_Feed_Cache"); $feed->set_file_class("WP_SimplePie_File"); $feed->set_feed_url($url); /** This filter is documented in wp-includes/class-wp-feed-cache-transient.php */ $feed->set_cache_duration(apply_filters("wp_feed_cache_transient_lifetime", 12 * HOUR_IN_SECONDS, $url)); /** * Fires just before processing the SimplePie feed object. * * @since 3.0.0 * * @param object $feed SimplePie feed object (passed by reference). * @param mixed $url URL of feed to retrieve. If an array of URLs, the feeds are merged. */ do_action_ref_array("wp_feed_options", array(&$feed, $url)); $feed->init(); $feed->set_output_encoding(get_option("blog_charset")); if ($feed->error()) { return new WP_Error("simplepie-error", $feed->error()); } return $feed; }

Все мы, так или иначе, хотели бы быть уверенны в том, что наш сайт или блог никто не сможет взломать. Но увы, реальность такова, что любая система уязвима, как бы сильна она не была бы защищена. Все упирается лишь в ресурсы и в упорство взломщика… Хм… Что то меня не туда потянуло… Будем считать это предисловием =)

Не так давно я писал о том как . Но допустим вы взяли уже готовую CMS и не знаете, как там реализованна загрузка, да и вобще вся защита. Конечно, особо пытливые и грамотные разработчики изучат код этой цмс прежде чем поставят на свой сайт. Но что делать тем у кого нет столько времени?

Хорошо, или допустим вы из тех кто считает что безопасность и правильная настройка сервера лишней не бывает? Если так то добро пожаловать под кат.

Нет, в статье вы не найдете какой-то супер пупер плагин, фильтрующий все данные, который нужно приинклудить ко всем файлам. Моя идея заключается в использовании директивы auto_prepend_file и постройки списка разрешенных файлов… Но в общем читайте сами…

Данная идея у меня давно сидела в голове, но наконец у меня дошли руки, хоть ничего сложного тут и нету, и я смог эту систему реализовать и написать статью =)

Принцип работы

Как я уже говорил выше, система основанна на работе директивы auto_prepend_file в php.ini . Отвечает она за установку скрипта, который будет выполнятся ПЕРЕД выполнением основного.

К примеру вы открыли index.php, а перед его выполнением запускается файл, указанный в auto_prepend_file . Суть в том, что в этом скрипте мы сможем контролировать дальнейшую работу остальных скриптов. Грубо говоря, продолжить работу и запустить запрошенный скрипт, или завершиться сразу (die() ).

К примеру ситуация — злоумышленник залил на ваш сайт шелл через какую нибудь уязвимость и пытается его открыть в браузере. А вместо его шелла, ему, без всяких на то причин, отдается, вот такая вот ошибка:

Меня бы подобное ввело бы в ступор…

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

(Не знаю нужна ли эта диаграмма, вроде бы и так все должно быть понятно…)

Конечно составлять такой список вручную — дело не благородное, поэтому я пришел к выводу, что имеет смысл реализовать так называемый «режим обучения». Режим в котором все обращения ко всем скриптам будут заносится в список разрешенных файлов автоматически.

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

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

Что умеем

Так как это концепт, то и умеем мы не много.

• Блокирование неразрешенных скриптов (собственно основная функция). Но опять же это настраиваемо, можно не блокировать соединение, а только лишь уведомлять админа по email
• Уведомление о нелегитимных запросах администратору по email (краткий отчет или полный отчет, последний включает заголовки пакета и данные POST запроса если таковые имеются)
• Можно указать IP администратора, который будет иметь доступ к любым скриптам, т.е. данная система его затрагивать не будет (эти IP не будут участвовать в режиме обучения). К примеру теперь не надо закрывать .htaccess -ом софтины типа PhpMyAdmin, SupexDumper и прочие системные утилиты.
• Ксати Ip адреса поддерживают простенькие маски=)
• Полностью прокомментированный код, и подробно описанна каждая директива конфигурации
• Хз что еще…

Настройка

Теперь о том как встроить эту защиту в ваш сайт…

Для этого вам необходим доступ к файлу php.ini

1. Для начала скачиваем сам скрипт: PrependSecuritySystem
2. Распаковываем содержимое архива (data.txt и main.php) в какую либо папку на сервере, желательно в папку не доступную из веба (не обязательно, т.к. работать будет в любой, это имеет смысл чтобы убрать скрипт подальше от глаз взломщика)
3. Открываем файл main.php и редактируем настройки. Необходимо обязательно поменять ip адрес и email админа. Остальные настройки же — по вашему желанию.
4. Устанавливаем права доступа к распакованным файлам. Под никсами желательно изменить владельца для обоих файлов, отличного от пользователя из под которого работает веб сервер. Для файла main.php необходимо запретить запись для всех. Для файла data.txt необходимо установить права на чтение и на запись для всех (это временно, на период обучения)
5. Открываем php.ini и вписываем следующее:
   auto_prepend_file=[путь до распакованного файла main.php]
6. С данного момента начинается обучение системы. Выжидаем определенное колличество времени, достаточное, по вашему мнению, для полного обучения данной системы.
7. По окончанию обучения открываем файл main.php и редактируем костанту PSS_STATUS_BLOCK , устанавливаем ее значение в true , сохраняем
8. Изменяем права доступа на файл data.txt. Запрещаем редактирование данного файла для всех.
9. Теперь система перешла в режим блокирования неразрешенных скриптов

Многовато шагов, конечно, но с этим, как мне кажется, справится даже ребенок.

Если вам необходимо переобучить систему (с нуля или дополнить), то вам необходимо:

1. Разрешить запись в файл data.txt
2. Очистить содержимое data.txt (ТОЛЬКО если вам необходимо переобучить систему с нуля)
3. Отредактировать костанту PSS_STATUS_BLOCK в файле main.php , установив ее значение в false
4. Проводим переобучение…
5. По окончанию переобучения редактируем константу PSS_STATUS_BLOCK устанавливая ее значение обратно в true
6. Запрещаем запись файла data.txt

Ну а теперь о грустном

Лукавить я не буду, и теперь расскажу о недостатках.

• Пожалуй главный недостаток по сравнению с которым меркнут все остальные, это то, что эту систему можно обойти. Вы спросите: как же так? Все очень просто, директиву auto_prepend_file можно указать и в .htaccess . И если подойти трезво то если злоумышленник вдруг смог залить шелл, то наверняка он сможет залить и свой .htaccess в котором он может отключить оригинальную директиву.
  Это работает только под apache , но к примеру под nginx этот трюк не выйдет (у nginx нет файлов.htaccess). НО! Под Nginx можно вообще залить .
• Злоумышленник может отредактировать «разрешенный» скрипт если есть допустимые права на это, и с этим наша система ничего, к сожалению, сделать не сможет. Разве что необходимо устанавливать правильные права на все исполнемые файлы
• Помимо PHP есть еще всякие perl, cgi и прочее… с ними данная система не работает.
• Дополнительная нагрузка. Но вртяли эта нагрузка будет ощутима.

Именно поэтому, казалось бы такая оригинальная система, не может называться идеальной. Но она вполне подойдет в качестве простой превентивной меры, которая остановит не самых упоротых упертых взломщиков. По крайней мере данная система сможет отнять время у взломщика на проведение атаки. К примеру, система уведомит администратора о попытке взлома, дав тем самым администратору возможность устранить уязвимость до тех пор пока злоумышленник разберется с причиной его неудач.

Заключение

Все же, так или иначе, это концепт, может быть вы сможете придумать на ее основе что то лучшее. А может быть вас устроит моя система.

На мой взгляд разумной защиты много не бывает. Использовать что-либо подобное или нет, у вас на сайтах решать вам.

Фуф. Ну и написал я, почти целый день ушел. Простите если описал несколько сумбурно. В общем задавайте ваши вопросы в комментариях, я постараюсь ответить.

PS: хоть я и кодил максимально адекватно, скрипт может иметь баги. Тестировалось на win/apache/php 5.2 — все было ок.

Одним из наиболее значимых вопросов для web-программистов является безопасность php-скриптов. Все программисты в той или иной мере используют различные методы чтобы обезопасить свой проект, но, к сожалению, в большинстве случаев используется защита от нескольких уязвимостей, при этом остальные проблемные места даже не рассматриваются.
В данной статье перечислены основные виды уязвимостей PHP и рассмотрены способы защиты от них.

Виды уязвимостей PHP

1. Демонстрация ошибок пользователю
   Смысл: при каких-либо ошибках в коде пользователю выводиться информация об произошедшей ошибке. Не является критичной уязвимостью, но поваляет взломщику получить дополнительную информацию о структуре и работе сервера.
2. Доступность данных о характеристиках системы пользователю
   Смысл: пользователь может получить доступ к данным, дающим представление о системе. Не является критичной уязвимостью, но поваляет взломщику получить дополнительную информацию о структуре и работе сервера. Причина этой уязвимости в ошибках и «недосмотрах» программиста. Примером может служить наличие файла phpinfo.php с одноимённой функцией в свободном доступе.
3. Доступность данных о программном коде пользователю
   Смысл: пользователь может получить доступ к программным кодам модулей, имеющих расширение, отличное от php . Является критичной уязвимостью, так как позваляет взломщику получить достаточно полную информацию о структуре и работе сервера, выявить его уязвимости.
4. Простые пароли для доступа к административным страницам
   Смысл: взломщик может подобрать простой пароль к административной странице, дающей ему больше возможностей для взлома. Является критичной уязвимостью, так как позваляет взломщику повлиять на работу сервера.
5. Возможность задания глобальных переменных
   Смысл: при неправильных настройках PHP имеется возможность задавать глобальные переменные скрипта, через строку запроса. Является критичной уязвимостью, так как взломщик может влиять на ход работы скрипта в свою пользу.
6. PHP-инъекция
   Смысл: в параметр, определяющий работу PHP с файлами или программным кодом, передаётся ссылка на сторонний программный код или сам код. Является критичной уязвимостью, так как взломщик может выполнять свои скрипты на сервере. Выполнение кода осуществляется при помощи функций: eval(), preg_replace(), require_once(), include_once(), include(), require(), create_function(), readfile(), dir(), fopen() .
7. PHP-инъекция через загрузку файлов
   Смысл: при возможности задании глобальных переменных в параметр, определяющий загружаемый на сервер файл, передаётся ссылка на сторонний программный код или конфиденциальный файл на сервере. Является критичной уязвимостью, так как взломщик может выполнять свои скрипты на сервере или получить доступ к конфиденциальным данным. Данная уязвимость возможна только при возможности задания глобальных переменных и неверной организации механизма загрузки файлов.
8. e-mail-инъекция
   Смысл: в параметр, определяющий работу PHP с электронными письмами, передаётся ссылка на сторонний программный код или сам код. Является критичной уязвимостью, так как взломщик может выполнять свои скрипты на сервере или получить доступ к данным, хранимым у пользователя.
9. SQL-инъекция
   Смысл: в параметр, определяющий SQL-запрос, передаётся данные, образующее запрос для доступа к закрытым данным. Является критичной уязвимостью, так как взломщик может получить конфиденциальные данные, хранимые в базе данных. Для изменения запроса взломщик может использовать следующие конструкции: SELECT, UNION, UPDATE, INSERT, OR, AND .
10. Межсайтовый скриптинг или XSS
    Смысл: в параметр, определяющий выводимые пользователю данные, передаётся сторонний программный код. Является критичной уязвимостью, так как взломщик может получить конфиденциальные данные, хранимые в браузере клиента. Для изменения запроса взломщик использует html-теги.

Правила написания безопасного кода на PHP

1. Блокирование вывода ошибок
   Для этого достаточно в программном коде задать error_reporting(0) или в файле.htaccess добавить строку php_flag error_reporting 0
2. Использование сложных паролей для доступа к административным страницам
   Для этого достаточно использовать многозначные пароли, не имеющие семантического значения (например, К7O0iV98dq).
3. Логирование критических действий пользователя
   Не обеспечивает защиту напрямую, но позволяет выявить взломщиков и определить уязвимости, которые они использовали. Для этого действия пользователя и переданные им данные, которые касаются критических моментов работы системы, достаточно записывать в обычный текстовый файл.
   Пример функции логирования и её работы:
   function writelog($typelog, $log_text) {
   $log = fopen("logs/".$typelog.".txt","a+");
   fwrite($log, "$log_text\r\n");
   fclose($log);
   }
   writelog("authorization", date("y.m.d H:m:s")."\t".$_SERVER["REMOTE_ADDR"]."\tУспешный вход");
4. Закрытие доступа к модулям сайта
   Обеспечивает защиту от попыток просмотра их содержимого или выполнения. Для этого достаточно в файле.htaccess настроить доступ к файлам модулей при помощи конструкций FilesMatch и Files .
   Например, мы закрываем доступ ко всем модулям с расширением php , кроме файла capcha.php :
5. Отключение возможности задания глобальных переменных
   Для этого достаточно в настройках сервера задать register_globals = off; или в файле.htaccess добавить строку php_flag register_globals off . Использование ini_set("register_globals",0); проблему не решит так, как переменные задаются до начала выполнения скрипта.
6. Отключение возможности использования удаленных файлов
   Для этого достаточно в настройках сервера задать allow_url_fopen = off; . Это обеспечивает частичную защиту от PHP-инъекций, но не полную, так как взломщик может передавать не ссылку на файл с программным кодом, а сам программный код. Для полной защиты от PHP-инъекций необходимо дополнительно использовать фильтрацию поступивших данных. Иногда данную меру защиты невозможно использовать из-за особенностей работы проекта (нужно обращаться к удалённым файлам).
7. Фильтрация поступающих данных
   Обеспечивает защиту от большенства уязвимостей. Универсального решения не существует. Желательно использовать проверку по «белому» списку символов в совокупности с проверкой на запрещённые слова. «Белым» называется список разрешенных символов. В этот список не должны входить опасные символы, например, . К запрещённым словам можно отнести: script, http, SELECT, UNION, UPDATE, exe, exec, INSERT, tmp , а также html-теги.
   Пример фильтрации поступающих данных:
   // Проверка по белому списку. Допускаются только русские и латинские буквы, цифры и знаки _-
   if (preg_match("/[^(\w)|(А-Яа-я-)|(\s)]/",$text)) {
   $text = "";
   }
   // Фильтрация опасных слов
   if (preg_match("/script|http|||SELECT|UNION|UPDATE|exe|exec|INSERT|tmp/i",$text)) {
   $text = "";
   }
8. Проверка на загрузку файла при помощи HTTP POST
   Обеспечивает защиту от PHP-инъекций через загрузку файлов. Для обеспечения этого загруженные на сервер файлы необходимо проверять функцией is_uploaded_file() или перемещать функцией move_uploaded_file() . Данный вид защиты можно не использовать, если отключена возможность задания глобальных переменных.
9. Экранирование символов кавычек данных, передаваемых в базу данных
   Обеспечивает защиту от SQL-инъекций. Наиболее оптимальным методом является обработка всех поступивших не числовых данных с помощью функции mysql_real_escape_string() . Можно так же использовать автоматическое экранирование, поступающих данных. Для этого достаточно в файле.htaccess добавить строку php_value magic_quotes_gpc on , но этот способ не является надёжным, так как может привести к двойному экранированию.
   Пример экранирования кавычек с помощью функции mysql_real_escape_string() :
   if (!is_numeric($text)) {
   $textrequest = mysql_real_escape_string($text);
   }
10. Преобразование специальных символов в html-сущности перед выводом
    Обеспечивает защиту от XSS. Для этого данные, введенные пользователем, которые могут содержать нежелательные html-тэги, при выводе достаточно обработать функцией htmlspecialchars() . Данный вид защиты можно не использовать, если фильтрация поступающих данных отсеивает опасные html-тэги.

Как видите создание продуманной системы безопасности скриптов не такое трудоёмкое дело как кажется.
Данная статья не претендует на роль учебника по безопасности скриптов, но Я надеюсь, что она подтолкнёт php-программистов использовать более продуманные методы защиты.

PHP является одним из самых популярных языков для веб-разработки на данный момент. В результате, хакеры постоянно ищут способы использования PHP сценариев для получения несанкционированного доступа или нанесения ущерба системе. Безопасность PHP кода необходима в любом веб-приложение, которое вы разрабатываете.

Для обеспечения безопасности PHP-приложения существует две основные категории методов защиты кода. Первая категория включает настройку самого интерпретатора PHP через файл php.ini, что оказывает влияние на безопасность приложения в целом. Вторая категория подразумевает использование проверенных методов программирования и написание безопасного кода для предотвращения использования уязвимостей.

Защита PHP с помощью php.ini

В PHP существует целый ряд настроек, которые влияют на безопасность ваших приложений. Этими настройками можно управлять с помощью файла php.ini . Контролируя саму работу PHP, вы снижаете потенциальный ущерб, который могут нанести ошибки.

Запретить Register Globals

До версии 4.2.0, PHP использовал глобальные переменные для предоставления доступа к входным переменным из запросов GET и POST. Эта функция была ликвидирована, поскольку она обеспечивает лазейку в безопасности. Злоумышленники могут использовать его для управления переменными в рамках различных сценариев. Но для обеспечения обратной совместимости PHP позволяет настраивать register_globals в php.ini . Когда эта опция включена, PHP работает в старом режиме и регистрирует глобольные переменные для входных значений. Чтобы обеспечить безопасность PHP, всегда следует выключать эту настройку. Избегайте использования сценариев, которым требуется register_globals, поскольку это обычно является признаком потенциально опасных или редко обновляемых сценариев.

Управление доступом к файлам

PHP-сценарии могут использовать функцию fopen для чтения и записи файлов на файловой системе сервера. Это, конечно, очень нужная возможность. Тем не менее, она также может представлять угрозу безопасности. Ошибка в сценарии PHP может позволить злоумышленнику читать или переписывать системные файлы. К счастью, в PHP есть ряд параметров, которые позволяют контролировать, к каким файлам PHP может получить доступ.

Хотите начать зарабатывать, продвигая свой аккаунт в социальных сетях и используя интернет маркетинг, но не знаете с чего начать? Сайт прайссмм поможет Вам разобраться в таком процессе. Здесь молодой, но достаточно опытный специалист расскажет Вам о том, чего многие до сих пор не знают. Это поможет Вам достаточно быстро поднять рейтинг любой страницы, аккаунта или канала.

Один из вариантов, который можно использовать в php.ini это open_basedir . Данный параметр принимает в качестве значения подкаталог, такой как /home/user/html/ . Ввод/вывод интерпретатора ограничивается указанным подкаталогом, что предотвращает чтение и запись файлов за пределами данного подкаталога с помощью PHP.

Вы можете также использовать параметр safe_mode в php.ini для управления доступом к файлам. В безопасном режиме PHP способен открывать только те файлы, которые принадлежат тому же пользователю, что и веб-сервер. Настройка также предотвращает запуск исполнимых файлов с помощью PHP. Если нужно разрешить PHP доступа к файлам, которые принадлежат разным владельцам, можно использовать safe_mode_gid . Параметр ограничивает доступ в PHP только теми файлами, которые принадлежат группе, под которой работает веб-сервер.

Сокрытие PHP

Хотя обеспечения безопасности путем внесения неясности недостаточно для защиты приложения, это усложнит попытки взлома, поскольку хакеры не будут знать, какие технологии вы используете. PHP выдает себя по ряду признаков, среди которых заголовки и подпись Apache. Это можно отключить с помощью expose_php = off в php.ini .

Ещё один признак, который выдает PHP, это отображение ошибок. Ошибки часто включают в себя информацию о путях и других параметрах, которую хакер найдет неоценимой. Сообщения об ошибках являются бесценными в процессе разработки для тестирования и отладки, но они должны быть выключены при введении приложения в эксплуатацию. Вы можете их отключить, установив: display_errors = Off в php.ini . Полезной функцией является запись сообщений об ошибках в лог-файл, которую можно включить, установив: log_errors = On в php.ini .

Наконец, можно настроить Apache для перезаписи URL, чтобы скрыть расширение PHP.

Использование проверенных методов программирования

После обеспечения безопасности PHP настройкой php.ini, необходимо обратить внимание на сам код. Другим методом защиты PHP является хорошая техника программирования. Есть целый ряд проверенных методов программирования, но не меньше методик, которые нужно избегать.

Контроль POST и передачи форм

Подмена форм (form spoofing) является распространенным видом атаки на веб-сайты.. Обычно это делается путем создания POST-запроса и отправки его по URL адресу, указанному в атрибуте action на форме. Чаще всего, подмена бывает безвредной, но раздражающей, например, когда спамеры отправляют спам сценариям, которые обрабатывают форму обратной связи. Тем не менее, подмена формы может быть опасной. Некоторые разработчики считают, что использование раскрывающегося списка на форме может ограничить пользовательский ввод. После этого они не проверяют данные, введенные пользователем, потому что считают, что форма выполнила проверку для них. Это может быть опасно, если кто-то отправит сценарию данные, не используя форму. Переданные данные не будут ограничиваться списком выбора.

Одним из способов защиты от подмены формы является использование одноразовых маркеров. Генерируйте случайные маркеры и храните вместе с сессией. Затем с помощью скрытых полей ввода отправляйте одноразовые маркеры как часть формы. При обработке формы сравните маркер в сессии и маркер на форме. Если они совпадают, обработайте форму, если нет – выведите сообщение об ошибке. После обработке следует удалить маркер из сессии.

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

Защита баз данных

При работе с базами данных вы не должны использовать динамические SQL операторы, которые основаны на пользовательском вводе. Это создает реальную возможность для злоумышленников направить неправильные данные в базу данных. Иногда вы должны использовать вводимые пользователем данные в запросе SQL. Проверяйте введенные пользователем данные, прежде чем использовать их в запросе. Если база данных MySQL, вы можете использовать функцию mysql_real_escape_string() . Эта функция удалит недопустимые символы, эффективно обрабатывая пользовательский ввод. Если ваш код использует PHP функциональность magic_quotes_gpc , сейчас самое время пересмотреть назначение кода. Использование magic_quotes_gpc будет прекращено в PHP версии 6.