Як хакери захоплюють веб-сайти за допомогою SQL Injection і DDoS
Навіть якщо ви лише слабко стежили за подіями хакерських груп Anonymous і LulzSec, ви, напевно, чули про сайти і сервіси, які були зламані, як ганебні Sony хакі. Ви коли-небудь замислювалися, як вони це роблять?
Є цілий ряд інструментів і методів, якими користуються ці групи, і, хоча ми не намагаємося дати вам посібник, щоб зробити це самостійно, корисно зрозуміти, що відбувається. Двома атаками, які ви постійно чуєте про них, є “(Distributed) Denial of Service” (DDoS) та “SQL Injections” (SQLI). Ось як вони працюють.
Зображення на xkcd
Відмова в обслуговуванні
Що це?
"Відмова в обслуговуванні" (інколи називається "розподіленим відмовою в обслуговуванні" або DDoS) атака виникає, коли система, в даному випадку веб-сервер, отримує стільки запитів одночасно, що серверні ресурси перевантажені системою просто блокує і вимикається. Метою і результатом успішної DDoS-атаки є недоступність веб-сайтів на цільовому сервері для легальних запитів на трафік.
Як це працює?
Логістику DDoS-атаки можна краще пояснити на прикладі.
Уявіть собі, що мільйон людей (зловмисники) збираються разом з метою перешкодити бізнесу компанії X, знімаючи свій кол-центр. Зловмисники координують так, щоб у вівторок о 9 ранку всі вони називали номер телефону компанії X. Швидше за все, телефонна система компанії X не зможе обробити мільйон дзвінків відразу, так що всі вхідні лінії будуть зв'язані зловмисниками. Результатом є те, що легітимні дзвінки клієнтів (тобто ті, які не є нападниками) не проходять через те, що телефонна система пов'язана з обробкою викликів зловмисників. Таким чином, компанія X потенційно втрачає бізнес через легітимні прохання про те, що вони не в змозі пройти через це.
Атака DDoS на веб-сервері працює точно так само. Оскільки практично немає способу дізнатися, який трафік походить від законних запитів проти нападників, поки веб-сервер не обробляє запит, цей тип атаки, як правило, дуже ефективний.
Виконання атаки
Завдяки «грубій силі» характеру DDoS-атаки, вам потрібно мати багато комп'ютерів, які скоординовані для атаки одночасно. Переглядаючи приклад нашого центру обробки викликів, для цього потрібно, щоб всі зловмисники знали, що вони повинні дзвонити о 9 ранку і фактично викликати в цей час. Хоча цей принцип, безумовно, буде працювати, коли справа доходить до атаки на веб-сервер, це стає значно легше, коли комп'ютери-зомбі, замість реальних пілотованих комп'ютерів, використовуються.
Як ви, напевно, знаєте, існує безліч варіантів шкідливих програм і троянів, які, колись у вашій системі, знаходяться в стані спокою, а іноді і "телефонують додому" для отримання інструкцій. Одним з таких вказівок може бути, наприклад, надсилання повторних запитів до веб-сервера компанії X о 9 ранку. Таким чином, з одним оновленням до домашнього розташування відповідного шкідливого програмного забезпечення, один зловмисник може миттєво координувати сотні тисяч компрометованих комп'ютерів для виконання масової атаки DDoS.
Краса використання комп'ютерів-зомбі полягає не тільки в його ефективності, але і в її анонімності, оскільки зловмисник не повинен взагалі використовувати свій комп'ютер для виконання атаки.
SQL Injection Attack
Що це?
Атака «SQL-ін'єкція» (SQLI) - це експлуатат, який використовує переваги слабких методів веб-розробки і, як правило, поєднується з помилковою безпекою бази даних. Результат успішної атаки може варіюватися від уособлення облікового запису користувача до повного компромісу відповідної бази даних або сервера. На відміну від DDoS-атаки, атака SQLI повністю і легко запобігає, якщо веб-додаток запрограмовано належним чином.
Виконання атаки
Всякий раз, коли ви входите на веб-сайт і вводите своє ім'я користувача і пароль, щоб перевірити облікові дані, веб-додаток може запустити запит, подібний до наведеного нижче:
SELECT UserID FROM Користувачі WHERE UserName = "myuser" І Password = "mypass";
Примітка: рядкові значення в запиті SQL повинні бути укладені в одинарні лапки, тому вони з'являються навколо введених користувачем значень.
Таким чином, комбінація введеного імені користувача (myuser) і пароля (mypass) повинна відповідати запису в таблиці Users для того, щоб повернути UserID. Якщо немає відповідності, ідентифікатор користувача не повертається, тому реєстраційні дані недійсні. Хоча конкретна реалізація може відрізнятися, механіка є досить стандартною.
Тепер давайте подивимося на запит автентифікації шаблону, який можна замінити значеннями, які користувач вводить у веб-форму:
SELECT UserID FROM Користувачі WHERE UserName = "[user]" AND Password = "[pass]"
На перший погляд це може здатися простим і логічним кроком для легкої перевірки користувачів, однак, якщо на цьому шаблоні виконується проста заміна введених користувачем значень, вона піддається атаці SQLI.
Наприклад, припустимо, що в поле імені користувача введено “myuser'-”, а в пароль введено “wrongpass”. Використовуючи просту заміну в нашому шаблоні, ми отримаємо таке:
SELECT UserID FROM Користувачі WHERE Користувач = "myuser" - 'AND Password = "wrongpass"
Ключем до цього твердження є включення двох тире (-). Це початковий маркер коментарів для операторів SQL, так що все, що з'являється після двох тире (включно), буде проігноровано. По суті, вищезазначений запит виконується базою даних як:
SELECT UserID FROM Користувачі WHERE Користувач = "myuser"
Очевидним недоліком тут є відсутність перевірки пароля. Включивши два тире як частину поля користувача, ми повністю обійшли умову перевірки пароля і змогли увійти в систему як "myuser", не знаючи відповідного пароля. Цей акт маніпулювання запитом для отримання ненавмисних результатів є атакою ін'єкції SQL.
Яка шкода може бути завдана?
Атака ін'єкції SQL викликана недбалістю і безвідповідальним кодуванням додатків і повністю запобігається (яку ми розглянемо в даний момент), однак ступінь шкоди, яку можна зробити, залежить від налаштування бази даних. Для того, щоб веб-додаток зв'язувалося з базою даних, програма повинна надати логін до бази даних (зауважте, це відрізняється від входу користувача до самого веб-сайту). Залежно від дозволів, які вимагає веб-додаток, цей відповідний обліковий запис бази даних може вимагати що-небудь від дозволу читання / запису в існуючих таблицях лише до повного доступу до бази даних. Якщо це зараз не зрозуміло, кілька прикладів допоможуть забезпечити певну ясність.
Виходячи з наведеного вище прикладу, можна побачити, що, наприклад, ввести, "Ваш користувач" - "," адміністратор "-" або будь-яке інше ім'я користувача, ми можемо миттєво входити на сайт як цей користувач, не знаючи пароля. Коли ми в системі не знаємо, що ми насправді не є таким користувачем, ми маємо повний доступ до відповідного облікового запису. Дозволи для бази даних не забезпечують безпеку для цього, оскільки, як правило, веб-сайт повинен мати принаймні доступ на читання / запис до своєї відповідної бази даних.
Тепер давайте припустимо, що веб-сайт має повний контроль над своєю відповідною базою даних, що дає можливість видаляти записи, додавати / видаляти таблиці, додавати нові облікові записи тощо. Важливо відзначити, що деякі веб-програми можуть потребувати такого типу дозволу, тому не є автоматично поганим, що повний контроль надається.
Для того, щоб проілюструвати збитки, які можна зробити в цій ситуації, ми скористаємося прикладом, наведеним у коміці вище, ввівши наступне в поле імені користувача: "Роберт"; Користувачі DROP TABLE; - ". Після простої заміни запит аутентифікації стає:
SELECT UserID FROM Користувачі WHERE UserName = "Robert"; Користувачі DROP TABLE; - 'AND Password = "wrongpass"
Примітка: крапка з комою в запиті SQL використовується для позначення кінця конкретного оператора і початку нової операції.
Яка виконується базою даних як:
SELECT UserID FROM Користувачі WHERE Користувач = "Роберт"Користувачі DROP TABLE
Так само так, ми використовували атаку SQLI для видалення всієї таблиці Users.
Звичайно, набагато гірше можна зробити, оскільки, залежно від дозволів SQL, зловмисник може змінювати значення, таблиці дампа (або всю саму базу даних) до текстового файлу, створювати нові облікові записи для входу або навіть захоплювати всю установку бази даних..
Запобігання атаці ін'єкцій SQL
Як ми вже згадували кілька разів раніше, атака SQL-ін'єкції легко запобігти. Одним з основних правил веб-розробки є те, що ви ніколи не сліпо довіряєте введенню користувача, як ми, коли ми виконували просту заміну в нашому шаблоні запиту вище.
Атака SQLI легко перешкоджає тому, що називається санітарізація (або уникнення) ваших входів. Процес дезінфекції насправді досить тривіальний, тому що все, що він по суті робить, - обробляти будь-які вбудовані символи окремої цитати (') відповідним чином, щоб вони не могли бути використані для передчасного припинення рядка всередині оператора SQL.
Наприклад, якщо ви хочете знайти "O'neil" в базі даних, ви не можете використовувати просту заміну, тому що одиночна цитата після O призведе до того, що рядок достроково закінчиться. Замість цього ви дезінфікуєте його, використовуючи відповідний вихідний символ бази даних. Припустимо, що символ втечі для окремої єдиної лапки є попередньою кожною цитатою символом. Отже, "O'neal" буде дезінфікований як "O \ t.
Цей простий акт санітарії значною мірою запобігає атаці SQLI. Щоб проілюструвати, давайте переглянемо наші попередні приклади і побачимо результуючі запити, коли користувальницький вхід санітований.
myuser '-- / неправильно:
SELECT UserID FROM Користувачі WHERE Користувач = "myuser" - 'AND Password = "wrongpass"
Оскільки єдина цитата після того, як myuser буде перервано (тобто він вважається частиною цільового значення), база даних буде буквально шукати ім'я користувача "myuser" - ". Окрім того, оскільки тире включено до значення рядка, а не самого оператора SQL, вони вважатимуться частиною цільового значення, а не інтерпретуватися як коментар SQL.
Роберт '; Користувачі DROP TABLE;-- / неправильно:
SELECT UserID FROM Користувачі WHERE UserName = "Robert"; Користувачі DROP TABLE; - 'AND Password = "wrongpass"
Просто вибираючи одну цитату після Роберта, і крапка з комою, і тире містяться в рядку пошуку в UserName, тому база даних буквально шукатиме "Роберт"; Користувачі DROP TABLE; - " замість виконання таблиці видалити.
У резюме
Хоча веб-атаки еволюціонують і стають більш складними або зосереджуються на іншому місці входу, важливо пам'ятати про захист від перевірених і справжніх атак, які були натхненням декількох вільно доступних «хакерських інструментів», призначених для їх використання.
Деякі типи атак, наприклад DDoS, неможливо уникнути, тоді як інші, такі як SQLI, можуть. Проте збитки, які можуть бути завдані цими типами атак, можуть коливатися від незручностей до катастрофічних залежно від запобіжних заходів.
