While the issues in this space don’t tend to rank highly “on a scale of one to l33t,” I found it to be an interesting area because existing design practices appear inconsistent and suboptimal with regard to security.

As social networking platforms are changing very rapidly, the specific examples in this write-up will become dated quickly, if that isn’t already the case.  I'm more hopeful that the enumeration of issue types as well as the conclusions / recommendations in this write-up will stay relevant in the future.

Hyperlink Spoofing and the Modern Web

The XSS Filter’s approach has always relied on taking great care not to neuter characters which can alter context.  For example, if we were to neuter a double quote, that could have the unintended side-effect of activating script otherwise safely contained within a javascript string in some other part of the page.  The bug addressed by MS10-002 was not quite as obvious, but along the same lines.

Neutering is an attempt to cleverly target XSS as it may manifest on a given page.  But one thing that often goes unnoticed is that the XSS Filter is actually empowered to take various different approaches to mitigate XSS.  And it can do this on a per-heuristic basis.  In other words, given any identified issue with the neutering approach for a heuristic, we are able to choose from various different possible mitigations (Eg: mode=block), specifically applied for that heuristic.  In that way it is possible to disable attacks with a larger hammer as necessary, without forcing the XSS Filter to apply in any situations where it didn’t apply before.

An easy answer might be that it’s better to examine the response after processing, as this is when the true meaning of the response is most apparent.  While this makes sense intuitively, it turns out that later matching may be considered suboptimal.  Let’s explore why.

Transformations Everywhere

As suggested above, modern client-side XSS filtering techniques attempt to identify request data that has been reflected into the response.  Transformations on this data will always have the potential to reduce a filter’s ability to successfully make a match.  Some transformations may occur at the server, and since the XSS filter has no way of preventing this, it must compensate.  XSS filters do in fact compensate for server-side transformations.

But at the same time, transformations occur on the client side as a response is parsed and makes it way out to the HTML DOM and/or script engine.  For a filter that delays matching until after a response is processed by the browser, transformations will apply prior to matching and can inhibit successful matching.  This manifests as a filter bypass scenario, or false negative.

In fact, transformations that may occur in various places within the browser codebase are not generally regarded as security related, so they may get introduced, change, or disappear over time without any warning.

Example

Consider the following filter bypass scenario that affected a very old version of Chrome (4.0.249.89):

Benchmark:
foo?x=<IFRAME%20src='javascript:alert(1)'>

Bypass: 
foo?x=<IFRAME%20src='javascript:alert%26%23x25;281)'>

This issue was reported several years ago and subsequently resolved.

Observe how the open-parenthesis is replaced with its HTML encoding, &#x25;.  Because browsers automatically HTML-decode attributes, the &#x25; is able to substitute for open-parenthesis in this context.  But given a post-parsing matching process, the &#x25; present in the URL will no longer match the open-parenthesis present in the actual script!

Conclusions

It is not simply a matter of later matching being inherently “better.”  As you can see from the example above, there is a real tradeoff – while a late-matching technique may be able to more specifically target an attack for disablement, it loses some ability to accurately identify an attack.

In any manifestation of this problem, it would seem that there are several approaches to mitigate the threat:

1. Move the matching process to occur before parsing.  This may be difficult if matching is entirely context-dependent.  Eg: If there are no regular expression heuristics to identify what an attack actually looks like, reflection detected before parsing may be too generic to flag as a potential attack.
    
2. Simulate HTML encoding behavior in matching.
    
3. Change the browser to remove automatic HTML decoding in attributes.  Unfortunately though this is a bit of a non-starter.  The automatic HTML decoding is supported cross-browser and removing it would trigger application compatibility issues.

Taking an early-matching approach, the Internet Explorer XSS Filter still must account for the behavior of the HTML parser so as to properly identify attacks.  It does this in a way that is designed into its core architecture – using a flexible regular expression heuristic.

Refining a regular expression has a number of advantages relative to alternative approaches to addressing bypass scenarios like the one described above.  Specifically:

• Straightforward implementation and testing
• Consistency across fixes
• Easier to reason about overall fix approach
• No code churn outside the core filter logic
• Less likelihood of a performance penalty

Finally, the “later is better” argument fails to recognize that matching can be decoupled from blocking.  It is asserted that matching should occur as early as possible so as to avoid any transformations that may be observed as a response proceeds through the browser’s internals.  For the purposes of accuracy, blocking can be performed later in the process, as necessary, when the browser has determined the semantics of any suspect response fragment.

Putting this into practice is pretty simple.  First, you’ll need a Standards Mode DOCTYPE and document compatibility header on your web content, eg:

<!DOCTYPE html>
<html>
<head>
  <!-- Enable IE9 Standards mode -->
  <meta http-equiv="X-UA-Compatible" content="IE=9" >
</head>
<body>
…
</body>
</html>

Then enable X-FRAME-OPTIONS by setting the appropriate HTTP response header:

X-FRAME-OPTIONS: DENY
…or…
X-FRAME-OPTIONS: SAMEORIGIN

Now Standards Mode will be enabled and framing-induced "mode inheritance" will be prevented.

This question comes up quite a bit in the context of reactive security work.  There are basically two traditional answers:

• Yes.
  When you’re attempting to find variants of something like a memory corruption bug, fuzzing is your best friend.  It’s a no-brainer.
  
  
• No.  Er, wait.  Sure, uh, go for it...
  When you’re attempting to find variants of something that looks more like a design bug, fuzzing might at first seem silly.  The answer becomes less clear after thinking about it a little more.  With 20/20 hindsight you can usually think up a way in which any particular bug might be caught by an automated process.  Would that automated process fit a loose definition of fuzzing?  Possibly.
  
  This intellectual discussion usually doesn’t go very far.  This is because of a general perception that fuzzing for design bugs just isn’t going to deliver the ROI that creative hacking, code analysis, etc. can provide in a given period of time.  But it’s very hard to say that this is true in all cases.  Hence the vague answer above.

Example

Here’s one simple scenario where a technique that could surely be considered fuzzing (and was specifically designed to identify design bugs) did yield a good result.

While testing the Internet Explorer XSS Filter prototype in 2007, SkyLined identified that classic ASP would simply drop invalidly encoded character sequences from HTTP request querystring parameters prior to the HTTP response formation.  This resulted in a situation where our filter could not properly match requests to responses and thus the filter could be bypassed for apps on classic ASP.

The XSS Filter was adapted to account for this situation and test cases were created.

Later we developed a fuzzer capable of slightly modifying test cases before running them.  As you may imagine, it’s not hard for a simple fuzzer to generate various forms of invalidly encoded character sequences.  As it turned out, our fix for the encoding issue missed a corner case that our fuzzer was able to trigger.  We were then able to fix the variant and add a new test case to cover any future regressions.

Thoughts?

Fuzzing for design bugs is not a new idea.  Just in regards to XSS, it was mentioned by Alexander Sotirov in 2008, and of course the sla.ckers are well known for putting this approach into practice.  What is most interesting to me right now is the question of when / how to apply fuzzing style techniques for design bugs in general.  I don’t recall ever having seen a really good answer to this question.

So I would be interested in your thoughts on classes of design defects that are particularly amenable to some form of fuzzing, as well as classes of design defects where fuzzing is just a waste of time.  (Some other questions: What actions must a DOM crawler have to perform in order to be a true fuzzer, and does it even matter if it’s called a fuzzer or not?)

Feel free to hit me up on Twitter or leave a comment on this blog.

Unauthorized Site Scripting
Unofficial Site Scripting
URL Parameter Script Insertion
Cross Site Scripting
Synthesized Scripting
Fraudulent Scripting

The next day there was consensus – Cross Site Scripting.  In retrospect, I think this was a good choice given the options on the table.

By early February there was a coordinated advisory release with CERT:
www.cert.org/advisories/CA-2000-02.html

The research leading up to the disclosure dates to mid-December 1999 – exactly ten years ago.

Over the years, the definition of Cross-Site Scripting has expanded somewhat.  What we once referred to as simply “Cross Site Scripting” might now be classified as the reflected / non-persistent form of the attack.

Let's hope that ten years from now we'll be celebrating the death, not the birth, of Cross-Site Scripting!

Dan and RSnake are big on server-side Host header validation as an anti-rebinding strategy.  Every time I starting thinking about this, here's my basic train of thought:

1. Host header validation is simple, and simple is good.  If you implement Host header validation at the server, it just works.
   
   
2. But what about everybody who doesn't conform?  Most web sites don't conform today, and if they do it's not particularly intentional.  I'd hate to see webappsec spend the next 10 years beating up the web properties that don't confirm.  We'd inch the web towards real security in a sort of hostile manner.  There must be a better way...
   
   
3. So coming at this from the other side -- what can the client-side do to help?  The hope there is to not only empower the user to verify their rebinding defenses on any given site, but also to put leverage on the server-side to implement Host header validation (to avoid getting blocked at the more secure clients).  As of now, a simple, practical, and comprehensive client-side anti-rebinding strategy remains elusive.  And if client-enforced Host header validation requires a server-side tweak, say a Host header on the response, that puts us back to the problem in #2 above.
   
   
4. So with all of this, why isn’t "use SSL" the simple anti-rebinding strategy?  In the near term, is there really a better answer?
   

Now, all this being said, I think the Rebinding threat is still yet to be fully defined.  It's possible that some interesting anti-rebinding strategies we see will develop out of a need to address specific attack scenarios identified over time.

Here are some related resources from Shawn Steele, Windows / .Net globalization guru: blogs.msdn.com/shawnste/pages/code-pages-unicode-encodings.aspx

Example:
site.tld/foo.asp?FName=<object%20data=anything_at_all.pdf><param%20name=src%20value=othersite.tld/xss.pdf%20></param></object>

The PDF proof-of-concept contained:
getURL("vbscript:MsgBox document.cookie");

Thanks to Alex, we were able to address this bug for the IE8 final release.