Чак и ако сте само слабо пратили догађајегрупа хакера Анонимоус и ЛулзСец, вероватно сте чули за хаковање веб локација и услуга, попут злогласних Сонијевих хакова. Да ли сте се икад запитали како то раде?
Постоји низ алата и техника којиове групе користе, а иако вам не покушавамо дати приручник да то сами урадите, корисно је схватити шта се дешава. Два напада за која константно чујете о њима користећи се „(Дистрибутед) Порицање услуге“ (ДДоС) и „СКЛ Ињецтионс“ (СКЛИ). Ево како функционишу.
Имаге би ккцд
Одбијање напада напада
Шта је то?
„Одбијање услуге“ (понекад се назива иНапад „дистрибуираног ускраћивања услуге“ или ДДоС) догађа се када систем, у овом случају веб сервер, одједном прими толико захтева да се ресурси сервера преоптерећују, а систем се једноставно закључава и искључује. Циљ и резултат успешног ДДоС напада су веб локације на циљном серверу недоступне за легитимне захтеве саобраћаја.
Како то функционише?
Логистика ДДоС напада можда се најбоље може објаснити примером.
Замислите милион људи (нападача)заједно са циљем да омета пословање компаније Кс, уклањањем њиховог позивног центра. Нападачи се координирају тако да ће у уторак у 9 сати сви позвати телефонски број компаније Кс. Највероватније, телефонски систем компаније Кс неће моћи истовремено да поднесе милион позива, тако да ће нападачи све долазне линије повезати. Резултат тога је да легитимни позиви корисника (тј. Они који нису нападачи) не могу доћи јер је телефонски систем везан за руковање позивима нападача. Дакле, у суштини, компанија Кс потенцијално губи посао због тога што легитимни захтеви не могу да се пробију.
ДДоС напад на веб сервер функционише тачноисти начин. Будући да практично не постоји начин да сазнате какав је саобраћај прикупљен од легитимних захтева насупрот нападачима све док веб сервер не обради захтев, ова врста напада је обично врло ефикасна.
Извођење напада
Због природе „бруталне силе“ ДДоС напада,требате имати пуно рачунара који су координирани да нападају истовремено. Прегледајући пример нашег позивног центра, ово би захтевало да сви нападачи обоје знају да позову у 9 ујутру и да у ствари у то време позову. Иако ће овај принцип сигурно функционисати када се ради о нападу на веб сервер, постаје знатно лакше када се користе зомби рачунари, уместо стварних рачунара.
Као што вероватно знате, постоји пуно варијантизлонамерног софтвера и тројана који се, једном у систему, налазе у стању мировања и повремено "телефонирају" за упутства. Једно од ових упутстава могло би бити, на пример, слање поновљених захтева на веб сервер компаније Цомпани Кс у 9 сати. Тако једним ажурирањем матичне локације одговарајућег злонамјерног софтвера, један нападач може одмах да координира стотине хиљада компромитованих рачунара како би извео масиван ДДоС напад.
Лепота коришћења зомби рачунара није само у његовој ефикасности, већ иу анонимности јер нападач уопште не мора да користи свој рачунар да би извршио напад.
СКЛ ињекцијски напад
Шта је то?
Напад „СКЛ ињекције“ (СКЛИ) је експлоатацијакоја користи лоше технике веб за развој и обично у комбинацији са неисправном сигурношћу базе података. Резултат успешног напада може се кретати од лажног представљања корисничког налога до потпуног компромиса одговарајуће базе података или сервера. За разлику од ДДоС напада, СКЛИ напад је у потпуности и лако спречити ако је веб апликација одговарајуће програмирана.
Извођење напада
Кад год се пријавите на веб локацију и унесете своје корисничко име и лозинку, како би проверили своје веродостојности веб апликација може покренути упит на следећи начин:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
Напомена: стринг вриједности у СКЛ упиту морају бити затворене у појединачне наводнике, због чега се појављују око уписаних корисничких вриједности.
Дакле комбинација унесеног корисничког имена(миусер) и лозинка (мипасс) морају се подударати са уносом у табели Усерс како би се УсерИД могао вратити. Ако нема подударања, не враћа се УсерИД, тако да су вјеродајнице за пријаву неважеће. Иако се одређена примена може разликовати, механика је прилично стандардна.
Дакле, погледајмо упит провјере аутентичности шаблона којим можемо замијенити вриједности које корисник уноси у веб образац:
ОДАБЕРИТЕ УсерИД ОД корисника ГДЈЕ УсерНаме = '[корисник]' И Лозинка = '[пасс]'
На први поглед ово може изгледати каодиректан и логичан корак за лако провјеру корисника, међутим ако се на овом предлошку изврши једноставна замјена унесених вриједности корисника, подложан је СКЛИ нападу.
На пример, претпоставимо да је у поље корисничког имена унето „миусер´–“, а у лозинку „фалсепасс“. Помоћу једноставне замјене у нашем предлогу за предложак, добили бисмо ово:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Кључ ове изјаве је укључивање две цртице (--). Ово је почетни коментар за СКЛ изјаве, тако да ће се све што се појави након две цртице (укључиво) занемарити. У основи, горњи упит извршава база података као:
SELECT UserID FROM Users WHERE UserName='myuser'
Овде је јак пропуст недостатакпровера лозинке. Укључивањем две цртице као корисничког поља, у потпуности смо заобишли стање провере лозинке и могли смо се пријавити као „мојусер“, а да не знамо одговарајућу лозинку. Овај чин манипулације упитом да би се произвели ненамерни резултати је СКЛ ињекцијски напад.
Која штета се може учинити?
СКЛ ињекцијски напад је изазван непажњом инеодговорно је кодирање апликација и потпуно га је могуће спријечити (што ћемо покрити у трену), међутим обим штете која се може направити зависи од подешавања базе података. Да би веб апликација комуницирала са резервном базом података, апликација мора да достави пријаву у базу података (имајте на уму, ово је другачије од пријаве корисника на сам веб локацију). У зависности од дозвола које веб апликација захтева, овај одговарајући рачун базе података може захтевати било шта, од дозволе за читање / писање у постојећим табелама до потпуног приступа бази података. Ако то сада није јасно, неколико примјера требало би вам помоћи да пружите одређену јасноћу.
На основу горњег примера то можете видети уношењем, на пример, "youruser'--", "admin'--" или било које друго корисничко име, на које се можемо одмах пријавитивеб локацију као тог корисника без познавања лозинке. Једном када смо у систему не знамо да ми у ствари нисмо тај корисник, тако да имамо пуни приступ одговарајућем налогу. Дозволе базе података неће пружити сигурносну мрежу за то, јер обично веб локација мора имати приступ за читање / писање у своју базу података.
Претпоставимо да веб локација има потпуну контролу надодговарајућу базу података која омогућава брисање записа, додавање / уклањање табела, додавање нових безбедносних налога итд. Важно је напоменути да би неким веб апликацијама могла бити потребна оваква врста дозволе, тако да није аутоматски лоше што је потпуна контрола одобрено.
Дакле, да илуструјемо штету која се у овој ситуацији може направити, користићемо пример наведен у стрипу изнад уношењем следећег у поље корисничког имена: "Robert'; DROP TABLE Users;--". Након једноставне замјене, упит за провјеру аутентичности постаје:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Напомена: тачка под зарезом у СКЛ упиту користи се за означавање краја одређене изјаве и почетка нове изјаве.
Која се извршава у бази података као:
SELECT UserID FROM Users WHERE UserName='Robert'
ДРОП ТАБЛЕ Корисници
Управо тако, користили смо СКЛИ напад за брисање читаве табеле корисника.
Наравно, може се учинити и много горе, у зависностидозвољене СКЛ дозволе, нападач може да промени вредности, баци табеле (или целокупну базу података) у текстуалну датотеку, креира нове рачуне за пријаву или чак отме целу инсталацију базе података.
Спречавање напада СКЛ убризгавања
Као што смо претходно неколико пута поменули, СКЛнапад ињекцијама је лако спречити. Једно од кардиналних правила веб развоја је да никада не слепо верујете корисничком уносу као што смо то радили када смо извршили једноставну замену у горњем предлогу упита.
СКЛИ напад је лако спречити оним што јестекоја се зове санирање (или бекство) од уноса. Процес санирања је заправо прилично тривијалан, јер све што у основи ради јесте да на одговарајући начин поступа са било којим уграђеним једним цитатом (') знаковима тако да их се не може користити за преурањени прекид низа унутар СКЛ израза.
На примјер, ако желите потражити "О'неил" унутрабазе података, не бисте могли да користите једноставну замену, јер би један цитат након О прерано завршио низ. Уместо тога, санитарно га очистите коришћењем знака за бекство одговарајуће базе података. Претпоставимо да знак за бијег за унутарњи појединачни цитат претходи сваком цитату са симболом. Дакле, „О’неал“ би се санирао као „О'неил“.
Овај једноставан чин санитације прилично спречава СКЛИ напад. Ради илустрације, поново ћемо прегледати наше претходне примере и видети резултирајуће упите када је кориснички унос саниран.
myuser'-- / фалсепасс:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Будући да је појединачни цитат након избацивања миусера (што значи да се сматра дијелом циљане вриједности), база података ће дословно тражити УсерНаме од "myuser'--". Уз то, цртице су укључене у вриједност низа, а не у СКЛ израз, сматрат ће се дијелом циљне вриједности умјесто да се тумаче као СКЛ коментар.
Robert'; DROP TABLE Users;-- / фалсепасс:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Једноставним бијегом од јединственог цитата након Роберта, и тачка зарез и цртице налазе се у корисничком низу УсерНаме, тако да ће база података дословно тражити "Robert'; DROP TABLE Users;--" уместо извршавања табеле избришите.
Укратко
Док се веб напади развијају и постају вишесофистицирани или усредсређени на другачију тачку уласка, важно је запамтити да се заштитите од испробаних и истинских напада који су били инспирација неколико слободно доступних "хакерских алата" дизајнираних да их искористе.
Неке врсте напада, као што је ДДоС, не могу битилако се избегавају, док други, као што је СКЛИ, могу. Међутим, штета коју могу начинити ове врсте напада може варирати од неугодности до катастрофалних стања, зависно од предузетих мера предострожности.
