Съществуват редица инструменти и техники, които тези групи използват и докато не се опитваме да ви дадем ръководство, за да го направите сами, е полезно да разберете какво се случва. Две от атаките, които постоянно чувате за тях, са "(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 injection" (SQLI) е експлойт, която се възползва от лошите техники за уеб програмиране и обикновено се комбинира с неправилна сигурност на базата данни. Резултатът от успешната атака може да варира от представяне на потребителски акаунт до пълен компромис със съответната база данни или сървър. За разлика от атака на DDoS, SQLI атаката е напълно и лесно предотвратима, ако уеб приложението е подходящо програмирано.
Изпълняване на атаката
Когато влизате в уеб сайт и въведете потребителското си име и парола, за да тествате данните си, уеб приложението може да изпълни заявка като следното:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
Забележка: Стойностите на низовете в SQL заявката трябва да бъдат приложени в единични кавички, поради което те се появяват около въведените от потребителя стойности.
Така че комбинацията от въведеното потребителско име (myuser) и паролата (mypass) трябва да съответства на запис в таблицата Users, за да се върне UserID. Ако няма съответствие, не се връща Потребителски номер, така че идентификационните данни за вход са невалидни. Докато определено изпълнение може да се различава, механиката е доста стандартна.
Така че сега нека разгледаме заявката за удостоверяване на шаблон, която можем да заменим стойностите, които потребителят въвежда в уеб формуляра:
SELECT UserID FROM Users WHERE UserName='[user]’ AND Password='[pass]’
На пръв поглед това може да изглежда като пряка и логична стъпка за лесно валидиране на потребителите, но ако в този шаблон се извърши просто заместване на въведените от потребителя стойности, то е податливо на SQLI атака.
Да предположим например, че в полето за потребителско име се въвежда "myuser", а в паролата се въвежда "wrongpass". Като използваме просто заместване в заявката ни за шаблон, ще получим следното:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Ключът към това твърдение е включването на двете тирета
(--)
Това е началното кодирано означение за SQL изрази, така че всичко, което се появява след двата тирета (включително), ще бъде пренебрегнато. По същество горната заявка се изпълнява от базата данни като:
SELECT UserID FROM Users WHERE UserName='myuser'
Очевидният пропуск тук е липсата на проверка на паролата.Като включихме двете тирета като част от потребителското поле, напълно прескочихме условието за проверка на паролата и можехме да се регистрираме като "myuser" без да знаем съответната парола. Този акт на манипулиране на заявката за генериране на нежелани резултати е SQL инжекция атака.
Какви щети може да се направи?
Атаката срещу инжектирането на SQL се дължи на небрежното и безотговорно кодиране на приложението и е напълно предотвратимо (което ще покрием в един момент), но размерът на щетите, които може да се направи, зависи от настройката на базата данни. За да може една уеб приложение да комуникира с базата данни на базата данни, приложението трябва да предостави данни за вход в базата данни (забележете, че това е различно от влизането на потребителя в самия уеб сайт). В зависимост от това какви разрешения изисква уеб приложението, тази съответна база данни може да изисква всичко от разрешението за четене / писане в съществуващите таблици само до пълния достъп до базата данни. Ако това не е ясно сега, няколко примера ще ви помогнат да осигурите яснота.
Въз основа на горния пример можете да видите, че като въведете, например,
'youruser'--', 'admin'--'
или всяко друго потребителско име, можем незабавно да влезем в сайта като този потребител без да знаем паролата. След като сме в системата, не знаем, че всъщност не сме този потребител, така че имаме пълен достъп до съответната сметка. Разрешенията за бази данни няма да осигурят защитна мрежа за това, защото обикновено уеб сайт трябва да има поне достъп за четене / писане в съответната си база данни.
Сега нека приемем, че уеб сайтът има пълен контрол над съответната база данни, което дава възможност за изтриване на записи, добавяне / премахване на таблици, добавяне на нови профили за защита и др. Важно е да отбележим, че някои уеб приложения може да се нуждаят от този тип разрешение не е автоматично лошо нещо, което дава пълен контрол.
За да илюстрираме вредите, които могат да се случат в тази ситуация, ще използваме примера, даден в комикса по-горе, като въведете следното в полето за потребителско име:
'Robert'; DROP TABLE Users;--'.
След просто заместване заявката за удостоверяване става:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Забележка: Точката на точка и запетая в SQL заявка се използва за означаване на края на конкретна операция и началото на нов отчет.
Което се изпълнява от базата данни като:
SELECT UserID FROM Users WHERE UserName='Robert'
ПОТРЕБИТЕЛНА ТАБЛИЦА Потребители
По този начин използвахме SQLI атака, за да изтрием цялата таблица на потребителите.
Разбира се, много по-лошо може да бъде направено, тъй като, в зависимост от позволените разрешения на SQL, атакуващият може да променя стойности, да премества таблици (или цялата самата база данни) в текстов файл, да създава нови акаунти за вход или да отвлича цялата инсталация на базата данни.
Предотвратяване на атака на SQL инжекция
Както споменахме няколко пъти по-рано, SQL атаката срещу инжектирането е лесно предотвратима. Едно от кардиналните правила за уеб програмиране никога не сте сляпо доверие потребителски вход, както направихме, когато направихме просто заместване в нашата заявка за шаблони по-горе.
Атака на SQLI лесно може да бъде заличена от това, което се нарича дезинфекциране (или избягване) на вашите входове. Процесът на дезинфекция е всъщност доста тривиален, тъй като всичко, което всъщност прави, е да се справя с всеки вграден единичен цитат (') знаци по подходящ начин, така че те да не могат да бъдат използвани за преждевременно прекратяване на низ в SQL израза.
Например, ако искате да търсите "O'neil" в база данни, не бихте могли да използвате просто заместване, защото единичната оферта след О ще доведе до преждевременно прекратяване на низа. Вместо това можете да го дезинфекцирате, като използвате съответния характер на бягството на съответната база данни. Да приемем, че евакуационният знак за вградения единичен цитат е предшестващ всеки цитат с символ. Така че "O'neal" ще бъде дезинфекциран като "O 'neil".
Този прост акт на саниране до голяма степен предотвратява атака на SQLI. За да илюстрираме, нека да прегледаме нашите предишни примери и да видим получените заявки, когато потребителският вход е дезинфекциран.
myuser'--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Тъй като единичната котировка след миозер е избягала (т.е. тя се счита за част от целевата стойност), базата данни буквално ще търси името на потребителя на
'myuser'--'.
Освен това, тъй като тиретата са включени в стойността на низа, а не в самия SQL израз, те ще се считат за част от целевата стойност, вместо да се интерпретират като SQL коментар.
Robert'; DROP TABLE Users;--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Чрез просто избягване на единичната оферта след Робърт, както точка и запетая, така и тиретата се съдържат в низа за търсене UserName, така че базата данни буквално ще търси
'Robert'; DROP TABLE Users;--'
вместо да изпълнява изтриването на таблицата.
В обобщение
Докато интернет атаките се развиват и стават по-сложни или се фокусират върху различна точка на влизане, е важно да се помни, че трябва да се предпазвате от изпитани и истински атаки, които са вдъхновение от няколко свободно достъпни "хакерски инструменти", предназначени да ги използват.
Някои видове атаки, като DDoS, не могат лесно да бъдат избегнати, докато други, като например SQLI, могат. Въпреки това, щетите, които могат да бъдат причинени от тези видове атаки, могат да варират от неудобство до катастрофално, в зависимост от предприетите предпазни мерки.
