Sql ін'єкції, все для початківця хакера безкоштовні програми для злому, відео уроки

SQL ін'єкція - це один з найдоступніших способів злому сайту.
Суть таких ін'єкцій - впровадження в дані (передані через GET, POST запити або значення Cookie) довільного SQL коду. Якщо сайт вразливий і виконує такі ін'єкції, то по суті є можливість творити з БД (найчастіше це MySQL) що завгодно.

Як обчислити вразливість, що дозволяє впроваджувати SQL ін'єкції?

Змінюємо GET запит на? Detail = 1 \ 'або? Detail = 1 ". Далі пробуємо передавати ці запити серверу, тобто заходимо на test.ru/? Detail = 1 \' або наtest.ru /? Detail = 1 \" .

Якщо під час заходу на дані сторінки з'являється помилка, значить сайт вразливий на SQL ін'єкції.

Приклад помилки, що виникає при перевірці уразливості

Практика. Варіанти злому сайту з уразливістю на SQL впровадження

Отже, у нас є вже згадуваний сайт test.ru. У базі зберігається 4 новини, 3 з яких виводяться. Дозвіл на публікацію новини залежить від парметри public (якщо параметр містить значення 1, то новина публікується).

Тестую наступні варіанти:
test.ru/?detail=4+OR+1
test.ru/?detail=4+-
test.ru/?detail=4+UNION+SELECT+*+FROM+news+WHERE+id=4

У підсумку удача посміхнулася і два запити (перший і третій) повернули нам детальний опис четвертої новини

Розбір прикладу зсередини

За отримання детального опису новини відповідає блок коду:
$ Detail_id = $ _ GET [\ 'detail \'];
$ Zapros = "SELECT * FROM` $ table_news` WHERE `public` = \ '1 \' AND` id` = $ detail_id ORDER BY `position` DESC";

Мало того, що $ detail_id отримує значення без будь-якої обробки, так ще й конструкція `id` = $ detail_id написана криво, краще дотримуватися` id` = \ '$ detail_id \' (тобто сравниваемое значення писати в прямих апострофах).

Дивлячись на запит, одержуваний при зверненні до сторінки через test.ru/?detail=4+OR+1

SELECT * FROM `news` WHERE` public` = \ '1 \' AND `id` = 4 OR 1 ORDER BY` position` DESC

стає не зовсім ясно, чому відобразилася 4-а новина. Справа в тому, що запит повернув всі записи з таблиці новин, відсортовані в порядку убування зверху. І таким чином наша 4-а новина виявилася найпершою, вона ж і вивелася як детальна. Тобто просто збіг.

Розбираємо запит, сформований при зверненні через test.ru/?detail=4+UNION+SELECT+*+FROM+news+WHERE+id=4.

Тут назва таблиці з новинами (в нашому випадку це news) бралося логічним перебором.
Отже, виконався запит SELECT * FROM `news` WHERE` public` = \ '1 \' AND `id` = 4 UNION SELECT * FROM news WHERE id = 4 ORDER BY` position` DESC. До нульового результату першої частини запиту (до UNION) приєднався результат другої частини (після UNION), яка повернула детальний опис 4-ої новини.

Захист від SQL ін'єкцій (SQL впроваджень)

Захист від злому зводиться до базового правилом «довіряй, але перевіряй». Перевіряти треба все - числа, рядки, дати, дані в спеціальних форматах.

Для перевірки змінної на числове значення використовується функція is_numeric (n) ;, яка поверне true, якщо параметр n - число, і false у противному випадку.
Так само можна не перевіряти значення на число, а вручну перевизначити тип. Ось приклад, переобумовленої значення $ id, отримане від $ _GET [\ 'id_news \'] в значення цілочисельного типу (в ціле число):
$ Id = (int) $ _ GET [\ 'id_news \'];

Більшість зломів через SQL відбуваються через знаходження в рядках «незнешкоджених» лапок, апострофів і інших спеціальних символів. Для такого знешкодження потрібно використовувати функцію addslashes ($ str) ;, яка повертає рядок $ str з доданим зворотним слешем (\\) перед кожним спеціальним символом. Даний процес називається екранізацією.

$ A = "приклад тексту з апострофом \ '";
echo addslashes ($ a); // буде виведено: приклад тексту з апострофом \\\ '

Крім цього існують дві функції, створені саме для екранізації рядків, які використовуються в SQL виразах.
Це mysql_escape_string ($ str); і mysql_real_escape_string ($ str) ;.

Перша не враховує кодування з'єднання з БД і може бути обійдена, а ось друга її враховує і абсолютно безпечна. mysql_real_escape_string ($ str); повертає рядок $ str з доданим зворотним слешем до наступних символів: \\ x00, \\ n, \\ r, \\, \ ', "і \\ x1a.

магічні лапки

Магічні лапки - ефект автоматичної заміни лапки на зворотний слеш (\\) і лапки при операціях введення / виводу. У деяких конфігураціях PHP цей параметр включений, а в деяких немає. Для того, що б уникнути подвійного екранізірованія символів і заекранізіровать дані по-нормальному через mysql_real_escape_string ($ str) ;, необхідно прибрати автоматичні проставлені зворотні слеші (якщо магічні лапки включені).

Перевірка включеності магічних лапок для даних одержуваних з GET, POST або Куков організовується через функцію get_magic_quotes_gpc (); (Повертає 1 - якщо магічні лапки включені, 0 - якщо відключені).

Якщо магічні лапки вкючая (тобто зворотні слеші добавляеются) і таке зустрічається частіше, то їх потрібно прибрати. Це робиться через функцію stripslashes ($ str); (Повертає рядок $ str без зворотних слешів у лапок і прямих апострофів).

У закюченіі привожу код з повною екранізацією рядків для запису в БД

if (get_magic_quotes_gpc () == 1)
$ Element_title = stripslashes (trim ($ _ POST [ "element_title"]));
$ Element_text = stripslashes (trim ($ _ POST [ "element_text"]));
$ Element_date = stripslashes (trim ($ _ POST [ "element_date"]));
>
else
$ Element_title = trim ($ _ POST [ "element_title"]);
$ Element_text = trim ($ _ POST [ "element_text"]);
$ Element_date = trim ($ _ POST [ "element_date"]);
>

$ Element_title = mysql_real_escape_string ($ element_title);
$ Element_text = mysql_real_escape_string ($ element_text);
$ Element_date = mysql_real_escape_string ($ element_date);

SQL ін'єкція - це один з найдоступніших способів злому сайту.
Суть таких ін'єкцій - впровадження в дані (передані через GET, POST запити або значення Cookie) довільного SQL коду. Якщо сайт вразливий і виконує такі ін'єкції, то по суті є можливість творити з БД (найчастіше це MySQL) що завгодно.

Як обчислити вразливість, що дозволяє впроваджувати SQL ін'єкції?

Змінюємо GET запит на? Detail = 1 \ 'або? Detail = 1 ". Далі пробуємо передавати ці запити серверу, тобто заходимо на test.ru/? Detail = 1 \' або наtest.ru /? Detail = 1 \" .

Якщо під час заходу на дані сторінки з'являється помилка, значить сайт вразливий на SQL ін'єкції.

Приклад помилки, що виникає при перевірці уразливості

Практика. Варіанти злому сайту з уразливістю на SQL впровадження

Отже, у нас є вже згадуваний сайт test.ru. У базі зберігається 4 новини, 3 з яких виводяться. Дозвіл на публікацію новини залежить від парметри public (якщо параметр містить значення 1, то новина публікується).

Тестую наступні варіанти:
test.ru/?detail=4+OR+1
test.ru/?detail=4+-
test.ru/?detail=4+UNION+SELECT+*+FROM+news+WHERE+id=4

У підсумку удача посміхнулася і два запити (перший і третій) повернули нам детальний опис четвертої новини

Розбір прикладу зсередини

За отримання детального опису новини відповідає блок коду:
$ Detail_id = $ _ GET [\ 'detail \'];
$ Zapros = "SELECT * FROM` $ table_news` WHERE `public` = \ '1 \' AND` id` = $ detail_id ORDER BY `position` DESC";

Мало того, що $ detail_id отримує значення без будь-якої обробки, так ще й конструкція `id` = $ detail_id написана криво, краще дотримуватися` id` = \ '$ detail_id \' (тобто сравниваемое значення писати в прямих апострофах).

Дивлячись на запит, одержуваний при зверненні до сторінки через test.ru/?detail=4+OR+1

SELECT * FROM `news` WHERE` public` = \ '1 \' AND `id` = 4 OR 1 ORDER BY` position` DESC

стає не зовсім ясно, чому відобразилася 4-а новина. Справа в тому, що запит повернув всі записи з таблиці новин, відсортовані в порядку убування зверху. І таким чином наша 4-а новина виявилася найпершою, вона ж і вивелася як детальна. Тобто просто збіг.

Розбираємо запит, сформований при зверненні через test.ru/?detail=4+UNION+SELECT+*+FROM+news+WHERE+id=4.

Тут назва таблиці з новинами (в нашому випадку це news) бралося логічним перебором.
Отже, виконався запит SELECT * FROM `news` WHERE` public` = \ '1 \' AND `id` = 4 UNION SELECT * FROM news WHERE id = 4 ORDER BY` position` DESC. До нульового результату першої частини запиту (до UNION) приєднався результат другої частини (після UNION), яка повернула детальний опис 4-ої новини.

Захист від SQL ін'єкцій (SQL впроваджень)

Захист від злому зводиться до базового правилом «довіряй, але перевіряй». Перевіряти треба все - числа, рядки, дати, дані в спеціальних форматах.

Для перевірки змінної на числове значення використовується функція is_numeric (n) ;, яка поверне true, якщо параметр n - число, і false у противному випадку.
Так само можна не перевіряти значення на число, а вручну перевизначити тип. Ось приклад, переобумовленої значення $ id, отримане від $ _GET [\ 'id_news \'] в значення цілочисельного типу (в ціле число):
$ Id = (int) $ _ GET [\ 'id_news \'];

Більшість зломів через SQL відбуваються через знаходження в рядках «незнешкоджених» лапок, апострофів і інших спеціальних символів. Для такого знешкодження потрібно використовувати функцію addslashes ($ str) ;, яка повертає рядок $ str з доданим зворотним слешем (\\) перед кожним спеціальним символом. Даний процес називається екранізацією.

$ A = "приклад тексту з апострофом \ '";
echo addslashes ($ a); // буде виведено: приклад тексту з апострофом \\\ '

Крім цього існують дві функції, створені саме для екранізації рядків, які використовуються в SQL виразах.
Це mysql_escape_string ($ str); і mysql_real_escape_string ($ str) ;.

Перша не враховує кодування з'єднання з БД і може бути обійдена, а ось друга її враховує і абсолютно безпечна. mysql_real_escape_string ($ str); повертає рядок $ str з доданим зворотним слешем до наступних символів: \\ x00, \\ n, \\ r, \\, \ ', "і \\ x1a.

магічні лапки

Магічні лапки - ефект автоматичної заміни лапки на зворотний слеш (\\) і лапки при операціях введення / виводу. У деяких конфігураціях PHP цей параметр включений, а в деяких немає. Для того, що б уникнути подвійного екранізірованія символів і заекранізіровать дані по-нормальному через mysql_real_escape_string ($ str) ;, необхідно прибрати автоматичні проставлені зворотні слеші (якщо магічні лапки включені).

Перевірка включеності магічних лапок для даних одержуваних з GET, POST або Куков організовується через функцію get_magic_quotes_gpc (); (Повертає 1 - якщо магічні лапки включені, 0 - якщо відключені).

Якщо магічні лапки вкючая (тобто зворотні слеші добавляеются) і таке зустрічається частіше, то їх потрібно прибрати. Це робиться через функцію stripslashes ($ str); (Повертає рядок $ str без зворотних слешів у лапок і прямих апострофів).

У закюченіі привожу код з повною екранізацією рядків для запису в БД

if (get_magic_quotes_gpc () == 1)
$ Element_title = stripslashes (trim ($ _ POST [ "element_title"]));
$ Element_text = stripslashes (trim ($ _ POST [ "element_text"]));
$ Element_date = stripslashes (trim ($ _ POST [ "element_date"]));
>
else
$ Element_title = trim ($ _ POST [ "element_title"]);
$ Element_text = trim ($ _ POST [ "element_text"]);
$ Element_date = trim ($ _ POST [ "element_date"]);
>

$ Element_title = mysql_real_escape_string ($ element_title);
$ Element_text = mysql_real_escape_string ($ element_text);
$ Element_date = mysql_real_escape_string ($ element_date);

Схожі статті