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

            Начнем с теории, и выясним, что такое взлом сайта. В моем понимании взлом это получение полного, или частичного доступа к управлению сайта. Допустим, вы являетесь администратором корпоративного сайта, и у вас стоит какой-либо популярный бесплатный движок, работающий на MySQL. В принципе ничего предосудительного в этом нет, но если задуматься, что любой человек может знать точную структуру таблиц, sql запросов и прочей ценной информации, то без можно представить такую картину: Ваши конкуренты или просто недовольный клиент решил вам отомстить, разрушив ваш сайт или нарушив его работу, просто ищут “слабые места” в php скриптах и sql запросах и делают свое дело. Под слабыми местами я понимаю sql запросы выполненные без какой-либо проверки на верность введенных данных. В качестве примера можно привести примерно следующий кусочек скрипта:

$next = argv[0]; // видите, никакой проверки ввода!
  $query  = 'SELECT * FROM `table_name` LIMIT 0, $next;";
  $result = mysql_query($query);  

Как видно из примера, в этот скрипт без особых проблем может быть вставлена SQL инъекция, обычная urlencode()'ированная строка, в начале которой стоит знак прерывания текущего запроса и начала нового “0;”.

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

0;
  UPDATE user SET Password=PASSWORD('New_password') WHERE user='root';
  FLUSH PRIVILEGES;  

Если же скрипт имеет только права на удаление или запись в базу, то можно сделать примерно следующее:

0;
  DROP TABLE `table_name`  

или

0;
DELETE FROM `registred_user` 

Как вы видите, sql инъекция очень страшная вещь, если ей умело пользоваться. Что же делать!, возразите вы мне, а ответ очень прост:

Во-первых: создать несколько пользователей с разными правами, например: один, для записи в базу данных, другой, для чтения из базы, третий для создания новых таблиц и удаления, четвертый для создания новых пользователей, и самое главное, никогда и нигде не открывать соединение с базой от имени пользователя root!!!

Во-вторых: обязательно нужно проверять вводимые данные на корректность ввода. К примеру, проверять тип вводимых переменных с помощью функции is_numeric или is_string или им подобными функциями. Ну, или самостоятельно изменять тип переменных на нужный с помощью функции settype, например settype($next, "integer"); и теперь в $next содержится переменная типа integer.

В-третьих: Весь передаваемый в запрос текст нужно закавычивать с помощью addslashes и addcslashes, что бы избежать присоединения к тексту sql инъекции.

В-четвертых: Не выводите никаких ошибок о работе скрипта, во всяком случае, уже полностью рабочего и отлаженного, вставив функцию error_reporting(0); в начало скрипта.

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

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