New Vulnerability Detection
Attribute-Based Cross-Site Scripting is one of the hardest types of Cross-Site Scripting to find in an automated fashion. Today, no desktop scanner does a good job at this; most don't even attempt it because false-positives skyrocket – except for the WhiteHat Sentinel Service. Naturally.
WhiteHat Sentinel implemented our second-generation attribute injections last week. Many of you have seen new XSS attack vectors being pushed on your sites, and for quite a few it is a result of these tests. The example we most often push is sourcing in JavaScript via an injected STYLE tag (attack vector for Internet Explorer).
Attribute injection is when user-controlled data lands inside of an HTML tag, or specifically a value inside of an HTML tag, where notorious characters like “<” and “>” may not be required for XSS exploitation. For example:
HTTP GET request (not actual Sentinel test - this is an example for exploitation):
http://www.domain.site/search/partner/index.cfm?sessionid=12345678901
&hid=
%22+STYLE%3D%22background-image%3A+expression%28alert
%28%27Is_XSS_HERE%3F%29%29Will result in this example tag in the HTTP Response:
<* td>
<* a href="/index.cfm?sessionid=12345678901&hid="
" STYLE="background-image: expression(alert('Is_XSS_HERE?))">
<* img src="http://www.domain.site/images/topnav/logo.gif" width="274" height="83" border="0">
<* /a>
<* /td>
This is a perfect example of an XSS vulnerability in which the attacker wouldn't need HTML tags or meta characters like <>. All you need in this case is a double-quote, a colon, and some parenthetics to begin your attack. From here the exploit can be carried out in many ways (e.g.-malicious Javascript). The ability to detect these issues accurately will grow exponentially with the advanced conditional logic currently being implemented into the Sentinel Service.
WhiteHat Website Vulnerability Management Practice TipsQ. How do I stop an XSS attack that lands in an HTML tag?
A. For most attribute-based attacks to work, the attacker needs at least single or double-quotes. Double-quotes are what is most often needed – from what we see at WhiteHat. You could try escaping, removing, or substituting single and double-quotes on input.
Alternately you could encode any user-supplied data safely on output. This is the safest approach. Barring international-language sites – there are a minimum of four alternate encoding types for all Latin-ASCII code page characters: being Unicode, Decimal, Hexadecimal, and Named. This can jump to 18 variants for something as simple as double-quote, if you factor in international-language code pages.
Q. How do I encode my output safely?
A. If you encode double-quotes as their named-entity references, you will remove most of your attribute XSS issues. If you encode single-quotes using Decimal (works across the most browsers) or named-entity reference, this should solve the problem, as well (by breaking the initial escape sequence the attacker needs to take over the tag and begin scripting).
A nice reference page for more on entity-encoding values can be found here:
http://www.crosswinds-cadre.net/?page=character_entities Q. What is this Unicode craziness you speak of?
A. A great place to start is here:
http://www.joelonsoftware.com/articles/Unicode.html
~~~posted by~~~
Mr. Jeremiah Grossman
