Phenquestions
Уязвимостта на SQL прекъсване обикновено съществува в базите данни на MySQL. Тази уязвимост е описана за първи път в CVE-2008-4106, която е свързана с WordPress CMS.
Как работят SQL атаките за отрязване
Тази атака работи поради съкращаване на потребителския вход в базите данни, използвайки функциите „избор“ и „вмъкване“.
- Когато въвеждането е дадено в полето на формуляра, функцията 'select' проверява за излишък, съответстващ на входовете в базата данни.
- След проверка за излишък, функцията 'вмъкване' проверява дължината на входа и потребителският вход ще бъде съкратен, ако дължината надвишава.
Да предположим, че разработчикът създава таблицата „потребители“ чрез следната заявка:
създаване на потребители на таблици (user_id INT NOT NULL AUTO_INCREMENT,
потребителско име VARCHAR (20) NOT NULL,
парола VARCHAR (40) НЕ НУЛА,
ОСНОВЕН КЛЮЧ (user_id)
);
Използвайки тази схема, ако разработчикът създаде администраторски акаунт със следното:
user_name = 'администратор'парола = “secret_p4ssw0ord”
Очевидно тези пълномощия не са публични. В базата данни има само един администраторски акаунт и ако нападателят се опита да регистрира друг акаунт с потребителското име „admin“, нападателят ще се провали поради проверките на съкратеността на базата данни. Атакуващият все още може да заобиколи тази проверка за резервиране, за да добави друг акаунт на администратор, като използва уязвимостта на SQL Truncation. Да предположим, че нападателят регистрира друг акаунт със следния вход:
User_name = 'adminxxxxxxxxxxxxxxxrandom'(x са интервалите)
&
Парола = "RandomUser"
Базата данни ще вземе „потребителско име“ (26 знака) и ще провери дали това вече съществува. След това въведеното име_потребител ще бъде съкратено, а 'admin' ('admin' с интервал) ще бъде въведено в базата данни, което ще доведе до два дублирани потребителя на администратор.
След това нападателят е в състояние да създаде „администратор“ потребител със собствена парола. Сега базата данни има два записа „потребителско име“ на администратор, но с различни пароли. Атакуващият може да влезе с новосъздадените идентификационни данни, за да получи администраторски панел, тъй като и двете потребителски имена „admin“ и „admin“ са равни за нивото на базата данни. Сега ще разгледаме примерна практическа атака.
Примерна атака
В този пример ще вземем сценарий от уебсайта.орг. Общността на overthewire предоставя CTF на wargame, на които можем да практикуваме нашите концепции за сигурност. Сценарият на SQL отрязване се среща в natas играта ниво 26-> 27. Можем да получим достъп до нивото, като използваме следното:
URL адрес: http: // natas27.natas.лаборатории.преобръщане.оргПотребителско име: natas27
Парола: 55TBjpPZUUJgVP5b3BnbG6ON9uDPVzCJ
Това ниво е достъпно на: https: // overthewire.org / wargames / natas / natas27.html. Ще ви бъде показана страница за вход, която е уязвима за атака на SQL Truncation.
След проверка на изходния код ще видите, че дължината на потребителското име е 64, както е показано по-долу.
Потребител на име „natas28“ вече съществува. Нашата цел е да създадем друг потребител на име „natas28“, използвайки атаката SQL_truncation. И така, ще въведем natas28, последван от 57 интервали и произволна азбука (в нашия случай а), потребителско име и всяка парола. Буквата „а“ не се вижда на екранната снимка поради потребителското име с дължина 65 знака. След създаването на потребителския акаунт ще можете да видитеа.'
Ако базата данни съдържа уязвимост sql_truncation, тогава базата данни трябва да има две потребителски имена 'natas28'. Едно потребителско име ще съдържа нашата парола. Нека се опитаме да въведем идентификационните данни на страницата за вход.
Сега сме влезли като потребител 'natas28'.
Смекчаване
За да смекчим тази атака, ще трябва да разгледаме множество фактори.
- Не трябва да допускаме дублиране на критични идентичности като потребителското име. Трябва да направим тези идентичности първични ключове.
- Функцията за отрязване трябва да бъде приложена за всички полета на външни форми, както и за вътрешен код, така че базите данни да получават пресечени входове.
- Строгият режим трябва да бъде активиран на ниво база данни. Без активиран строг режим базите данни дават само предупреждения в бекенда, но все пак запазват дублираните данни. При строг режим базите данни дават грешки в случай на дублиране и избягват запазването на данни.
Например, нека проверим за строг режим, като използваме следната заявка:
mysql> изберете @@ sql_mode
Ще създадем база данни и потребители на таблицата.'
mysql> Създаване на тест за база данниЗаявка ОК, засегнат 1 ред (0.02 сек)
mysql> Използвайте тест
Базата данни е променена
mysql> СЪЗДАЙТЕ ТАБЛИЦА потребители (потребителско име VARCHAR (10), парола VARCHAR (10));
Заявка OK, 0 реда засегнати (0.05 сек)
След това ще създадем администраторски потребител с идентификационни данни, използвайки заявката INSERT.
mysql> ВЪВЕЖДАНЕ В СТОЙНОСТИ на потребителите ('admin', 'password1');Заявка ОК, засегнат 1 ред (0.01 сек)
Можем да видим информацията в таблицата „потребители“, като използваме опцията „изберете * от потребители“.
Дължината на потребителското име е 10 знака. Сега ще опитаме SQL атаката за отрязване.
Когато се опитаме да въведем следното:
Потребителско име = 'adminxxxxxa'(x са интервалите)
&
Парола = 'pass2'
Ще получим грешка, което означава, че строгият режим е напълно ефективен.
mysql> INSERT INTO потребителски стойности ('admin a', 'pass2')ГРЕШКА 1406 (22001): Данните са твърде дълги за колона „потребителско име“ на ред 1
Без активиран строг режим базата данни ще извежда предупреждения, но все пак ще вмъква данните в таблицата.
Заключение
Атакуващите могат да получат достъп до акаунти с високи привилегии, ако в приложението ви съществува уязвимостта sql_trunction. Атакуващият може лесно да получи информация за потребителско име и дължината на неговата база данни, използвайки критичните полета, след което да създаде същото потребителско име, последвано от интервали и произволна азбука след минималната дължина, което води до създаването на множество акаунти с високи привилегии. Тази уязвимост е критична, но може да бъде избегната, ако предприемете някои предпазни мерки, като например активиране на строг режим за потребителски въведения и превръщането на чувствителното поле в Първичен ключ в базата данни.
