Проблем са веб апликацијама је у томе што су оне отворено изложене милијардама корисника интернета, од којих ће многи желети да пробију њене безбедносне мере – из било ког разлога.
У раним данима интернета, једна од најчешћих метода напада била је основна, једноставна груба сила. Ботови су обично изводили ове нападе – или особе са доста слободног времена – који су испробавали милионе комбинација корисничких имена и лозинки док нису пронашли ону која би омогућила приступ циљној апликацији.
Напади грубе силе више нису претња, захваљујући политици лозинки, ограниченим покушајима пријаве и цаптцха. Али сајбер криминалци воле да откривају нове подвиге и да их користе за нове врсте напада. Давно су открили да се текстуална поља у апликацијама или веб страницама могу искористити уношењем – или убризгавањем – неочекиваног текста у њих који би приморао апликацију да уради нешто што није требало да ради. На тај начин су на сцену ступили такозвани напади ињекцијама.
Ињекциони напади се могу користити не само за пријаву на апликацију без познавања корисничког имена и лозинке, већ и за откривање приватних, поверљивих или осетљивих информација, или чак за отмицу целог сервера. Због тога ови напади нису само претња веб апликацијама, већ и корисницима чији подаци се налазе на тим апликацијама, ау најгорем случају и другим повезаним апликацијама и сервисима.
Преглед садржаја
Ињекција кода
Ињекција кода је једна од најчешћих врста напада убризгавањем. Ако нападачи знају програмски језик, оквир, базу података или оперативни систем који користи веб апликација, могу да убаце код преко поља за унос текста како би натерали веб сервер да уради оно што желе.
Ове врсте напада убризгавањем су могући на апликације којима недостаје валидација улазних података. Ако поље за унос текста омогућава корисницима да унесу шта год желе, онда је апликација потенцијално искоришћена. Да би се спречили ови напади, апликација треба да ограничи колико год може да је корисницима дозвољен унос.
На пример, потребно је да ограничи количину очекиваних података, да провери формат података пре него што их прихвати и да ограничи скуп дозвољених знакова.
Рањивости убризгавања кода могу се лако пронаћи, само тестирањем уноса текста веб апликације са различитим типовима садржаја. Када се пронађу, рањивости је умерено тешко искористити. Али када нападач успе да искористи једну од ових рањивости, утицај може укључити губитак поверљивости, интегритета, доступности или функционалности апликације.
СКЛ ињекција
На сличан начин као код убризгавања, овај напад умеће СКЛ скрипту – језик који већина база података користи за обављање операција упита – у поље за унос текста. Скрипта се шаље апликацији, која је извршава директно у својој бази података. Као резултат тога, нападач би могао да прође кроз екран за пријаву или да уради опасније ствари, као што је читање осетљивих података директно из базе података, модификовање или уништавање података базе података или извршавање административних операција на бази података.
ПХП и АСП апликације су склоне нападима СКЛ ињекције због својих старијих функционалних интерфејса. Ј2ЕЕ и АСП.Нет апликације су обично заштићеније од ових напада. Када се пронађе рањивост СКЛ ињекције – а она се лако може пронаћи – величина потенцијалних напада биће ограничена само вештином и маштом нападача. Дакле, утицај СКЛ ињекције је несумњиво висок.
Командна ињекција
Ови напади су такође могући, углавном због недовољне валидације уноса. Они се разликују од напада убризгавањем кода по томе што нападач убацује системске команде уместо делова програмског кода или скрипти. Дакле, хакер не мора да зна програмски језик на коме је апликација заснована или језик који користи база података. Али они морају да знају оперативни систем који користи хостинг сервер.
Уметнуте системске команде извршава оперативни систем домаћина са привилегијама апликације, што би могло да омогући излагање садржаја произвољних фајлова који се налазе на серверу, за приказ структуре директоријума сервера, за промену корисничких лозинки, између осталог. .
Ове нападе може спречити системски администратор, ограничавањем нивоа приступа систему веб апликација које раде на серверу.
Скриптовање на више локација
Кад год апликација уметне унос од корисника у излаз који генерише, без провере ваљаности или кодирања, то даје прилику нападачу да пошаље злонамерни код другом крајњем кориснику. Напади скриптовања на више локација (КССС) користе ове могућности за убацивање злонамерних скрипти у поуздане веб локације, које се на крају шаљу другим корисницима апликације, који постају жртве нападача.
Прегледач жртве ће извршити злонамерну скрипту, а да не зна да јој не треба веровати. Према томе, претраживач ће му дозволити да приступи токенима сесије, колачићима или осетљивим информацијама које чува претраживач. Ако су правилно програмиране, скрипте би чак могле да препишу садржај ХТМЛ датотеке.
КССС напади се генерално могу поделити у две различите категорије: ускладиштене и рефлектоване.
У сачуваним КССС нападима, злонамерна скрипта се трајно налази на циљном серверу, у форуму за поруке, у бази података, у дневнику посетилаца, итд. Жртва је добија када њен претраживач затражи сачуване информације. У рефлектованим КССС нападима, злонамерна скрипта се одражава у одговору који укључује улаз послат серверу. Ово може бити порука о грешци или резултат претраге, на пример.
КСПатх ињекција
Овај тип напада је могућ када веб апликација користи информације које је корисник дао да направи КСПатх упит за КСМЛ податке. Начин на који ови напади функционишу је сличан СКЛ ињекцији: нападачи шаљу погрешне информације у апликацију како би сазнали како су КСМЛ подаци структурирани, а затим поново нападају да би приступили тим подацима.
КСПатх је стандардни језик са којим, попут СКЛ-а, можете одредити атрибуте које желите да пронађете. Да би извршиле упит над КСМЛ подацима, веб апликације користе кориснички унос да би поставиле образац са којим би подаци требало да се подударају. Слањем погрешно обликованог уноса, образац се може претворити у операцију коју нападач жели да примени на податке.
За разлику од онога што се дешава са СКЛ-ом, у КСПатх-у не постоје различите верзије. То значи да се КСПатх ињекција може извршити на било којој веб апликацији која користи КСМЛ податке, без обзира на имплементацију. То такође значи да се напад може аутоматизовати; стога, за разлику од СКЛ ињекције, има потенцијал да се активира против произвољног броја циљева.
Ињекција команде поште
Овај метод напада се може користити за искоришћавање сервера е-поште и апликација које граде ИМАП или СМТП изјаве са непрописно потврђеним корисничким уносом. Повремено, ИМАП и СМТП сервери немају јаку заштиту од напада, као што би то био случај са већином веб сервера, па би стога могли бити више експлоатисани. Улазећи преко сервера поште, нападачи би могли да избегну ограничења као што су цаптцхас, ограничен број захтева итд.
Да би искористили СМТП сервер, нападачима је потребан важећи налог е-поште за слање порука са убаченим командама. Ако је сервер рањив, он ће одговорити на захтеве нападача, дозвољавајући им, на пример, да заобиђу ограничења сервера и користе његове услуге за слање нежељене поште.
Убацивање ИМАП-а могло би се обавити углавном на апликацијама за веб пошту, искоришћавајући функционалност читања порука. У овим случајевима, напад се може извршити једноставним уношењем, у адресну траку веб претраживача, УРЛ са убаченим командама.
ЦРЛФ ињекција
Уметање знакова за повратак и повлачење реда – комбинација позната као ЦРЛФ – у поља за унос веб обрасца представља метод напада који се зове ЦРЛФ ињекција. Ови невидљиви знакови означавају крај реда или крај команде у многим традиционалним интернет протоколима, као што су ХТТП, МИМЕ или ННТП.
На пример, уметање ЦРЛФ-а у ХТТП захтев, праћено одређеним ХТМЛ кодом, могло би да пошаље прилагођене веб странице посетиоцима веб локације.
Овај напад се може извести на рањивим веб апликацијама које не примењују одговарајуће филтрирање на кориснички унос. Ова рањивост отвара врата другим врстама напада убризгавањем, као што су КССС и убризгавање кода, а такође може бити резултат отмице веб локације.
Ињекција заглавља домаћина
На серверима који хостују много веб локација или веб апликација, заглавље хоста постаје неопходно да би се одредило која од резидентних веб локација или веб апликација – свака од њих позната као виртуелни хост – треба да обради долазни захтев. Вредност заглавља говори серверу коме од виртуелних хостова да пошаље захтев. Када сервер прими неважеће заглавље хоста, обично га прослеђује првом виртуелном хосту на листи. Ово представља рањивост коју нападачи могу користити за слање произвољних заглавља хоста на први виртуелни хост на серверу.
Манипулација заглављем хоста се обично односи на ПХП апликације, иако се може урадити и са другим технологијама за развој веба. Напади заглавља хоста функционишу као покретачи за друге врсте напада, као што је тровање веб кеша. Његове последице могу укључити извршавање осетљивих операција од стране нападача, на пример, ресетовање лозинке.
ЛДАП ињекција
ЛДАП је протокол дизајниран да олакша претрагу ресурса (уређаја, датотека, других корисника) у мрежи. Веома је користан за интранет, а када се користи као део система за једнократну пријаву, може се користити за чување корисничких имена и лозинки. ЛДАП упити укључују употребу посебних контролних знакова који утичу на његову контролу. Нападачи могу потенцијално да промене планирано понашање ЛДАП упита ако могу да уметну контролне знакове у њега.
Опет, основни проблем који дозвољава нападе убризгавања ЛДАП-а је непрописно потврђен кориснички унос. Ако се текст који корисник шаље апликацији користи као део ЛДАП упита без дезинфекције, упит би на крају могао да преузме листу свих корисника и покаже је нападачу, само коришћењем звездице
на правом месту унутар улазног низа.
Спречавање напада убризгавањем
Као што смо видели у овом чланку, сви напади убризгавањем су усмерени на сервере и апликације са отвореним приступом сваком кориснику интернета. Одговорност за спречавање ових напада је распоређена међу програмерима апликација и администраторима сервера.
Програмери апликација треба да знају ризике који су укључени у нетачну валидацију корисничког уноса и да науче најбоље праксе за дезинфекцију уноса корисника у сврху превенције ризика. Администратори сервера морају периодично да ревидирају своје системе како би открили рањивости и исправили их што је пре могуће. Постоји много опција за обављање ових ревизија, било на захтев или аутоматски.