Архів для категорії 'Статті'

Проклята анімація з WWW

21:06 15.09.2009

Продовжуючи розпочату традицію, після попереднього відео про знаходження, експлуатацію та лікування XSS хробаків, пропоную новий відео секюріті мануал. Цього разу відео про прокляту анімацію з WWW. Рекомендую подивитися всім хто цікавиться цією темою.

Cursed Animations from the Wi1d W3st

В даному відео ролику демонструється процес атаки через e-mail з використанням ANI уразливості в Windows. Для розробки експлоіта використовується Metasploit Framework. Рекомендую подивитися дане відео для розуміння векторів атак з використанням ANI уразливості.

Redirectors: the phantom menace

22:47 12.09.2009

This is English version of my Redirectors: the phantom menace article.

There is such security problem in Internet as redirectors. Already at beginning of January 2008 I planned to write the article about different variants of attacks with using of redirectors. And now I present for you the article “Redirectors: the phantom menace”. It’s anthology of attacks with using of redirectors.

Attacks via redirectors.

Besides redirection to malicious and phishing sites, redirectors can be used for other attacks. Here is a list of all attacks via redirectors which I know:

  • Redirection.
  • HTTP Response Splitting and XSS (via HTTP Response Splitting) attacks.
  • Full path disclosure attacks.
  • Bypass of spam-filters.
  • Bypass of flash restrictions.
  • XSS attack via jar: URI in Firefox.
  • Attack on Google Toolbar.
  • CSRF attacks on a site.
  • Hidden attacks on other sites.
  • Image leakage in Firefox.
  • Denial of Service attacks.
  • Cross-Site Scripting attacks.

Redirection.

Standard attack with using of redirectors - it’s redirection to other sites for the purpose of infecting with viruses, conducting of phishing attacks, or just entice to the site of advertiser.

For these purposes numerous redirectors in Internet can be used, particularly in search engines (which I wrote about in MOSEB project), at popular sites (and other sites), in CMS and other web applications.

HTTP Response Splitting and XSS (via HTTP Response Splitting) attacks.

There can be HTTP Response Splitting vulnerabilities in web applications redirectors. Which can be used for conducting of HTTP Response Splitting and XSS (via HTTP Response Splitting) attacks. The protection from these attacks was made in last 4.x versions and 5.x versions of PHP. But PHP is using not at all sites, and there are not always last versions where it’s using, besides after fixing of this hole, developers of PHP added Full path disclosure hole.

Full path disclosure attacks.

If using at the site of last 4.x versions or 5.x versions of PHP, there is Full path disclosure vulnerability in PHP-redirectors.

Set “%0A1″ as URL of the site for this redirector and you’ll get the message “Warning: Header may not contain more than a single header, new line detected.” together with full path at the site.

http://site/redirector.php?url=%0A1

Bypass of spam-filters.

Redirectors can be used for bypass of spam-filters in e-mail. When spam-filters is set on appropriate URL of sites, then using of redirectors allows to bypass it. If filter is looking not on full URL, but on entering of string in site’s address, then it can be bypassed with help of redirection services (such as TinyURL and others).

Bypass of flash restrictions.

Bypass of flash restrictions on crossdomain access is possible via substitution of crossdomain policies (crossdomain.xml) with using of redirectors (which Stefan Esser wrote about). It can be used for conducting of Cross-Site Request Forgery attacks. These attacks (crossdomain) are possible in old versions of flash plugin.

XSS attack via jar: URI in Firefox.

In Mozilla Firefox the Cross-Site Scripting attacks are possible via jar: URI. Petko D. Petkov aka PDP found this vulnerability, and Beford found, that in Firefox it’s possible to use it together with redirectors for conducting of XSS attacks via jar: URI, without need to upload files on these sites. Vulnerability was fixed in Firefox 2.0.0.10 and SeaMonkey 1.1.7.

Attack on Google Toolbar.

As showed Aviv Raff, who found this vulnerability, in Google Toolbar it’s possible to spoof content of dialog window at adding of the button (with using of redirector). Vulnerable to Google Toolbar Dialog Spoofing Vulnerability are Google Toolbar 5 beta and previous versions.

CSRF attacks on a site.

Redirectors can be used for the purpose of conducting of CSRF attacks, when it’s needed to bypass checking of the referrer (as protection against CSRF), in order to make referrer from the same site.

Hidden attacks on other sites.

Redirectors can be used for conducting of attacks (particularly CSRF attacks) on other sites, for the purpose of hiding real attacking site, so as to mention quite another site in the logs.

Image leakage in Firefox.

Using of getImageData() together with redirection it’s possible to get cross-site access to images. Chris Evans found this vulnerability in Firefox. It was fixed in Firefox 2.0.0.18.

Denial of Service attacks.

Redirectors can be used for conducting of DoS attacks. There are possible two variants: redirector looped on itself (Looped DoS) and redirector looped on redirector (looped redirection attack).

About first variant of attack I wrote concerning vulnerabilities in Power Phlogger (and also I found these vulnerabilities on different sites), and about second variant of attack I wrote in detail in my articles Redirectors’ hell and Hellfire for redirectors.

Cross-Site Scripting attacks.

It’s possible to conduct XSS attacks via redirectors. For these purposes as refresh-header, as location-header redirectors can be used. Which I wrote about in detail in article Cross-Site Scripting attacks via redirectors.

There are next vulnerable browsers: Mozilla 1.7.x, Mozilla Firefox 3.0.x and 3.5.x (and Firefox 3.6 Alpha and 3.7 Alpha), Internet Explorer 6, Opera 9.x and 10.x, Google Chrome 1.x, 2.x and 3.x, QtWeb 3.0, Safari 4.0.x, SeaMonkey 1.1.x, Orca Browser 1.2 and Maxthon 3 Alpha (and in most cases previous versions of all mentioned browsers).

Conclusions.

Redirectors represent a danger to security of users of Internet. So owners of web sites, which have redirectors (open) on them, and also developers of browsers (when attack occurs because of a problem in browser), must not allow such vulnerabilities, and hard fixing already existent ones.

Редиректори: прихована загроза

22:44 11.09.2009

Існує така проблема безпеки в Інтернеті як редиректори. Ще на початку січня 2008 року я запланував написати статтю про різноманітні варіанти атак з використанням редиректорів. І зараз пропоную вашій увазі статтю “Редиректори: прихована загроза” (Redirectors: the phantom menace). Це антологія атак з використанням редиректорів.

Атаки через редиректори.

Окрім редирекції на зловмисні та фішинг сайти, редиректори можуть використовуватися для інших атак. Ось перелік усіх відомих мені атак через редиректори:

  • Редирекція.
  • HTTP Response Splitting та XSS (через HTTP Response Splitting) атаки.
  • Full path disclosure атаки.
  • Обхід спам-фільтрів.
  • Обхід обмежень флеша.
  • XSS атака через jar: URI в Firefox.
  • Атака на Google Toolbar.
  • CSRF атаки на сайт.
  • Приховані атаки на інші сайти.
  • Витік умісту зображень в Firefox.
  • Denial of Service атаки.
  • Cross-Site Scripting атаки.

Редирекція.

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

Для цього можуть використовуватися численні редиректори в Інтернеті, зокрема в пошукових системах (про що я писав в проекті MOSEB), на популярних сайтах (й інших сайтах), в CMS та інших веб додатках.

HTTP Response Splitting та XSS (через HTTP Response Splitting) атаки.

В веб додатках редиректорах можуть бути HTTP Response Splitting уразливості. Які можуть бути використанні для проведення HTTP Response Splitting та XSS (через HTTP Response Splitting) атак. В PHP в останніх 4.x версіях та в 5.x версіях зроблений захист від даних атак. Але не на всіх сайтах використовується PHP, а там де використовується, не завжди останні версії, до того ж виправивши дану дірку, розробники PHP додали Full path disclosure дірку.

Full path disclosure атаки.

При використанні на сайті PHP останніх 4.x версій або 5.x версій, в PHP-редиректорах наявна Full path disclosure уразливість.

Задайте “%0A1″ в якості URL сайта для даного редиректора і отримаєте повідомлення “Warning: Header may not contain more than a single header, new line detected.” разом з full path на сайті.

http://site/redirector.php?url=%0A1

Обхід спам-фільтрів.

Редиректори можуть використовуватися для обходу спам-фільтрів в пошті. Коли спам-фільтри налаштовані на відповідні URL сайтів, то використання редиректорів дозволить обійти їх. Якщо фільтр шукає не по повному URL, а по входженню рядка в адресу сайта, то його можна обійти за допомогою сервісів редирекції (таких як TinyURL та інших).

Обхід обмежень флеша.

Можливий обхід обмежень флеша на міжсайтовий доступ через підстановку міждоменних політик (crossdomain.xml) за допомогою використання редиректорів (про що писав Stefan Esser). Це може використовуватися для проведення Cross-Site Request Forgery атак. Дані атаки (міждоменні) можливі в старих версіях флеш плагіна.

XSS атака через jar: URI в Firefox.

В Mozilla Firefox можливі атаки міжсайтового скриптінга через jar: URI. Дану уразливість виявив Petko D. Petkov aka PDP, а Beford виявив, що в Firefox можна використати її разом з редиректорами для проведення XSS атак через jar: URI без необхідності завантаження файлів на дані сайти. Уразливість виправлена в Firefox 2.0.0.10 та SeaMonkey 1.1.7.

Атака на Google Toolbar.

Як продемонстрував Aviv Raff, який знайшов дану уразливість, в Google Toolbar можна підмінити зміст діалогового вікна при додаванні кнопки (з використанням редиректора). До Google Toolbar Dialog Spoofing Vulnerability вразливі Google Toolbar 5 beta та попередні версії.

CSRF атаки на сайт.

Редиректори можуть використовуватися з метою проведення CSRF атак, коли потрібно обійти перевірку на реферер (як захист проти CSRF), щоб реферер був з цього самого сайта.

Приховані атаки на інші сайти.

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

Витік умісту зображень в Firefox.

Використовуючи getImageData() разом з редирекцією можливо одержати міжсайтовий доступ до зображень. Дану уразливість в Firefox знайшов Chris Evans. Вона виправлена в Firefox 2.0.0.18.

Denial of Service атаки.

Можна використовувати редиректори для проведення DoS атак. Можливі два варіанти: редиректор зациклений на собі (Looped DoS) та редиректор зациклений на редиректорі (атаки зацикленою редирекцією - looped redirection attack).

Про перший варіант атаки я писав стосовно уразливостей в Power Phlogger (а також я знаходив дані уразливості на різних сайтах), а про других варіант атаки я детально писав в своїх статтях Пекло редиректорів та Пекельний вогонь для редиректорів.

Cross-Site Scripting атаки.

Через редиректори можна проводити XSS атаки. Для цього можуть бути використані як refresh-header, так і location-header редиректори. Про що я детально написав в статті Cross-Site Scripting атаки через редиректори.

До уразливих браузерів відносяться: Mozilla 1.7.x, Mozilla Firefox 3.0.x та 3.5.x (та Firefox 3.6 Alpha і 3.7 Alpha), Internet Explorer 6, Opera 9.x та 10.x, Google Chrome 1.x, 2.x та 3.x, QtWeb 3.0, Safari 4.0.x, SeaMonkey 1.1.x, Orca Browser 1.2 та Maxthon 3 Alpha (та в більшості випадків попередні версії усіх зазначених браузерів).

Висновки.

Редиректори становлять загрозу безпеці користувачів Інтернет. Тому власники веб сайтів, на яких є редиректори (відкриті), а також розробники браузерів (коли атака відбувається через проблему в браузері), повинні не допускати подібних уразливостей, і наполегливо виправляти вже існуючі.

XSS уразливості на 404 сторінках

22:47 05.09.2009

Cross-Site Scripting (XSS) уразливості дуже поширені в Інтернеті, що добре видно з моїх новин. Я регулярно знаходжу подібні уразливості на веб сайтах, про що пишу в себе на сайті, а також згадую про знайдені іншими секюріті дослідниками XSS дірки на відомих сайтах. Також я не раз писав про XSS хробаків.

XSS уразливості мені доводилося знаходити у різних веб додатках, а також у браузерах та веб серверах. Після уразливостей в пошуковцях, про що я вже писав детально в своєму проекті MOSEB, одними з найбільш поширених є XSS на Error 404 сторінках, про що я розповім детально.

Стандартний вектор атаки у випадку XSS на 404 сторінках - це вказання XSS-коду в якості адреси сторінки на сайті, що призведе до виведення 404-ї сторінки і до виконання JavaScript коду.

XSS:

http://site/%3Cscript%3Ealert(document.cookie)%3C/script%3E

Подібні XSS бувають reflected, persistent, DOM based та strictly social.

Прикладом persistent XSS на 404 сторінці є уразливість в Power Phlogger (код спрацює при перегляді логів відвідувань). DOM based XSS мені також траплялися, зокрема в компоненті ProofReader для Joomla. А reflected XSS на 404 сторінках - це найбільш поширений випадок. Прикладами даних XSS є уразливості на mts.com.ua, в Apache Tomcat та в Joomla.

А також уразливості в браузерах, що проявляються на 404 сторінках: Cross-Site Scripting з використанням UTF-7 в IE (reflected) та Cross-Site Scripting з UTF-7 в Mozilla та Firefox (strictly social XSS).

Так що розробникам веб серверів, браузерів та веб сайтів варто завжди перевіряти свої розробки на наявність XSS уразливостей на 404 сторінках (як і на усіх інших сторінках про помилки). Щоб не допускати уразливостей на даних сторінках.

Опис Cross-Site Scripting від CERT

22:47 03.09.2009

В своій статті CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests CERT розповідає про Cross-Site Scripting (XSS). Стаття датована 02.02.2000 - це перша документована згадка про такий вид уразливостей, як XSS. В тому числі в тексті використаний термін “Cross-Site Scripting” для позначення атак з включенням html-тегів в сторінки сайтів.

В статті йдеться про reflected XSS. Зазначу, що про persistent XSS було відомо ще в 1998, про що в Мережі є публікації за той час. Просто лише з появою reflected XSS (на початку 2000 року), почали вживати сам термін XSS, а до цього persistent XSS уразливості просто називали “ін’єкціями скриптів”.

В даній статті подається опис Cross-Site Scripting уразливостей, їх вплив та рекомендації по їх усуненню.

Знаходження, експлуатація та лікування XSS хробаків

19:27 29.08.2009

Продовжуючи розпочату традицію, після попереднього відео про захоплення SQL сервера через SQL ін’єкцію, пропоную новий відео секюріті мануал. Цього разу відео про знаходження, експлуатацію та лікування XSS хробаків. Рекомендую подивитися всім хто цікавиться цією темою.

Find, Exploit & Cure XSS w0rms

В даному відео ролику демонструється процес знаходження та експлуатації XSS уразливостей для разповсюдження XSS хробаків (на прикладі meebo.com), а також даються поради по їх лікуванню. Рекомендую подивитися дане відео для розуміння векторів Cross-Site Scripting атак.

Захоплення SQL сервера через SQL ін’єкцію

22:48 22.08.2009

Продовжуючи розпочату традицію, після попереднього відео про використання MSFweb 3.0, пропоную новий відео секюріті мануал. Цього разу відео про захоплення SQL сервера через SQL ін’єкцію. Рекомендую подивитися всім хто цікавиться цією темою.

Rooting SQL Server via SQL Injection

В даному відео ролику демонструється взлом SQL сервера. Через уразливий веб сайт, що має SQL ін’єкцію, на якому SQL Server запущений з адмінськими правами, створюється новий акаунт адміністратора. Рекомендую подивитися дане відео для розуміння векторів SQL Injection атак.

Закриття сайтів через їх взлом

22:42 15.08.2009

Раніше я писав про можливість закриття сайтів через їх уразливості. Це можливо в зв’язку з наявністю на сайті порнографії, секретних матеріалів, або терористичних матеріалів. І як я вже казав, закриття сайта може статися через його взлом та розміщення на ньому вищезазначених метеріалів.

Ще однією причиною закриття сайта може стати безпосередньо його взлом. Тобто, якщо у перших трьох випадках (порнографія, секретні та терористичні матеріали) ваш сайт закриють силові органи через порушення вами кримінального кодексу, то в цьому випадку сайт буде закритий через дії кіберзлочинців.

Тобто вже сам взлом може призвести до закриття сайта (це може бути дефейс і/або розміщення вірусів). Закриття може бути тимчасове - коли провайдер закрив сайт, доки його власник не почистить свій сайт, або повне - коли власник сайта закрив свій проект (бо не міг впоратися з проблемою дірявості власного сайта). В своїх дослідженнях безпеки Уанету (за 2006-2009 роки) я наводив безліч таких випадків. Як останній випадок з www.virtlibrary.dp.ua, так і минулорічні випадки з dn.kiev.ua та wmast.com.ua.

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

Основи хакінга

22:40 08.08.2009

В своїй презентації The fundamentals of Hacking, Jen Johnson та Miria Grunick розповідають про основи хакінга в Інтернеті.

Cross-Site Scripting attacks via redirectors

21:44 04.08.2009

This is English version of my Cross-Site Scripting attacks via redirectors article.

In this article I’ll tell you about using of redirectors in different browsers for conducting of Cross-Site Scripting attacks. Which can be conduct for the purpose of stealing cookies, or access to web site’s pages for making of various advanced attacks (in case when there is connection between code which is executed via redirector and the site), and also for the purpose of conducting of fishing attacks and execution of JavaScript code (in case when there is no such connection).

Besides that redirectors allow to redirect to malicious and fishing sites (which is Redirector vulnerability), there are also other variants of attacks with their use. Particularly in my articles Redirectors’ hell and Hellfire for redirectors I wrote about using of redirectors for DoS attacks. Already in January 2008 I planned to write an article about various attacks with using of redirectors (was planning to make anthology of attacks via redirectors), which I’d certainly do, but now I’d tell about one of this attacks - about XSS attacks via redirectors.

There are two types of redirectors (server-side): location-header, which works via Location header, and refresh-header, which works via Refresh header.

In different browsers (via vulnerabilities in them) XSS attacks are possible in different redirectors. Attacks are doing via redirection to javascript: URI and data: URI.

Attack #1

As I wrote about Cross-Site Scripting vulnerabilities in Mozilla, Internet Explorer, Opera and Chrome, in browsers Mozilla 1.7.x (and previous versions), Mozilla Firefox 3.0.8 (and previous versions), Internet Explorer 6 (and previous versions, but not IE7 and IE8), Opera 9.52 (and previous and next versions) and Google Chrome 1.0.154.48 (and previous and next versions) is possible XSS attack via refresh-header redirectors. Attack is doing by redirecting to javascript: URI.

Method of attack:

With request to script at web site:
http://site/script.php?param=javascript:alert(document.cookie)
Which returns in answer the Refresh header:
Refresh: 0; URL=javascript:alert(document.cookie)
The code will execute in context of this site.

This vulnerability in browsers can be used for conducting of reflected XSS attacks.

Attack #2

As I wrote about Cross-Site Scripting vulnerabilities in Mozilla, Firefox and Chrome, in browsers Mozilla 1.7.x (and previous versions), Mozilla Firefox 3.0.12 (and previous and next versions) and Google Chrome 1.0.154.48 (and previous and next versions) is possible XSS attack via refresh-header redirectors. Attack is doing by redirecting to data: URI (with or without using of base64).

Method of attack:

With request to script at web site:
http://site/script.php?param=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2b
Which returns in answer the refresh header and the code will execute in the browser:
refresh: 0; URL=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2b

Because in browsers Firefox 3.0.12 and Google Chrome the code is executing not in context of this site, hence there is no access to cookies, but it can be done in old Mozilla. This vulnerability in browsers (modern) can be used for conducting of fishing attacks and executing of JavaScript code.

Attack #3

As I wrote about Cross-Site Scripting vulnerabilities in Firefox and Opera, in browsers Mozilla Firefox 3.0.12 (and previous and next versions) and Opera 9.52 (and previous and next versions) is possible XSS attack via location-header redirectors. Attack is doing by redirecting to data: URI (with or without using of base64).

Method of attack:

With request to script at web site:
http://site/script.php?param=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2b
Which returns in answer the Location header and the code will execute in the browser:
Location: data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ+

Because in browsers Firefox and Opera the code is executing not in context of this site, hence there is no access to cookies. This vulnerability in browsers can be used for conducting of fishing attacks and executing of JavaScript code.

Both types of redirectors, location-header and refresh-header, very widespread in Internet, but most widespread are location-header redirectors. So existence of vulnerabilities which work via location-header redirectors pose the most threat. Particularly via this vulnerability in browsers are possible attacks via redirection services, as I wrote concerning vulnerability at tinyurl.com. It allows to spread malware via redirection services, when there will be set the code of exploit instead of address for redirection.

Attack #4

All modern browsers don’t allow execution of JavaScript code by redirecting to javascript: URI in location-header redirectors. But as showed my researches - it’s not always so. As I wrote about Cross-Site Scripting vulnerabilities in Mozilla and Firefox, in browsers Mozilla 1.7.x (and previous versions) and Mozilla Firefox 3.0.12 (and previous and next versions) is possible XSS attack via location-header redirectors, which use answer “302 Object moved”. Attack is doing by redirecting to javascript: URI (and also it’s possible to conduct attack to data: URI).

Method of attack:

With request to script at web site:
http://site/script.php?param=javascript:alert(document.cookie)
Which returns in answer the Location header:
HTTP/1.x 302 Object moved
Location: javascript:alert%28document.cookie%29

The browser will show “Object Moved” page. At click on the link “here” the code will execute in context of this site.

This vulnerability in browsers can be used for conducting of Strictly social XSS attacks.

Attack #5

After initial publication of the article, Aung Khant informed me at 24.08.2009 about vulnerability in Maxthon 3 Alpha (3.0.0.145) with Ultramode. Which allows execution of JavaScript code by redirecting to javascript: URI in location-header redirectors. It’s variation of attack #4 (which I checked, but not found in other browsers, but he found it in Maxthon). If in that case XSS attack is possible via location-header redirectors, which use answer “302 Object moved”, then in this case attack is possible with any 301 and 302 answers of redirectors. Attack is doing by redirecting to javascript: URI.

Method of attack:

With request to script at web site:
http://site/script.php?param=javascript:alert(document.cookie)
Which returns in answer the Location header:
Location: javascript:alert%28document.cookie%29
The browser will show “Unable to connect to the site” page. At click on the link “Refresh the page” the code will execute. Besides, there is the same behaviour in Maxthon 3 Alpha in attacks #3,4,5 (code executes not in context of the site).

This vulnerability in Maxthon can be used for conducting of Strictly social XSS attacks.

Note, that in case of execution of JavaScript code by redirecting to data: URI, when code is executing not in context of this site, the danger exists. Because this vulnerabilities can be used for conducting of fishing attacks and executing of JavaScript code (for malware spreading).

Main advantages of this attack method for criminals, in comparison with ordinary redirection to their site, is first that they don’t need even to have their site (so it’ll be harder to trace them, and also it’ll be impossible to close their site). And second that none anti-fishing and anti-malware filter (in browsers and email) will can’t filter out them, because there will no such address in their base (because not http: address, but data: is using), i.e. bypass of all filters is possible. So it’s needed to fix all mentioned vulnerabilities in browsers.

Attack #6

As I wrote about Cross-Site Scripting vulnerability in Mozilla, Firefox and other browsers, in browsers Mozilla 1.7.x (and previous versions) and Mozilla Firefox 3.0.19 (and previous and next versions) and potentially in other browsers is possible XSS attack via location-header redirectors, which use answer “302 Found”. Attack is doing by redirecting to javascript: URI (and also it’s possible to conduct attack to data: URI). This attack is similar to attack #4.

Method of attack:

With request to script at web site:
http://site/script.php?param=javascript:alert(document.cookie)
Which returns in answer the Location header:
HTTP/1.x 302 Found
Location: javascript:alert(document.cookie)

The browser will show “Found” page. At click on the link “here” the code will execute in context of this site.

This vulnerability in browsers can be used for conducting of Strictly social XSS attacks.

Attacks #7,8

In article Cross-Site Scripting via redirectors 301 and 303 in different browsers I’ve described two more attacks via redirectors with status 301 and 303. These are attacks via data: and javascript: URI.

[Update: 05.08.2009]

As I checked, Mozilla Firefox 3.0.13 is also vulnerable to attacks #2,3,4.

In case of all browsers which are vulnerable to attacks #1,4, JS code executes in context of the site.

[Update: 22.08.2009]

As I found with help of Aung Khant from YEHG Team, the next browsers are also vulnerable:

Google Chrome 2.0.172.28, 2.0.172.37 and 3.0.193.2 Beta - vulnerable to attacks #1,2.

QtWeb 3.0 Build 001 and 3.0 Build 003 - vulnerable to attacks #1,2,3.

Safari 4.0.3 - vulnerable to attacks #1,2.

Opera 10.00 Beta 3 Build 1699 - vulnerable to attacks #1,3.

SeaMonkey 1.1.17 - vulnerable to attacks #1,2,4 and in #1,2,4 JS code executes in context of the site.

[Update: 25.08.2009]

New information from Aung Khant from YEHG Team:

Firefox 3.6 a1 pre - vulnerable to attacks #1,2,3,4 and in #1,2,4 JS code executes in context of the site.

Firefox 3.7 a1 pre - vulnerable to attacks #2,3,4.

Orca Browser 1.2 build 5 - vulnerable to attacks #2,3,4.

Maxthon 3 Alpha (3.0.0.145 and 3.0.2.2) with Ultramode (Apple’s WebKit emulation) - vulnerable to attacks #1,2. And also vulnerable to attacks #3,4,5 as Strictly social XSS.

[Update: 05.08.2010]

Added information about attack #6.

[Update: 07.08.2010]

New information:

Mozilla Firefox 3.0.19 - vulnerable to attacks #2,3,4,6 and in #4,6 JS code executes in context of the site.

Firefox 3.5.11 - vulnerable to attacks #2,3,4,6 and in #4,6 JS code executes in context of the site.

Firefox 3.6.8 - vulnerable to attacks #2,3,4,6 and in #4,6 JS code executes in context of the site.

Firefox 4.0b2 - vulnerable to attacks #2,3,4,6 and in #4,6 JS code executes in context of the site.

Opera 10.53 - vulnerable to attacks #1,4,5,6.

[Update: 16.09.2012]

New information:

Firefox 3.5.19, Firefox 3.6.28 - vulnerable to attacks #2,3,4,6 and in #4,6 JS code executes in context of the site.

Firefox 10.0.7, Firefox 15.0.1 - vulnerable to attacks #2,3. In versions Firefox 10.0.7 and 15.0.1 the attacks #4,6 are no more possible - these vulnerabilities were hiddenly fixed by Mozilla in Firefox 9.0.

Opera 10.62 - vulnerable to attacks #1,4,5,6.

[Update: 25.09.2012]

Added information about attacks #7 and #8.