This is English version of my Strictly social XSS article.
Earlier I’ve told about different classes of Cross-Site Scripting vulnerabilities, including about many classes created by me. Last time I’ve told about Cross-Application Scripting, and concerning classes created by me - about Cross-Language Scripting. And now I’ll tell you about another one type of XSS vulnerabilities. I’ve created this class already in September 2007 (though I’ve found such holes earlier) and at last came to writing of detailed article about it.
This is Strictly social XSS. Which I’ve announced already in 2007 and now would tell about it in detail. At 23.09.2007 I’ve found Cross-Site Scripting vulnerability in Mozilla and Firefox, which I’ve disclosed at beginning of October. Which I’ve referred to Strictly social XSS type. And since then I’ve many times used the term Strictly social XSS for such vulnerabilities, actively popularizing it.
If in September 2007 I’ve found possibility of this attack via gopher protocol, then at 9th of February 2008 I’ve found possibility of using of http, https and ftp protocols. Which I’ve wrote about in post Cross-Site Scripting with UTF-7 in Mozilla and Firefox. In all these cases the attack was conducted at visiting of special page with UTF-7 text (it could be as reflected, as persistent attack), where it was needed to force victim to set UTF-7 encoding in a browser (by choosing appropriate item in menu). Which could be done by using method of social engineering, as I showed on examples of XSS attacks for different protocols.
gopher:///1+ADw-SCRIPT+AD4-alert('XSS')+ADw-/SCRIPT+AD4-
gopher:///1Turn%20on%20UTF-7%20to%20view%20this%20message%20+ADw-SCRIPT+AD4-alert('XSS')+ADw-/SCRIPT+AD4-
Taking into account, that the attack could be conducted on any gopher, http, https and ftp resource (which showed UTF-7 text, set in URL, in the answer on the request), so it was universal Strictly social XSS vulnerability. Also I’ll note, that if in 2007 Mozilla ignored this vulnerability, then in autumn 2008 Mozilla silently fixed this vulnerability in Firefox 3.0.2.
Nuances of Strictly social XSS.
Main feature of Strictly social XSS vulnerabilities is that a user needs to make some actions (specific to individual browser or individual site). For example, click, mouse over, selecting of element on a page (input field, combobox or other element), or selecting of some item in menu of the browser (e.g. changing of codepage). I.e. this type of XSS vulnerabilities, comparing with others, more requires usage of the methods of social engineering.
Among browsers which had such holes there are Mozilla and Firefox, which I mentioned about earlier, and Internet Explorer via attack via protocol guessing in IE6. Among such holes at web sites there are specific for separate sites and such ones, which are widespread at many sites, and also such ones, which require usage of browser functionality (but at that the hole is specific for the site, not for the browser). E.g. vulnerability on craigslist.org, which I’ve found at 01.11.2007.
The hole on craigslist.org required for attack to force a user to select required item in menu in the browser (if Site Navigation Bar turned on, as it often happens). And if it was turned on at a user (Show Always or Show Only As Needed), then it was only needed to force a user to make a click in menu Site Navigation Bar in the browser. For executing of JavaScript code it was needed to select site’s RSS feed in Site Navigation Bar in menu More. Attack could work in the browsers, which supported Site Navigation Bar, such as Mozilla, Firefox and Opera.
Besides above-mentioned cases, also such vulnerabilities happen in plugins for the browsers, such as Flash (particularly in content for this plugin - flash-files). Which allows to conduct these attacks in all browsers, i.e. these vulnerabilities are cross-browser and can take place at any sites with vulnerable flash-files. About examples of such mass XSS I wrote in articles XSS vulnerabilities in 8 millions flash files and XSS vulnerabilities in 34 millions flash files. In all these cases there was needed to click on flash-content to execute JavaScript-code.
Events handlers.
There are such XSS vulnerabilities, which work via events handlers, particularly those ones, which work not automatically, but at some user actions. Such as on click, on hovering cursor or at other events (as events, which exist in HTML standard, as own events of browsers developers, which are supported only by browsers of these companies). Such vulnerabilities are known for a long time, long before creation by me of the class Strictly social XSS, and usually they were referred to reflected XSS vulnerabilities (and some developers even didn’t count them as XSS and didn’t fix them).
At creation of this class of XSS vulnerabilities I’ve added all such XSS via vents handlers to it. Because these vulnerabilities require additional actions of a user, which conform to the definition of Strictly social XSS. I.e. not only new holes, which I’ve found and mentioned in this article, I referred to this class, but also old XSS holes, which work at onClick, onMouseOver and other events. So such holes via events handlers should be referred to this class.
At that cases happen, when there is filtration at web site (built in the site or WAF) and it’s possible to use common reflected XSS, but it’s possible to use events handlers. It’s that case, when reflected XSS is changing to Strictly social XSS for filtration bypass. During many years I’ve many times used Strictly social XSS for bypassing WAF, including ModSecurity.
Types of Strictly social XSS.
There are the next types of Strictly social XSS:
- Strictly social XSS reflected.
- Strictly social XSS persistent.
- Strictly social XSS DOM based.
- Strictly social XSS local.
- Strictly social XSS reflected self-contained.
- Strictly social XSS persistent self-contained.
Strictly social XSS reflected.
Strictly social XSS reflected represent by itself a link with JavaScript/VBScript code.
Examples of such XSS are vulnerability on tinyurl.com, vulnerabilities in 8 millions flash banners and vulnerabilities in WP-Cumulus for WordPress and tens of ports of WP-Cumulus for different engines, which together are using at around 34000000 web sites.
Strictly social XSS persistent.
Strictly social XSS persistent represent by itself a link with JavaScript/VBScript code.
Example of such XSS is vulnerability on tinyurl.com and vulnerability in WordPress.
Strictly social XSS DOM based.
Strictly social XSS DOM based represent by itself an inclusion of JavaScript/VBScript code in event handler, such as click (onClick) or other event.
Examples of such XSS are vulnerabilities in Joomla and Joostina, on yandex.ru, images.yandex.ru and market.yandex.ru, afisha.yandex.ru and video.i.ua.
Strictly social XSS local.
Strictly social XSS local represent by itself such XSS in local application, particularly in browser. About such type I’ve wrote already in details in article Local XSS.
Examples of such XSS are vulnerabilities in Mozilla and Firefox, in Mozilla and Firefox via redirectors, in Internet Explorer 6, on search.yahoo.com and craigslist.org.
Strictly social XSS reflected self-contained.
Strictly social XSS reflected self-contained represent by itself a link with data with JavaScript code.
Example of such XSS is vulnerability on www.s-cars.org.
Strictly social XSS persistent self-contained.
Strictly social XSS persistent self-contained represent by itself a link with data with JavaScript code.
Examples of such XSS are vulnerabilities on tinyurl.com and vulnerability in WordPress.
Using of Strictly social XSS together with additional attack techniques.
Taking into account, that for execution of JS/VBS code at Strictly social XSS vulnerabilities the additional actions of a user are needed, it’s complicating the attack. For simplification of the attack, up to full automation (similar to reflected XSS), it’s possible to use additional attack techniques. Particularly such techniques as ClickJacking, MouseOverJacking and attack via clipboard.
If for the attack a victim needs to do a click, then it’s possible to use ClickJacking (made by Jeremiah and Robert).
If for the attack a victim needs to do mouse over, then it’s possible to use MouseOverJacking (made by me).
If for the attack a victim needs to paste a text from clipboard, then for this it’s needed at first to put attacking code into her clipboard, for that it’s possible to conduct attack via clipboard (made by me), for remote putting of a code into clipboard.
