A couple of weeks ago I posted sections from one of our WhiteHat customer newsletters that focused HTTP Response Splitting. Newsletters are one way we keep customers informed of important industry trends and improvements to the Sentinel Service. Judging from the blog traffic and comments it was well received. So this time I’ll highlight Attribute-Based Cross-Site Scripting, which Arian Evans (WhiteHat’s Director of Operations) has been spending a lot of R&D time to get working properly. Enjoy.
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.
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):
Will result in this example tag in the HTTP Response:
<* 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">
WhiteHat Website Vulnerability Management Practice Tips
Q. 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:
Q. What is this Unicode craziness you speak of?
A. A great place to start is here: