random dross : Web Application Security

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

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.

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.

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

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.

Pinning / Rebinding / Quick-Swap DNS Links

dross — Fri, 03 Aug 2007 18:17:00 GMT

A group at Stanford has been researching these issues and recently published Protecting Browsers from DNS Rebinding Attacks.

Also, Dan Kaminski has published his slides from Blackhat 2007, Black Ops 2007: Design Reviewing The Web.