A3:Injection (SQL, OS command, XML)

І так у цій статті ми розглянемо третю вразливість із цього списку "Injection" з усіх її сторін. Нею вразливе за статистикою 28% компаній...

Ця вразливість поділяється на такі вектори для атаки:

- Ін'єкції через запити SQL, LDAP, XPath

- ін'єкції через команди в операційних системах

- Ін'єкції через синтаксичні аналізи XML

- Ін'єкції через заголовки SMTP

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

1) Запити SQL, LDAP, XPath

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

І так тут ми бачимо форму, при заповненні якої введені дані будуть відправлені в SQL запит, який витягне з бази даних нам відповідь. Якщо є такий користувач у базі даних, нас авторизує. Якщо немає, то нам скаже сорян зарегайся. Те, що ми будемо вводити в поле User, передається в змінну $username, а те, що введуть у поле Pass, передається в змінну $password нашого SQL запиту. А тепер нижче розглянемо те, що відбуватиметься при введенні значень у ці поля...

Давайте введемо такі дані: - у полі User ми введемо значення Svyat, яке, як ми бачимо, позначене червоною стрілкою, стане на місце змінної $username - у полі Pass ми введемо значення 1234, яке, як ми бачимо, позначене синьою стрілкою, стане на місце змінної $password Після запуску цього SQL запиту буде виконано пошук у базі даних, де буде знайдено цього користувача з усією його інформацією, відповідно ми отримаємо позитивну відповідь на сторінці авторизації та успішно авторизуємося. Давайте тепер розглянемо, що може зробити зловмисник у нашому випадку.

Тут зловмисник робить хід конем і цілиться на користувача admin. Давайте розберемо докладніше те, що він запровадив: - у полі User він ввів значення admin, яке, як ми бачимо, відзначено червоною стрілкою, стане на місце змінної $username - у полі Pass він ввів значення ' OR 1=1 --, яке, як бачимо, відзначено синьою стрілкою, стане місце змінної $password.

А тепер давайте розберемо, що відбувається зі змінною $password, коли до неї потрапляють такі дані. Килимком ' із заданого значення ' OR 1=1 --, ми закриваємо цю змінну, залишивши пароль не заповненим, після оператора AND. Це видно на зображенні вище. Потім переходимо до слова OR з нашого значення ' OR 1=1 --, воно говорить про те, що ми викликаємо оператор OR, який виконуватиме свою вже функцію в SQL запиті, тому що ми попередньою лапкою закрили нашу змінну. А вираз 1 = 1 --, говорить про те, що поверни нам трушне значення, так як 1 = 1 прирівнюється як true.

Давайте подивимося на картинку нижче, як наш SQL запит трансформувався після введеного нами значення OR 1 = 1 - в полі Pass.

Сподіваюся тепер зрозуміло, що сталося... Відповідно SQL отримав додаткову умову, яка означає, що цей запит поверне рядок для користувача з користувачем адміністратор, навіть якщо правильний пароль не було введено. У запит додано значення OR 1=1, яке завжди буде оцінюватися як true (оскільки 1 завжди дорівнює 1). OR true завжди буде true, немає значення, що ще введено користувачем, вони автоматично отримають правильний результат. Тепер цей користувач буде авторизовано як адміністратор, навіть якщо він не знає пароля. Це не прикольно погодьтеся.

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

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

Можемо розглянути ще такий випадок, коли ми здійснюємо пошук чогось. Давайте візьмемо такий приклад, шукаємо якогось користувача в системі:

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

Давайте спробуємо ввести якийсь айді і глянути, що станеться:

І так після введення айдихи 1 в наше поле, ми отримали користувача admin з прізвищем adminovich. Здавалося б, що тут може бути не так.

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

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

А тепер давайте в наступному прикладі вживаємо оператор UNION, який робить об'єднання рядків, за допомогою його ми додамо до існуючого запиту, який виконується самим додатком, наш запит, в якому ми хочемо, щоб крім користувача імені та прізвища вивівся пароль, замість останнього, то -Є замість прізвища. Відповідно ми бачимо результат в наявності. У таблиці після звичайного запиту та виведення даних на нього, з'явиться і дані, що стосуються запиту після UNION, тобто Select username, password From users ім'я та паролі цих користувачів.

Якщо є така вразливість, можна навіть спробувати використовувати LOAD_FILE, для завантаження різних речей з файлової системи. Зверніть увагу на запит на нижньому скрині.

2) Команди в операційних системах

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

1) ping 127.0.0.1

Чи пробували ви додати якісь спеціалісти при використанні пінгу? Типу таких:

1) | ping 127.0.0.1 |

2) & ping 127.0.0.1 &

3); ping-i 30 127.0.0.1;

4) % 0a ping 127.0.0.1% 0a

Стежте, на скільки зміниться результат відповіді, навіть так би мовити, час відповіді на відміну від оригінального запиту пінг. Якщо ж відмінність є, то є вразливість. Знову ж таки не всі операційні системи мають цю вразливість, найбільше нею заражені дуже старі ОС. Давайте поглянемо на практичний приклад через додаток BWapp:

Що ми маємо тут? Уявіть, що це консоль, якою ми можемо перевіряти якийсь ресурс. Допустимо давайте перевіримо за допомогою lookup цей сайт, який відображено на скріншоті вище. При виконанні такої команди, сервак нам віддасть його ip.

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

Давайте розглянемо ще одну команду для закріплення розуміння ОС команд інжекшин. На цей раз введемо UNIX команду ;ls; після назви нашого сайту, яка працює як покажи мені весь вміст у цьому каталозі.

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

Це звичайний запит, у якого в тілі лежить запит на файл pdf, давайте додамо спеціальні команди в нашому боді запит на цей файл, +|+Dir c:.

І якщо програма не фільтрує зайві запити, то ми отримаємо все, що знаходиться всередині директорії С

Спеціальні символи для команд

Небагато розповім про спецсимволи для команд, що вони роблять | ; &$><`!

- команда1 | команда2 - використання символу труба | зробить команду 2 здійсненною, у тому випадку, якщо команда 1 буде виконана чи ні.

- команда1; команда2 - використання символу крапка з комою; зробить команду 2 теж здійсненною, якщо команда 1 буде виконана чи ні.

- команда1||команда2 - у разі команда 2 буде виконано, лише у разі збою команди 1.

- команда1&&команда2 - команда 2 буде виконана лише за успішного виконання команди 1.

- $(команда) - як приклад, echo $(whoami), для виконання команди

- 'команда' - працює лише певних команд. Як приклад 'whoami'

- >(команда) - як приклад <(ls) - <(команда) - як приклад>(ls)

Санітарна

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

Загальний перелік, який буде включений для введення команд, може бути таким | ; & $ > < ' ! >> #

Спеціальні символи для Windows, ( ) < > & ‘ | =? ; [ ] ^ ~ ! . ' % @ / : + , `

Спеціальні символи для Linux, { } ( ) < > & ‘ | =? ; [] $ - # ~! . ' % / : + , `

Права доступу

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