DB атака сайт
Специално: Hacker, стая # 052, стр 052-084-1.
Какво може нападателя с помощта на SQL инжекция
С всеки изминал ден, все повече скриптове, използвайки базата данни, по-надеждни хостинг пароли на своите клиенти SQL-база данни, по-популярни сайтове отива на обществени форуми и двигатели, работещи с MySQL. Но не всеки ясно да си представите колко опасно може да бъде зле замислена използване на MySQL скриптове.
Без основни познания по езика SQL е трудно да се разбере нищо. На първо място, ние трябва да разберем, каква е същността на вида на инжекция атаки SQL. Например, на сървъра приемник е на стойност след PHP-скрипт, който се основава на поле category_id извлича заглавията статия от членове на маса и ги показва на потребителя:
// свърже с MySQL
mysql_connect ($ dbhost, $ dbuname, $ dbpass) или умират (mysql_error ());
mysql_select_db ($ DBNAME) или умират (mysql_error ());
$ Резултат = mysql_query ( "SELECT article_id, ARTICLE_TITLE от членове където category_id = $ CID"); // <- уязвимый запрос
а ($ навън = mysql_fetch_array ($ резултат)):
// показване на резултата в списък
Защо сте грешка? Да видим какво са поискали PHP MySQL. променлива $ CID е # 1 ", а след това по искане отнема погрешно от гледна точка на MySQL на: Изберете article_id, ARTICLE_TITLE от членове където category_id = # 1". Когато синтактична грешка в MySQL низ на заявката отговаря "Грешка 1064: Имате грешка в SQL синтаксис.". PHP не разпознава отговора и докладите на грешката, по които един хакер може да се съди за наличието на вида на SQL уязвимости инжекция. Очевидно е, че атакуващият ще бъде в състояние да определи променливата $ CID всяка стойност ($ CID = $ _ GET [CID]) и следователно променят заявката за MySQL. Например, ако $ CID е равна на "1 или 1" (без кавички в началото и в края), а след това MySQL връща всички записи, независимо category_id, тъй като искането ще има формата (..), където category_id = 1 или 1. Това е или category_id = 1 (само подходящ category_id запис, равно на 1) или 1 (побере всички записи, тъй като този брой е по-голяма от нула - винаги е вярно).
Само тези стъпки само наречените SQL инжекция - SQL-инжекции код в искането за скрипт за MySQL. атакуващият може да получи достъп до данните чрез SQL инжекция, има достъп до уязвими сценария: пароли за ограничени части от сайта, информация за кредитни карти, парола за администратор и т.н. Хакерът с успешна за него обстоятелства ще бъде в състояние да изпълнява команди на сървъра.
Класически пример за уязвимостта на вида на SQL инжекция - следната заявка: SELECT * FROM администратори КЪДЕ вход = # '$ вход #' и парола = MD5 (# "$ парола #").
Съюз и MySQL версия 4
Да се върнем към сценария получаване заглавия на статии. В действителност, тя позволява на атакуващия да спечелят много повече от списък на всички статии. Факт е, че в MySQL версия 4 добавя нов оператор - съюз, който се използва за комбиниране на резултатите от няколко SELECT отчети в един резултат сет. Например: SELECT article_id, ARTICLE_TITLE от членове UNION SELECT ID, заглавие ОТ анкети. В резултат на това, MySQL връща записите N, където N - брой на записи от заявка в ляво, както и броя на записите от резултата на точната заявка. И всичко това в реда, в който исканията се отделят Съюза.
Но има някои ограничения върху използването на Съюза:
1. Числата показват, колоната на всички въпроси трябва да бъде един и същ: nedoputimo да избере първото искане, например, номер, име, титла, а втората само ARTICLE_TITLE;
2. Видовете колони показва една заявка трябва да отговаря на останалите графи посочват видовете заявки, ако един и същи тип заявка избран колони INT, текст, текст, TINYTEXT, а след това поиска Всички останали колони трябва да бъдат избрани от същия вид и в същия ред;
3. съюз не може да отиде след изтичане на оператор и ред.
Е, как да се превърне в съучастник на Съюза е нападателя? В нашия скрипт присъства поискване "SELECT article_id, ARTICLE_TITLE от членове където category_id = $ CID". Какво пречи на хакер с помощта на SQL инжекция, поставете още един SELECT-заявка и изберете желаните данни за него? Точно така: нищо!
Нека да разгледаме модифицираната заявка от PHP към MySQL: SELECT article_id, ARTICLE_TITLE от членове където category_id = 1 UNION SELECT 1,2. В отговор MySQL връща резултата от първия изберете (елементи от списъка) и резултатът от втората Изберете - номер "1" в първата колона, както и "2" във втората колона (SELECT + 1,2). С други думи, сега заместване # "№1" и # "# 2" истинските имена на колоните на всяка маса, ще бъде да получите техните стойности.
Защо не го направи нападателя да поставите името на колона вместо на устройството? Той се нуждае от текстова информация (потребителско име, парола), а в нашия случай в лявата SELECT заявката на първо място е article_id, от тип INT. Вследствие на това право да поиска хакер не може да постави на първо място информация име на колона текст (на правилата на Съюза).
Сега нека разгледаме някои ситуации, при които използването на Съюза е трудно за една или друга причина.
Това се случва, че PHP-код в един ред е повече SQL-заявки податливи на инжектиране. И всички те използвате променлива, към която нападателят вкарва SQL-код. Например (пропуска PHP):
$ Резултат = mysql_query ( "SELECT article_id, ARTICLE_TITLE от членове където category_id = $ CID");
$ Резултат = mysql_query ( "SELECT ARTICLE_NAME от членове където category_id = $ CID");
// тук в резултат на сключването
Това е доста неприятна за хакер, защото за първи SQL заявка инжектиране ще се оправи, а за втората СЪЮЗ - не са, тъй като броят на заявените колони е различен. И ако програмист, който е написал кода, спрете сценария е предвидено в случай на тип грешка ". Или да умре (" грешка База данни! ")", Действието на конвенционални методи не може, защото сценарият ще спре, преди да ще донесе резултати.
Сценарият не извежда цялата резултатите от търсенето, както и, например, само първото влизане. И ако хакер директно ще използва СЪЮЗ, скриптът ще се извеждат само първият запис от отговор MySQL и изхвърлете останалите, включително и в резултат на SQL инжекция. За да се преодолее всички препятствия и на този етап, да се даде хакер напусна параметър искане до къде, че в отговор на MySQL не се върна празен.
Например, има тази заявка: SELECT име ОТ КЪДЕ автори ID = $ номер. След SQL инжекция, той ще бъде, както следва: (..) ID = 1 UNION SELECT парола от автори. Но PHP-скрипт показва само първият запис, така че трябва да бъде променена на кода за вграждане: (..) ИД = -12 345 UNION SELECT (..). Сега, в отговор на ляво MySQL заявката не се връща нищо, а в отговор на правото - добре дошли на данни на хакера.
Да разгледаме следната заявка: SELECT ID ОТ автори където category_id = -1 ЮНИОН SELECT 1,2 ОТ КОИТО автори номер = 1 и ASCII (подниз (парола, 1,1))> 109. резултатният ще бъде един запис, ако ASCII-кода на първите символи на паролата повече от 109, и нула записите, ако по-големи или равни. По този начин, на метода на двоично търсене може лесно да намерите желания символ. Защо хакер използва знаците "повече / по-малко", а не "равни"? Ако нападателят трябва да получи до 32 знака, хеш на паролата, тя ще трябва да се направи около 32 * 25 искания! двоичен метод на търсене дава възможност да се намали този брой наполовина. Разбира се, хакерът трябва да направи, няма да бъде в ръцете, и с един скрипт, който автоматизира търсенето.
Правило №1. Филтрува вход. Цитат се заменя с наклонена черта-цитат (#), наклонена черта - да намали наклонена черта. В PHP, това се извършва чрез включване или magic_quotes_gpc в php.ini или addslashes (функция). В Perl: $ ИД =
с / ([# '\]) / \ $ 1 / г. И за всеки случай: $ ИД =
и / [а-ZA-Z] // г; - за цифровите параметри.
Правило №2. Не позволявайте на никого не е нужно да изпълни SQL-код! Да бъде цитиран всички променливи в запитването. Например, SELECT * FROM потребители КЪДЕ ИД = # '$ ID # ".
Правило №3. Потискане на съобщения за грешки. Някои програмисти, а напротив, го прави така, че когато сценария показва съобщение за грешка на MySQL, или дори по-лошо - цялата SQL-заявка. Тя осигурява допълнителна информация за злодей база структурата и значително улеснява работата.
Правило №4. Никога не позволявайте на скриптове, за да се движат с MySQL от корена. Нищо добро няма да излезе, ако хакер получава достъп до цялата база данни.
Правило №5. Стартира обществени скриптове от един и същи потребител в отделна база данни. Това е неприятно да е, ако има такива дечица, използвайки 0 дни дупки във форума, ще получат достъп до база данни с въже на клиентите си.
Правило №6. Изключете MySQL потребител привилегия ФАЙЛ - Не позволявайте на нападателя да пиша да подаде нещо като