SQL ін'єкція

Що таке SQL ін'єкція?

Рядок, наданий користувачем, об’єднується в запит, і цей рядок може змінити те, що вимагається в запиті. Кожен запит тут виконується проти реальної вбудованої бази даних, тому нічого не підробляється. Ви зламаєте форму пошуку облікового запису за допомогою однієї лапки, повернете всю таблицю учасників за допомогою ' OR '1'='1 , а потім використаєте UNION SELECT і information_schema , щоб отримати з неї електронні адреси адміністратора та хеші паролів. Виправлення прив’язує значення як параметр, тому граматика SQL ніколи не аналізує вхідні дані як код. Не дезінфекція, не список блокувань брандмауера.

Що ви дізнаєтесь у SQL ін'єкція

• Розпізнати підручницьку тавтологію SQL-ін’єкцій ' АБО '1'='1 і пояснити, чому завжди справжня умова обходить фільтр WHERE
• Відстежте, як кінцева точка пошуку з одним рядком стає читанням повної таблиці, коли її параметр об’єднується в рядок SQL
• Використовуйте UNION SELECT, щоб перерахувати таблиці бази даних за допомогою information_schema та отримати рядки з таблиці, яку форма ніколи не відображала, наприклад admin_users
• Відрізнити параметризовані запити (надійний захист) від засобів захисту від маніпулювання рядками, як-от списки блокування, екранування та правила WAF, і пояснити, чому діє лише параметризований підхід
• Прочитайте вразливий обробник бази даних достатньо добре, щоб помітити помилку конкатенації, а потім підтвердьте параметризоване виправлення, повторно запустивши точне корисне навантаження проти виправленої кінцевої точки та побачивши нуль рядків

SQL ін'єкція — Кроки навчання

1. Знайдіть цільову форму

   У Боба є Vantyr , членський сервіс із загальнодоступною сторінкою account-lookup . Немає входу, лише поле електронної пошти, яке повертає план учасника. Тут починаються веб-атаки: звичайна форма, яка тихо спілкується з базою даних.

2. Надішліть звичайний пошук

   Спочатку подивіться, як нормально поводиться форма. Введіть електронну адресу справжнього учасника та надішліть. Мережева панель браузера відкриває та записує запит, саме те, що розробник бачить у DevTools.

3. Перегляньте запит

   Ось запит. Введений вами електронний лист надсилається на сервер у запиті payload , а відповідь повертає одного відповідного учасника. Поки нічого поганого. Ось як ця функція має працювати.

4. Прочитайте код обробника

   Тепер найцікавіше: код сервера, який обробляє цей запит. Він створює SQL-запит, вставляючи вашу електронну пошту прямо в рядок запиту . Це одне твердження — уся проблема.

5. Визначте вразливу лінію

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

6. Розбийте його цитатою

   Поле все ще містить morgan.lee@example.com з вашого першого пошуку. Ваші дані потрапляють у рядок у лапках, тож що відбувається, коли ви надсилаєте цитату? Додайте одну лапку в кінець і надішліть, і спостерігайте за коментарем виконаного запиту у перебудові коду під час введення: ваша цитата потрапляє всередину рядка та розриває його. Ви більше не надсилаєте дані. Ви редагуєте запит.

7. Прочитайте помилку бази даних

   Сервер повернув 500 зі справжньою помилкою бази даних. Ця додаткова лапка завчасно завершила рядок і залишила запит неправильним. База даних спробувала запустити його та захлинулася. Подібна помилка є зеленим світлом для зловмисника: вхідні дані досягають механізму SQL.

8. Обійти фільтр

   Тепер зробіть запит корисним для вас. Закрийте рядок самостійно, додайте умову, яка завжди вірна , і фільтр WHERE припинить фільтрацію. Класика: ' OR '1'='1 .

9. Переглянути повний дамп

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

10. Перевірка знань

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