Как хакерите поемат уеб сайтове с SQL инжектиране и DDoS

Дори ако сте проследили само небрежно събитията на хакерските групи Anonymous и LulzSec, вероятно сте чували за хакери на уеб сайтове и услуги, като скандалните Sony хакове. Чудили ли сте се как го правят?

Съществуват редица инструменти и техники, които тези групи използват, и докато ние не се опитваме да ви дадем ръководство, за да направите това сами, полезно е да разберете какво става. Две от атаките, които последователно чувате за тях, са “(Разпределени) отказ на услуга” (DDoS) и “SQL инжекции” (SQLI). Ето как работят.

Изображение от xkcd

Нападение на отказ на услуга

Какво е?

"Отказ в услуга" (понякога наричан "разпределен отказ на услуга" или DDoS) атака възниква, когато системата, в този случай уеб сървър, получава толкова много заявки едновременно, че сървърните ресурси са претоварени, системата просто блокира и се изключва. Целта и резултатът от успешната DDoS атака са сайтовете на целевия сървър да не са достъпни за легитимни заявки за трафик.

Как работи?

Логистиката на DDoS атака може да бъде най-добре обяснена с пример.

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

А DDoS атака на уеб сървър работи точно по същия начин. Тъй като на практика няма начин да се знае какъв трафик се получава от законните заявки срещу атакуващите, докато уеб сървърът обработи заявката, този вид атака обикновено е много ефективен.

Изпълнение на атаката

Поради „бруталната сила” на DDoS атака, трябва да имате много компютри, всички координирани да атакуват по едно и също време. Преразглеждане на нашия пример за кол център, това ще изисква всички нападатели да знаят, че трябва да се обадят в 9 часа сутринта и всъщност да се обадят по това време. Докато този принцип със сигурност ще работи, когато става въпрос за атакуване на уеб сървър, става значително по-лесно, когато се използват зомби компютри, вместо действително пилотирани компютри..

Както вероятно знаете, има много варианти на злонамерен софтуер и троянски коне, които веднъж на вашата система лежат пасивни и понякога "се обаждат по телефона" за инструкции. Една от тези инструкции може да бъде, например, изпращането на многократни заявки към уеб сървъра на X. Така с едно обновяване на домашното местоположение на съответния злонамерен софтуер един атакуващ може незабавно да координира стотици хиляди компрометирани компютри, за да извърши масивна DDoS атака.

Красотата на използване на зомби компютри е не само в нейната ефективност, но и в нейната анонимност, тъй като нападателят всъщност не трябва да използва компютъра си, за да изпълни атаката..

Атака за SQL инжектиране

Какво е?

Атаката "SQL инжекция" (SQLI) (SQLI) е експлоатация, която се възползва от лошите техники за уеб разработки и, обикновено комбинирана с дефектна сигурност на базата данни. Резултатът от успешна атака може да варира от представяне на потребителски акаунт до пълен компромис на съответната база данни или сървър. За разлика от DDoS атаката, SQLI атаката е напълно и лесно предотвратима, ако уеб приложението е програмирано по подходящ начин.

Изпълнение на атаката

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

SELECT Потребителски ИД От потребители WHERE UserName = "myuser" И Password = "mypass";

Забележка: Стойностите на низа в SQL заявката трябва да бъдат затворени в единични кавички, поради което се появяват около въведените от потребителя стойности.

Така че комбинацията от въведеното потребителско име (myuser) и парола (mypass) трябва да съответства на запис в таблицата Users, за да бъде върнат потребителски идентификатор. Ако няма съвпадение, не се връща потребителски идентификатор, така че идентификационните данни за влизане са невалидни. Докато конкретна реализация може да се различава, механиката е доста стандартна.

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

SELECT Потребителски идентификатор FROM Потребители WHERE UserName = "[user]" AND Password = "[pass]"

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

Например, да предположим, че “myuser'-” е въведено в полето за потребителско име и “wrongpass” е въведено в паролата. Използвайки проста замяна в заявката ни за шаблон, ще получим следното:

SELECT UserID FROM Потребители WHERE UserName = "myuser" - "AND Password =" wrongpass "

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

SELECT Потребителски идентификатор от потребители WHERE UserName = "myuser"

Гледащият пропуск тук е липсата на проверка за парола. Като включихме двете тирета като част от потребителското поле, ние напълно заобиколихме условието за проверка на паролата и успяхме да влезем като „myuser“, без да знаем съответната парола. Този акт на манипулиране на заявката за получаване на нежелани резултати е SQL инжекционна атака.

Какви щети могат да бъдат направени?

SQL инжекционната атака е причинена от небрежно и безотговорно кодиране на приложения и е напълно предотвратима (която ще обхванем в един момент), но степента на щетите, която може да се направи, зависи от настройката на базата данни. За да може уеб приложението да комуникира с базата данни на базата данни, приложението трябва да предостави вход в базата данни (имайте предвид, че това е различно от потребителското влизане в самия уеб сайт). В зависимост от това какви разрешения се изискват от уеб приложението, съответната сметка в базата данни може да изисква нещо от разрешението за четене / запис в съществуващите таблици само до пълен достъп до базата данни. Ако това не е ясно сега, няколко примера трябва да помогнат да се осигури известна яснота.

Въз основа на горния пример, можете да видите това, като въведете, например, "вашият потребител" - "," администратор "-" или друго потребителско име, можем незабавно да влезем в сайта като този потребител, без да знаем паролата. След като сме в системата, не знаем, че всъщност не сме този потребител, така че имаме пълен достъп до съответния акаунт. Разрешенията за базата данни няма да осигурят предпазна мрежа за това, тъй като обикновено уеб сайтът трябва да има достъп за четене / запис до съответната база данни.

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

За да илюстрираме щетите, които могат да бъдат направени в тази ситуация, ще използваме примера, представен в комикса по-горе, като въведем следното в полето за потребителско име: "Робърт"; Потребители на DROP TABLE; - ". След проста подмяна заявката за удостоверяване става:

SELECT Потребителски идентификатор от потребители WHERE UserName = "Робърт"; Потребители на DROP TABLE; - 'AND Password = "wrongpass"

Забележка: точка-точка е в SQL заявка, която се използва за обозначаване на края на определено изявление и началото на ново изявление.

Което се изпълнява от базата данни като:

SELECT Потребителски идентификатор от потребители WHERE Потребителско име = "Робърт"

Потребители на DROP TABLE

Така че просто използвахме SQLI атака, за да изтрием цялата таблица Users.

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

Предотвратяване на SQL инжекционна атака

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

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

Например, ако искате да търсите "O'neil" в база данни, не можете да използвате проста подмяна, тъй като единичният цитат след O ще доведе до преждевременно прекъсване на низ. Вместо това го дезинфекцирайте с помощта на аварийния символ на съответната база данни. Да предположим, че символът за бягство за един вграден единичен цитат е предварителен за всеки цитат със символ. Така че "O'neal" ще бъде дезинфектиран като "O \ t.

Този прост акт на саниране много пречи на SQLI атака. За да илюстрираме, нека да преразгледаме предишните си примери и да видим получените заявки, когато потребителският вход бъде дезинфекциран.

myuser "-- / wrongpass:

SELECT Потребителски идентификатор от потребители WHERE UserName = "myuser" - "И парола =" неправилно преминаване "

Тъй като единичният цитат след изтриване на myuser (което означава, че се счита за част от целевата стойност), базата данни ще търси буквално името UserName на "Myuser" - ". Освен това, тъй като тирета са включени в стойността на низовете, а не в самия SQL израз, те ще се считат за част от целевата стойност, вместо да се интерпретират като коментар за SQL.

Робърт "; Потребители на DROP TABLE;-- / wrongpass:

SELECT Потребителски идентификатор от потребители WHERE UserName = "Робърт"; Потребители на DROP TABLE; - 'AND Password = "wrongpass"

Като просто се измъкнем от единичния цитат след Робърт, и запетая и тирета се съдържат в низа за търсене на UserName, така че базата данни буквално да търси "Робърт"; Потребители на DROP TABLE; - " вместо да изпълни изтриването на таблицата.

В обобщение

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

Някои видове атаки, като DDoS, не могат лесно да бъдат избегнати, докато други, като SQLI, могат. Въпреки това, щетите, които могат да бъдат направени от тези видове атаки, могат да варират от неудобство до катастрофално в зависимост от взетите предпазни мерки.