XSS: да ти подпъхнат код

Cross-site Scripting – със сигурност помните добре това словосъчетание, ако сте станали жертва на такъв тип атака. Но ако не ви говори нищо, определено си струва да научите основните правила по темата. Независимо дали сте потребител, който трябва да знае за какво да внимава, собственик на сайт, който да осигури безопасна срещу XSS атаки страница. Или пък планирате да си направите сайт (в този случай можете да започнете напълно безплатно тук).

 

Хора и сайтове, скрипт като скрипт

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

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

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

И така, в какво се изразява една от най-честите атаки срещу сигурността онлайн? Нападателят се старае да изпълни свой скрипт в браузъра на жертвата, като „инжектира“ свой код в обичайна, уж безопасна уеб апликация.

Кодът на кода

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

Почти винаги този пробив става на места, където на потребителите е позволено да оставят свое съдържание – форуми, публикации с коментари. Идеята е именно чрез тези текстове тихомълком да се промъкне кодът на скрипта, който хакерът иска да се пусне на компютъра. Възможно е подобна атака да се получи дори чрез инжектиран CSS, но все пак най-често се използва JavaScript, тъй като той е основният език, на който се разчита за пускането на скриптове в браузъра.

Е добре, значи XSS атаката си е проблем на потребителя? Нищо подобно. Задачата на програмистите, които се грижат за всеки един сайт, е да не допуснат възможността скрипт, който може да бъде „запален“ от браузъра, да се появи сред коментарите или потребителските публикации.

 

Мий ръцете…

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

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

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

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

Воден пистолет

Добрата новина е, че потенциалните щети от тази атака са доста по-малки по мащаб от тези при доста по-зловредния братовчед SQL injection. Причината е, че браузърите също са подготвени за нея – обикновено те пускат JavaScript скриптовете в достатъчно безопасна среда, която няма как например да стигне до операционната система на компютъра (особено ако при избора на браузър не сте се насочили към нещо прекалено екзотично).

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

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

Тагни ме тук и тук

Разбира се, най-лесно е атакуващият скрипт да бъде „опакован“ в HTML тага… script type=“mce-no/type“. Но това наистина е първосигналното решение, което надали би могло да бъде пропуснато. Скриптовете могат да се появят и като атрибути в основния body таг, например:

span style=“font-weight: 400;“>body onload=alert(„XSS“)</span

А понякога да влязат дори в… снимка. Защото някои браузъри биха пуснали и скрипт, който се крие в тага img:

body background=“javascript:alert(„XSS“)“

 

Особено внимание би трябвало да имаме и към тага iframe, който позволява в страницата да бъде вградена друга страница – по този начин се появяват например публикациите от социални мрежи. Да, по принцип той би могъл да съдържа JavaScript, който обаче няма достъп до DOM дървото на основната страница. И все пак е възможно да се използва при друг тип атаки, включващи още едно оръжие.Отровна комбинация

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

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

Разказахме ви за социалното инженерство, показахме и обратната страна на „човешкия фактор“ – работата на „белите хакери“. Разгледахме технологии като VPN и IoT и опасностите, които носят. А като особен акцент открояваме чисто технологичните страни на най-честите атаки – след DoS и DDoS и SQL Injection, ето че дойде време и за Cross-site Scripting.

В битката за сигурността онлайн никога не бива да сте сами, защото спокойствието зависи и от качествения хостинг. А това е нещо, което ние знаем как да осигурим – опитайте безплатно тук! Останете сигурни!

<a href="https://www.zettahost.bg/author/georgik/" target="_self">Георги Караманев</a>

Георги Караманев

Георги е журналист, писател и Front-end програмист – част от екипа на ZETTAHOST.bg. Има повече от 15 години опит в подготвянето на публикации на технологична тематика за Списание 8, в. „24 часа“ и други медии. През 2019 г. и 2021 г. получи наградите в категория „Технологии и иновации“ от конкурса на Dir.bg за чиста журналистика Web Report.
Последвайте ни

Най-нови публикации:

ChatGPT: 6 ползи от изкуствения интелект за онлайн бизнеса

ChatGPT може да се превърне в тайното оръжие за вашия онлайн бизнес. От изготвянето на съдържание за сайта, през анализа на данни до съставянето на бизнес план, платформата предлага различни решения, а ние ви представихме 6 от основните ползи на изкуствения интелект.

Личен сайт безплатно!

Регистрирай се безплатно и си направи сайт още днес.

Безплатната хостинг услуга на ZETTAHOST.bg няма скрити такси и изисквания за ползване.

Безплатен хостинг

Pin It on Pinterest

Share This