 All right, can you hear me? Okay, well, thanks everyone for coming. This is a great attendance, and so I'm glad everyone could make it. So who we are, this is Jesse U, and I'm Rich Lundin, and we are both security geeks. We also have a third author who's not here. He's Travis Walker-Road, so shout out to him. He might be streaming it back in Seattle. So what this talk is about is, well, we spend a lot of our daytime looking at a lot of web applications, and these web applications are usually not your typical internet web applications. They usually have had threat models, and they've usually had code reviews, and they've usually been pen tested a lot of times. And so typically they have some of these, the common vulnerabilities like the OOS top 10, so sometimes they'll have cross-site scripting, but usually we don't see as much things like that as you might see in a regular web application. So, but we still find bugs, right? But the bugs we find are maybe a little different. They're bugs that if you hire a pen test, or maybe they won't find, or maybe they'll rate as less important as they might be, as we'll hopefully show. So this talk is about some of those bugs we're finding. We call it the new low-hanging fruit, or new security bugs, because they're typically, when we look at a web application, there's some of the things that we look for first. Oh, sorry. What was that, down? Slow down, please, slow. Oh, sorry, slow down, yes. So, along these lines, first I'm going to talk about click-jacking, then Jesse's going to talk about cookies, and I will wrap up with XML processing. Here's the obligatory problems and mitigation slide, so no companies were harmed in the making of this presentation. Yeah, so everything here has been fixed already, but we're gonna show some examples of like Facebook and WordPress and Microsoft of things we've broken and are fixed now. So, with that, click-jacking. So, click-jacking is that thing where maybe you're logged into Facebook and you visit in another tab, you visit a page that looks something like this, and you want to watch this video, so you click here to verify your age. But really, where there's this here, you're actually clicking this hidden Facebook like button, and so when you're just trying to watch the video, you're actually clicking like on this arbitrary thing, and so you end up with crap like this on your Facebook wall. So let's get one thing out of the way. Most of us just don't take this click-jacking thing very seriously. When we think of click-jacking, we normally think of a fact like this, where we've clicked on a link and we clicked on the page, and we end up with crap on our Facebook wall, and sure, that's an annoying thing, right? But it's not something that's a critical security problem. So click-jacking is something that's well-documented everywhere. OWASP has a great page for it, and they go into a lot of detail about mitigations and how to exploit it, but it's not something that's like in the OWASP top 10. And so Microsoft is where Jesse and I happen to work. We also have SDL recommendations and SDL requirements around certain threats, and click-jacking is one that has an SDL recommendation. So again, it's like the OWASP recommendation where it goes into a lot of detail about how to exploit it and how to defend against it, but it's not an SDL requirement. So we kind of give developers this guideline that says this is how you should be doing it, but maybe it's not as enforced as some of the OWASP top 10 like cross-site scripting and cross-site request forgery. So personally, I've always wondered why maybe we, as a security community, treat click-jacking, which is essentially this confused deputy problem. So it's the same basic problem as something like CSRF, but we tend to treat it less serious. So maybe it's because it's hard to get people to click on something. Like a quarter of the sites on the internet, when you visit them, before you even go to the page, they make you click on something. And I'm pretty sure if most people didn't click, maybe this is Forbes.com, maybe they wouldn't have a click thing to get to the page. But anyway, so we don't care about click-jacking that much, maybe, but if it's convenient, we will try to defend against it, I guess. And when we try to defend against it, in general, our goal is to not be framed. So if we have a web application and our web application can be framed, then we've lost. So there are two typical ways to do this, and these are X-frame options and using JavaScript. So X-frame options, that's an HTTP header that's sent in an HTTP response. And this was kind of pioneered by the IE team. But all major browsers support it now. So what it does is it sent in this HTTP response, and when a browser sees that, it will say, okay, I'm not going to frame this page and there's two options for it. There's same origin or allow. And based on that, like if it's same origin, it will only frame pages in the same origin. And if it's denied, then it just won't frame pages at all. And so there's no bypasses for this. So X-frame options is a great mitigation for click-jacking. If you have it, you're probably protected with modern browsers. But that said, there are two pretty serious limitations with it, and these are, one, even though all modern browsers support it, only newer browsers support it. So if you want your web application to protect users that use Internet Explorer 7 or maybe Firefox 3.6 and below, these users just aren't protected, not with X-frame options. So another limitation is that there's just not that much flexibility. It has two options, same origin or deny, and nothing else. So say you're site A and you want to frame site B, that's a pretty legitimate scenario. You just can't do that with X-frame options. So the other solution is a JavaScript frame buster solution. And it might look something like this. This is a really bad one. But it says something like, if top does not equal self, top.location.replace.location. So this is a stupid frame buster script, but it's easy to see what's going on. It's trying to prevent the page from being framed. JavaScript solutions are super common. They're way more common than X-frame options. And they're also, they kind of don't have the same limitations X-frame options has, right? So all browsers support it. And so it's a tempting solution, because we theoretically have this one solution to rule them all, right? So we have one solution that could theoretically protect all browsers, so that's appealing. And also, let's see, there is another advantage. Oh yeah, you can have flexibility. So if you're site A, you can do things like frame site B. That's OK. You just have to have custom JavaScript for it. So JavaScript is a defense. The problem with JavaScript is it's really, really easy to get wrong. So what happens with mobile sites? What happens when there's no JavaScript support? And can the JavaScript protection be disabled or neutered? And so there's been a lot of work here. My personal favorite way to disable or neuter JavaScript are using security protections of the browser against it itself, I guess because I like the irony of it. But like Internet Explorer and Chrome, they have XSS filters to cut out script. And these are pretty good at what they do. When they see a script in the URI, sometimes when they see that in the response, they'll filter out this JavaScript. And these have changed over time. But how they work is sometimes you can use these against the browser and actually filter out the frame-busting script. So you're using this protection mechanism that's designed to prevent cross-site scripting, but you're using it to disable this other script that's trying to prevent the page from being framed. So that's pretty interesting to me. There's also another one of this category of security features is the sandbox attribute. And all HTML5 compliant browsers will support this because it's part of the HTML5 draft specification. But if you have this, then in the iframe, then it's not supposed to execute JavaScript. So anyway, moving on to an actual application of this, Facebook used JavaScript. And this is to prevent the framing of their pages. This is to prevent click-jacking. And they did this on their most sensitive pages. This isn't like the like button that we showed before. This is on their pages like the privacy settings and the account settings. These are pages they definitely did not want you to frame. So this is me. So on these pages, I guess, rather, they had like a six-inch snippet of JavaScript. So they had this frame-busting script that's trying to prevent this framing. But it turns out that if you just added a sandbox attribute, or there's probably another number of ways to do this. But if you just disabled the JavaScript, then you can happily frame the page. So this picture is me framing Facebook. So all right, we win. But now what? What can we actually accomplish by framing a page? This is kind of where you have to get it creative. At Blue Hat this year, I was talking to Marcus Neumitz, who's writing a whole freaking German book about the subject of UI redressing and this subject. And he's got a lot of very, very cool techniques. And they're all very interesting. But what I think is the most interesting is when you take these techniques into account, that people like Marcus have come up with and you actually take the application's logic into account. So you browse through the application with the Evil Bit Set, and you see what you can do just by framing a page. So along these lines, let's have an example. Here I am, I'm Richie Needle, and I'm pretty sweet. I like work for the NSA. And my religious views are like so crazy that Microsoft PR decided to censor them, I guess. And also I have a birthday, but I don't want that getting out because I use it for all my passwords. So all my information is super secret. And I don't want it getting out. So I'm very careful about my privacy settings, right? I go into here and I have everything set to friends only. I only share information with my friends. And in fact, I don't even have any friends. So that got a laugh. So I'm very careful. But one thing I do do is I like to browse the internet while I'm logged into Facebook. Who doesn't? So I visit these legit looking sites. And this is like a GNU man page or something. And it looks totally legit. So maybe I click on it when I read. Then I go back to insert my Facebook profile some more because that's just how I roll on the internet. But meanwhile, in the dark corners of the internet, this isn't my server. Jeez, that's my phone number, my birthday. I use my birthday for all my passwords and my crazy religion. How the deuce did this happen? All of my information is on some server somewhere on the internet. And I didn't even see anything go wrong. So what actually happened is when I visited this totally legit looking page, what was actually happening is, hopefully this video plays actually. Oh, I have to actually click it. No. Maybe I won't play in this resolution. But that said, we have several videos too. So that's kind of a bummer. Oh well. I'll explain them to you. So what actually happens is it follows the mouse around. And so wherever you click on this page, it doesn't matter. Then you're actually clicking on this button. So what is that button? It turns out that this is this ad front button. And ooh, this guy looks super sketchy. And he likes Fight Club and his face is censored. So I would never friend this guy left my own devices. But when I clicked on that page, I was actually clicking on this ad friend button. And that's a different trust decision, right? Just clicking on a page is a very different trust decision than adding this friend. And so what actually happened is when I added this friend, so I clicked on this page with this button that was following my mouse that unfortunately was not visible, I clicked that. And then there's this event that happens when I click on that link. And so that page then detects the click. It logs into its evil account, scrapes the friend request, retrieves all my friend information, and then unfriends me. And so after you unfriends me, I don't even see anything out of your ordinary. So there are some tricks behind the scenes that took some time. I'm not a JavaScript developer, so there's like getting the mouse or the button to follow the mouse actually took a while. Unfortunately, we didn't get to see it. All that time wasted. But luckily, Birgit, my wife, is a JavaScript developer, so she healed me with that. But basically, you hit the edge and it went to the middle. But even things like how to detect a click are actually not trivial problems. Because we're trying to detect a click in Facebook.com, we don't own that DOM, but what we do own is our own web page. So how we did that is we set focus to an invisible button on our web page. And when we lost focus, we just assumed there was a click. And that makes a lot of sense. We might be wrong at some of the time, like say a user presses tab will lose focus, but that's okay, we don't need to be right all the time because what that kicks off is our friend scraping information stealing. If we're wrong, that's fine. So this is a browser-specific exploit. My exact code only worked on Chrome, but it's exploitable on browsers so I don't think it's only a Chrome issue or anything. So this was pretty neat, and I went back to the guys, like Jesse Yu and Travis, the other offer. They're just like, hey, I can steal everyone's information. All they have to do is click once. I thought that was pretty neat. But Jesse Yu was not impressed. He's like, what else can we do with click jacking? Can we completely take over someone's account? So most good web applications, and I consider Facebook a pretty good web application, when you reset your password, they usually ask for the old password first, and that makes a lot of sense. Like think about it, if you had a cross-site scripting in Facebook.com, you wouldn't want this cross-site scripting to all of a sudden completely take over their account. You might steal the session, but you don't want them to reset the password or their own password, that would be a bigger loss. And so good sites will require this old piece of information, the password. But there's more than one way to reset your password, right? Because what if you forgot your password or something? And so that's why there's like password reset questions. And again, these can be insecure, because so if you have a password reset question, you have the same scenarios before, you have like a cross-site scripting, then you don't want an attacker just to be able to add their own question, right? Because then they've still completely compromised the account. And so Facebook is good here too. They ask for the old password before you add any security questions. So again, good job in this case. But it turns out there's another way you can reset your password in Facebook. And that's through a mobile phone. It turns out that Facebook does not ever, or did not ever require a piece of old information when you're adding a mobile phone to your account. And you can use your mobile phone to reset your password. So let's run through a scenario now. This is a legitimate scenario. So I'm a legitimate user and I text FB to F-Book. And I get this response. And I visit this webpage. And so this confirmation code is 54X4MD. That is tied to my mobile account. And I'm also logged into Facebook at the same time. So it knows my Facebook account. So then I click this activate button and it can tie these two together. Again, the confirmation code is tied to my account, or my phone. And I'm logged into Facebook. That's my Facebook part. So the crazy thing about this whole system is though, that hackers actually have phones, too. So let's look at this from a slightly shifted scenario. Now I'm a hacker, okay? I text F-Book, or FB to F-Book, and I get the same response, okay? And I get this attackers page now. I don't even need to fill out that 54X4MD. It gets it from the get request. And so I have this hacker page that's tied to my hacker phone. If I can just get someone to click on that link, then they've tied my hacker phone to their victim account, okay? So here's another awesome video where it's following us around. Yeah, we don't have this either. But it's the same code. It's the exact same code where we can use the sandbox attribute to disable the framing. And so a user, this is a victims browser. Imagine a victims browser, and it's framing the hackers activate button to the hackers phone. So when the victim visits this page and they click anywhere on the page, it's tying the hacker's phone to their account. And so at this point, the hacker's won. And their account is completely compromised. But just to prove it, we'll prove it with images. So now I'm in an attacker again, I can say I forgot my password. And I don't even need to know the victim's email. I can use their phone number, my phone number that I added to their account. And they send me an SMS password reset code to my, again, my phone. And then they asked me to change my password. I never needed to know the old one. So there's kind of a lot going on behind the scenes if you're an attacker here. But if you're a victim, there's really not that much. You go to a malicious page and you click once. And then your account is completely taken over in a single click. So I thought that was pretty neat. Mitigations, we worked with Facebook to mitigate this issue. And the minute, like they took the pages immediately offline, we recommended X-Frame options to be put on the sensitive pages. And as time goes on, that'll become more of an effective mitigation more and more because more browsers will support it. They also now require a password to add a mobile phone number. But one point is, like all the things in this talk, we've spotted this issue multiple places with very similar results, similarly bad. And the mitigation, think about how bad this could be. It's a wormable attack in a lot of cases where you compromise one thing and then you give a lot of links to your friends and then they're all compromised and you give a lot of links to your friends. And so think about applications and they're completely compromised like this. It could be pretty nasty. But usually the mitigations are similar and they're to use like X-Frame options and in-depth security so you can't take over the account with adding a mobile phone. So the important thing is we made the wall of sheep. Okay, so now Jesse's going to talk about cookies. Thanks, Chris. Can you guys hear me all right? So first of all, I wanna say I'm very honored to be here. It's my first time at Chaos and I hope I'll have more opportunities in the future. Also, I wanted to say that a lot of this research that I'm about to show is done by Travis and I know Travis you're watching, so hey, how's it going? So I'm gonna be talking about cookies. Specifically a technique we call cookie tossing. It's a security conference so we thought it would be appropriate to make up a new term. In fact, this technique has been talked about a lot and what we're trying to do here really is to show you some real world examples as to how this works in the effort that you can go ahead and test your own applications. So let's get started. So basically for those of you that don't know what a cookie is, it's essentially used to maintain state between the client and a server in a web application and it's essentially just a semicolon delimited list of name value pairs as you see here. So in this case I have off token, site info, et cetera. What's interesting in this case is I actually have two language cookies shown in red and the question I want you guys to think about is what happens when there is this conflict where there are two cookies with the same name? As it turns out, it's usually the cookie that is first in the string that is processed or used by a script or a web application and that's really the basis for this attack being able to override cookies in this manner. We'll show you why this is important in a little bit. So if an attacker can merely control not read the cookies across domain, that's bad. I'll show you examples of that coming up soon. Basically the same origin policy will prevent a script from one domain from reading the cookies from another domain but what we're interested in looking here is what happens if you can write cookies across subdomains and what the implications are there. So the question becomes how can the attacker actually make his cookie first in an effort to override cookies that were set legitimately by the application? And one way of doing this is by making, by setting a more specific path and so that gives you the ability to set cookies for everyone else in the same root domain space and we'll talk about an example soon. So again, I wanna reiterate we're not talking about reading cookies across domain, we're only talking about writing them. These issues have been around for a while. Our friends at Google, Chris Evans and his colleagues actually blogged about this a while ago calling it cooking forcing through active managed middle attacks. But what we're gonna talk about here is really the subdomain vector. So let's take an example. Let's assume we had a JavaScript running in the context of test.MicrosoftOnline.com. So if we set document.Cookie to this value that you see here, cookname equals to first, domain to test.MicrosoftOnline.com and the path to slash, you'll see that this is the cookie that is sent to the server. As you would expect, cookname is equal to first. If we do this again and we set a second cookie, cookname equals second, but this time we scoped the cookie to the parent domain, MicrosoftOnline.com. You'll see nothing has changed. Really, cookname is still first and our cookie that we just set is second. However, if we play a different game this time and we set a more specific path, so in this case slash site and we set the cookie name, cookname equals evil, you'll see that when we request MicrosoftOnline.com slash site, our evil cookie actually comes first. It's the first in that cookie string. And similarly, if we browse, you make a request to test.MicrosoftOnline.com slash site, you'll see that the evil cookie comes first. And if we have a long domain, chicken.monkey.camel.emew.secure.MicrosoftOnline.com slash site, you'll see that our evil cookie is still at the head of that list. So why is that bad? We'll see soon. So which cookie wins? We talked about this briefly already. So if we have admin.company.com and it sets a good value for cookname and it has all the flags that we always encourage as security engineers, secure, HTTP only, whatnot. And then let's assume that there's a reflected or stored cross-site scripting in a less valuable domain. So food.beta.temporary.company.com. And now we set cookname to an evil value, but we play the same trick. So we set it to slash admin and we sculpt the cookie to company.com. You'll see that in the request to admin.company.com slash admin, the evil cookie actually comes first. So that's just the instance of what I've been describing. Our friends at Google actually documented this pretty well in the Google browser security handbook. What I like about this slide is you'll see that under Internet Explorer and some other browsers, it just says it's random. So it's not really predictable what happens. But in most cases, the most specific cookie does win in our experience. So how do we play this game? How do we toss the cookie up? So one of the first things you wanna do is to find a cross-site scripting in a sub-domain of something you care about. So when we are testing large Microsoft properties back home, we have huge domain spaces. As you can imagine, there's lots of sub-domains under live.com, microsoft.com, msn.com, et cetera. What we are gonna say here is that in the presence of a huge sub-domain space, it's actually really easy to find cross-site scripting with enough motivation and time. And once we have that cross-site scripting in the sub-domain, we can go ahead and play this game. And again, our objective here is to make our evil cookie always come first and override anything else that's in that cookie string. So let's talk about cross-site request forgery. So for those of you that are not familiar with CSRF, essentially this attack occurs because the server is not able to distinguish between a request that the user legitimately makes through the UI and a request that the user is forced or tricked into performing. So one common mitigation for cross-site request forgery is what you see here. This is sometimes called the double submit cookie pattern. And what's happening is we are comparing a form post value or a query string parameter with a cookie value. And if those values match, then we assume that the user is authenticated to perform that operation that changes state in the system. But there's a problem with this. And the problem is that this only proves that the request originated from someone that can write cookies. So back in the day, we used to say you could do this with rich internet applications like Flash and Applets and whatnot, but that's going away slowly. But this is a problem if we have this cookie tossing attack because attackers now have the ability to write cookies. And since they also can control form parameters, a cross-site request forgery mitigation like this is doomed to fail. So another way you can do this is through ActiveMan in the middle. That was kind of the cookie forcing issue that Chris Evans talked about. Essentially, you can trick a user into visiting a non-SSL version of the site and then attempt to overwrite their cookies that way. So we actually found this exact bug in the early development cycle of the Office 365 portal. Basically, there was an Ajax function that performed updates, and they were doing this exact same thing. So they were taking a cookie value and comparing it to a form value. And if those two matched, then they assumed that that's a legitimate request. The problem that we had at the time is that the MicrosoftOnline.com domain space is actually very big. There's lots of other subdomains that we don't necessarily control. There are third-party applications there as well. And we actually did manage to find a reflected cross-site scripting in the subdomain of MicrosoftOnline.com. So I don't know if videos are working today. I hope they are. I'll give it a shot. No, no. Yeah, that sucks. So what you would have seen is basically an exploitation of this bug where an authenticated user visits the application, opens his email, clicks a link. And that link, using the reflected cross-site scripting bug, sets a cookie that is scoped to the parent but with a more specific path in turn overriding the canary value that was set by the application. And since the attacker can specify the request form value, set a post-parameter as well as the cookie value, those things will match and the request will be authenticated even though the user was tricked into clicking a link. It's unfortunate this doesn't work. So we were involved with the mitigation strategy for fixing this bug. Security engineering was heavily involved and now the portal now submits a header with the hash value of a session-specific value. And the portal is better now as a result. So really the fix here is to make sure that you use a canary that can be bound to a user session that can be validated on a backend somehow cryptographically or through some sort of session persistence. And so my friend Travis actually found this bug and we were talking about it to Rich. And Rich was like, hey, Outlook Web Access does this exact same thing. So it turns out the exploit was identical to the one that we had found on the portal. So let's dive into that example a little bit and that's a picture, I know why that's there. Okay, so the exploit, as you can see here, this is a reflected cross-site scripting attack on editorial.microsoftonline.com. And what you can see we're doing here in the exploit is we are setting the document.cookie value specifically the user context value to be dead beef, dead beef, dead beef which is an attacker supply value and we then are setting a more specific path and scoping the cookie up to the parent domain which was the same trick early on. And then we're just redirecting to the form that will do the post that we'll see in a little bit. So here's the form post, it's just a vanilla form post for all of you that know HTML, calling to vulnerable endpoint. And then what's important is on that last line you can see that the hit canary value is dead beef, dead beef, dead beef as well. So again, what we're doing here is we're taking the form post value and the cookie value and we're making those match so that the request is authenticated. And this is what is sent to the server. As you can see, there's two hit canary values. The first one, dead beef, dead beef which is what is set by the attacker. And the second one is the legitimate canary that was set by the application. But since our cookie takes precedence in this case the application is going to go ahead and take the first value which is attacker control. And this is what happens. So this is Rich's signature in his outlook and when he clicks on the link that changes to this. So you can see a cookie tossing can be a very effective technique in bypassing weak cross-site request forgery mitigations. So outlook has clearly fixed this issue. They had quite the complicated patch matrix but they got it done. And again, the fix was similar. You always want to make sure that you use a value that is unique to the user and that cannot be modified. So there's really two properties that should hold here. First of all, an attacker should not be able to use an arbitrary pair of cookie value and a say get or post parameter to perform, to forge a request. But also, the attacker should not be able to repurpose his own legitimate value for such an attack as well. So if those two properties hold, then that's good. So cookie tossing first through cross-site scripting. So sometimes you have a DOM-based XSS where essentially the malicious payload never makes it to the server. It's all client-side. And lots of tools will report this as being non-exploitable because again, the assumption is it's very hard for an attacker to set cookies in the user's browser. But then again, we just found a way of doing that. So let's see how we can make that interesting. So we actually found a DOM-based XSS in the shared library of MSN. And we wanted to get msn.com. So we did not want to use the path trick that we just showed you. So the PRD cookie in this case was vulnerable. And there was a code that looked like this where essentially in JavaScript, they are getting document.cookie. And then they are parsing it out using a regular expression. And then it's a vanilla document.write with an iframe. And that value is not output encoded. And so that's your almost classic DOM XSS example. What's interesting is in this custom cookie parsing code, there's an iflag that has passed. And that actually means a case-insensitive match. And that's significant because a cookie name with a capital N and cookie name with a lower place N are actually treated as different cookies in the browser. And so, for instance, ASP.net will do a case-insensitive search. And so the case really doesn't matter. So back to the example that we were just talking about, the PRD cookie, which is the vulnerable parameter in the cross-site scripting, we could override by creating our own cookie with a lower case PRD. And actually, there was additional logic on this page that would expire the capital PRD cookie. And what that did was it bumped our lower case PRD cookie to the front of the string. And so what that means is we essentially control that value in the user's browser by playing these interesting casing tricks. So all we had to do to exploit this was to, again, find a cross-site scripting in the subdomain of MSN.com. And we quickly found a stray HTML file sitting somewhere that should not have been there. And we leveraged that. So our cookie is first. And because of that, we were able to get cross-site scripting on MSN. You can see Travis's cute baby face right there. Also on MSNBC.com. And also this web mail service that is used by a couple of people. So many getting cookie exercises relatively straightforward, the generic advice that applies to reflected or stored or traditional cross-site scripting also applies to this instance. You want to make sure that you input validate and encode for the correct context. One thing I did note before is that many automated tools do not actually detect bugs like this. And if they do, they always categorize them as low or informational. But the exception to this is the Google guys that have this DOM snitch tool that I think is really good and is a step in the right direction in finding some of these bugs or classes of bugs. So we showed that cross-site request forgery and cross-site scripting are possible through using this technique. But there are lots of other interesting research areas because your app could depend on cookies in different ways that lead to app-specific vulnerabilities. So things like session fixation or business logic flaws. So what can you do about cookie tossing? Well, the biggest takeaway here is that you should treat these as tainted or untrusted. Basically, they are the same as post-parameters and get-parameters when it comes to trusting them. So you should never trust your cookie values. And if you want to trust them, you should cryptographically assign them or guarantee their integrity some way. There's a local storage that you could potentially use and new HTML5 browsers that you could potentially leverage. And there's also a local storage, which is part of HTML5, that may or may not have the same subdomain issues. I don't think a lot of research has gone into that, so it's an interesting area for sure. And of course, there's Origin Cookies, which is a new RSC and more standards that are coming to help address issues like this. And with that, I'm going to pass it over to Rich to talk about XML. All right. XML attacks. Obviously, XML is used pretty much everywhere. It's used tons in configuration setups and whatnot. It's used pervasively in cloud applications, too, which is where we spend a lot of our days. So that's why it's important to us. So wait, are there really features that take user-controlled XML? Here's two products we support. This is link online. They take XML. And this is ACS, which is another product we support. So what happens if your feature part is untrusted to XML? Well, there's tons of things that can go wrong. And in this talk, we will only be talking about the cross-site scripting vectors using XML, XSL, which, and this is due because Microsoft asked us to only talk about the cross-site scripting XSS vectors using XML, XSL. So that's what we're going to talk about. But I think that's unfortunate, but on the other hand, there is maybe getting client-side JavaScript to execute is that's good. And maybe that's what we want, rather than dossing the server reading files. So maybe that's our end game. So what if the XML is only parsed and not stored? There's certain scenarios here that are pretty interesting. Let's take a look at this code. So this is some C-sharp. And what it's doing is taking this untrusted XML string, and it's reading it, it's parsing it. DTDs are enabled, and that's important. And so ignoring all the stuff that's wrong with that, there's this try block, and then there's a catch block. And if you look at the catch block, the exception message is printed out without HTML encoding. So if you look just at that, how can we get cross-site scripting out of this catch-all exception? If we can get scripts into our exception, then we can get script to execute. So let's talk about how we can get script into our exception. One technique is cross-site scripting using URL fragments. So if we have our malicious XML and it looks something like this, where we create a foo entity and we have it look like hashtag script alert one, well, then the exception message in .NET, it looks like this, so it says script alert one cannot be part of the system identifier. So we've successfully gotten script into our exception message. So that's one way to get script executing. And this is a good technique because it's self-contained. And that's all you need. There's another technique, though, to cross-site scripting using 500 messages. So in this case, it's similar. You just create an entity foo, and you point it at reachableserver.com slash return custom500.aspx. And this does exactly what you think it would do. This is a web page that returns a custom 500. So in the web application's response, it will return 500 script alert one. And in the exception message that's returned, it's script alert one. So this isn't as nice as technique one, because technique one was all self-contained and you didn't need to be able to reach a server. But I guess the neat thing about this is there's more than one way to do it. And there might even be more ways. And there probably is other ways in other languages, too. So I guess watch the exceptions you throw. So what if XML can be uploaded and downloaded? This is an interesting case, and it'll be important in our not video demo later. So you can actually get, if you upload an XML file, and it points to a second XSL transform on the same domain, that XSL is applied by design. So as an example of this, if we have on the left, we have firstXML.XML, and it's just very simple, but it points to this XSL that's on the right, and it's just doing what it's supposed to do, but it's transforming this firstXML to execute script. I'll go back to that. So this is important, and again, keep it in mind. Now we're going to talk about the WordPress blended threats demo. So WordPress comes in two flavors. There's the software you can download, and that has its own set of issues, right? And so don't think of that, because with that you can add your own plugins, and you can add your own templates, and it's like you can obviously get remote execution on that. So that's not the one we're talking about though. We're talking about WordPress.com, and that's very different, because you can only add a preexisting set of templates, and you can only use a preexisting set of plugins. So it's very locked down in comparison with the version of WordPress you just downloaded, although you can obviously configure your downloaded version of WordPress to be the same. So our end game here is to obtain JavaScript execution in any subdomain of WordPress.com. Okay? So what's interesting about this is Travis was doing a lot of work in cookies, like that Jesse was talking about, we're all kind of working in cookies a lot, and when you're working in cookies a lot, you want a space with a bunch of subdomains, right? So WordPress.com was especially interesting because they have site one.wordpress.com, site two.wordpress.com. Obviously there's a huge subdomain space there, and so I started looking at WordPress and thinking, okay, what issues can I find with cookies? Is there any CSRF? Is there any cross-site scripting? Is there anything like that? And sure enough, there was, and it didn't take very long to find. So I found this, this isn't a cookie. It's a WordPress logged in cookie, and it's just script alert one, and it's echoed in the response plain text. So this is as easy as a cross-site scripting as it gets, but it's in a cookie. And in fact, BERT found it too just by scanning it. So it's, again, this was very easy to find, but BERT rated it as informational, and the reason for that is that it's a cookie, so it's hard to exploit. So let's take a step back and look at WordPress.com. So if we own attacker.wordpress.com, that's a domain we can own, and we wanna attack fictionalcelebrity.wordpress.com. So if we wanna, if we could, let's make an assumption here, that we can execute script in our own domain. So we can execute script in attacker.wordpress.com, but just because we can execute script in our own domain, that doesn't mean we can execute script in fictionalcelebrity.wordpress.com. This is all the cookie tossing stuff, but the same origin policy blocks it, yeah. So the thing is we have this non-exploitable cookie self-XSS, but if we can execute script in our own domain, then we can toss the cookie up, just like we did with Hotmail, and execute script in wordpress.com. So it's exactly what Jesse was just talking about. So the only thing we need here is we need to be able to execute JavaScript in our own domain, okay? So if we do that, we win, and it seems like an easy problem. I was looking for cookie issues because I thought this would be easy, like Blogger let's you execute script in your own domain, and I own the domain, so on premise I can execute script, but it turns out it's actually very really pretty difficult to execute script in your own domain in wordpress. They use HTML, safe HTML API, output and coding, and so if you can execute script in your own domain, that's actually a bug. So we were looking for bugs. One thing about WordPress, Jesse and I actually spent a long time looking for this, and Jesse was the first one to find our XSS in our own domain, so this is his. One thing we can do in WordPress is we can upload safe media files. So that's files like JPEG or PNG, and these files can look like anything we want, so even though they are JPEG files, they can look like whatever. They can look like binaries or they can look like XSL, but it turns out the content type is explicitly set, or else we would get cross-site scripting here, so if we upload script alert one, we can't just request that because the content type is set to an image and so it's not scripting on its own, but we can upload an XSL file. There's another feature in WordPress that lets you import and download your old WordPress blog in XML format, so this is a WXR file. So with this, the content type is actually not set. Okay, so we might get scripted with this, but they actually do validate that the input is actually well-formed XML, so there's another hurdle there. But one thing is that the content type is not set with the WXR file, so if we can use the JPEG file as an XSL file to transform the WXR file, then we can get script executing in our own domain. Okay? So this is just an image to demonstrate that. We upload our bad XSL.JPEG, so this is our XSL that's transforming our XML, and we upload these both to WordPress. Foo.WXR, the browser transforms that, well it does a request and then it's transformed by badXSL.JPEG, which is valid XSL, and they all come together magically and script alerts and it shakes. So that's about as good as the demo gets because our videos don't work. But here's how the XML and XSL pair, here's the actual code for that. So badXSL.JPEG, this is the XSL that's doing the transform of our Foo.WXR, so we can get script executing in our own domain. But wait, we still only get script executing in our own domain, but here's what the JavaScript does. So it's actually using this other vulnerability, this cookie XSS, so the script for executing in our own domain is tossing the cookie up, setting the path to be more specific using WP Admin, and so our cookie wins, and then we can execute script across domain. So using these three things, we can actually get script to execute in any domain. Let's blend it, shall we? Let's have a video that doesn't work. But all this shows is exactly what I was talking about. So we have these three vulnerabilities that by themselves are maybe not so important. If you take a step back, we have this cookie cross-site scripting, and we have a JPEG file we can upload and put crap in, and we also have a WXR file that is validated to XML, but the content type is not set. So using these three, we toss the cookie up, and we actually do get script to execute in any WordPress.com domain. So I thought that was pretty neat because you get one big bug out of the three small bugs. They blend. The resolution with WordPress was super fast. We ported this to them, and they resolved it like within, well, they had a mitigations in place within 72 hours, and then they had a patch that came out in 3.1.3. So mitigations with cross-site scripting is the same as always, and you probably shouldn't be echoing back like exception messages anyway. Disabled DTD processing, for a lot of reasons. You probably shouldn't use DTD processing if you can avoid it, especially if the XML is untrusted. And one of those reasons is that cross-site scripting can happen. Set the content type. We would have had cross-site scripting a lot earlier if the content type was not set on the JPEG files, for example. So that's it. Jesse will sum it all up. All right, so you guys heard about a lot of different attacks, and I'm just going to try to sum it up here. So what do all these vulnerabilities have in common? We talked about cookies, clickjacking, XML, et cetera. These are the new types of low-hanging fruit that we're finding in addition to older ones. So at Microsoft, we have the Secure Development Lifecycle, which is essentially a set of processes that involves code review, threat modeling, pentesting, et cetera. And we have guidelines specifically that would have prevented a lot of these things. So in your organization, if you don't have an SDL or need help building out one, that's something you should probably do first and have strong requirements for common threats like this. Security engineers are awesome. Developers often need help understanding some of these esoteric issues. Testers, as well, need assistance. PMs need help when speccing new features. So security engineers are a good thing overall. So that's it. That's all we have for you. Those are our email addresses if you need to get in touch with us, so thank you. Give them a clap. Okay, please, pretty please, will the cherry on top stay seated during the Q&A and generates a lot of distraction? If you do want to exit after the Q&A, to your right, my left. So do we have any questions? Cue up at the microphones. Let's ask the internet. Okay, either everything was entirely clear or nobody understood anything? Yes. Okay, the interjection was now, we're going to try to play the videos. It may be a resolution thing. I think it is a resolution thing. It's something without codec error, so you might need... Well, that could be... Do you need audio? No. So... Let's black the screen. Okay, there's the screen again. Let's see if this plays. I should have had backup. Yeah, unavailable. Oh, there we go. Oh, now it plays. Okay, here's the super cool ad friend button following the mouse. That was totally worth it. Next time, we got to sacrifice some people to the demo gods. Yeah. We were trying to be cautious with video, right? That's the following the mouse one. This one's the same thing, but... It's the same one, but... It made for a really good slide, and it was really smooth. Where's yours at? Yeah. That was kind of long, I mean, skip that. Do you want to share that? Yeah. Let's do the WordPress one. Yeah, WordPress one's cool. Sure. I should have just... We have so many slides. That's the problem. Reviewing. So here's the WordPress one. Oh, no, that's not the WordPress one, is it? War. Yes, you and your animations. There we go. Okay. Okay, so it's not much, but it's just exactly what we talked about you. We uploaded this goodxsl.jpeg, and then we make a request to this WXR file, which is just straight XML, and it does the transform because it points to the XSL, and so here's us executing a script in our own domain, and then it tosses the cookie up, and we're executing a script in another domain, so that's what it does. Do we get any questions? No questions, so... I think we have one. Yeah, so the first question is, does NoScript help against those attacks? So what was the question? The NoScript extension, does it help against these, or the tag? Yes. I think the question is, does NoScript help prevent some of these attacks? Oh yes, that's a good question. So with clickjacking, no, in fact, with clickjacking it's interesting because if you have NoScript, then the frame busting, well actually NoScript has built-in x-frame option stuff, so that stuff will help. But if your site supports NoScript, like if your site supports the ability to visit the site without script, sometimes that can mess things up, then it might be vulnerable to clickjacking unless you have x-frame options or something, so that's kind of a complicated one to clickjacking. And the cases with cross-site scripting, I mean, essentially the server has no way of, or the client has no way of distinguishing between script that was injected, in some cases, in the case of cross-site scripting and script that's not supposed to be there, so the answer is sometimes yes, sometimes no. Well, almost always yes for the user, but if you're a web application developer and you allow NoScript users, then sometimes you open yourself up to, you could potentially open yourself up to other things. Okay, another one? Yeah, can you give a simple advice? Sorry. I'm sorry. That was hard, I don't think I can answer it. Can you give a simple advice except don't trust everything? Sorry, what was the question? Sorry, yeah. Can you give a simple advice except trust nothing? Sorry, simple advice to... Yeah. So is there any other simple advice besides just don't trust anybody? Oh yeah, simple advice besides don't trust anyone. Well, that's pretty good advice. Um, I mean, the thing is, most of these things can, like a lot of good, there are a lot of good SEL practices out there that exist. And there are a lot of good habits that exist. And if you, sometimes developers will see something, they're like, show me an exploit or I'm not gonna fix it. But a lot of times, in fact, with most of these, just applying these basics without fully understanding the exploits all the time, then you can fix a lot of these, like output encoding cookies, even if you can't immediately see an exploit for it. Or that's just good practice. So I think the rules, like from the SEL, would have prevented most of these attacks if they would have been implemented. I think there's another one here and then over there. Yeah, there's another one. The cookie vulnerabilities you discussed would have been prevented by just not trusting data from your users and signing your cookies. Why is something as obvious as this still a problem? Sorry. Why is it still a problem to just not trust anything the user inputs and just sign everything and verify the signatures? That's actually completely legitimate solution to the cookie tossing one. Signing everything and verifying the signature of all the cookies. Like the MVC framework, that's one way they mitigate it. So one thing I think that's similar to is view state in ASP.net, you wanna cryptographically sign that to ensure it doesn't get tampered with. Okay, I think there's one over there and then there. Yeah, I'm not really into these cookie domains and can't I simply write cookie for .com and it gets passed to facebook.com. If I visit evilhacker.com, where's this cookie? Before I visit Facebook. That's a good idea but it doesn't work in most browsers. In fact an even better idea is like ut or uk.co or something because sometimes they go up to the, browsers used to only go up to the second to the top domain but now most browsers aren't vulnerable to that. But you might be able to find like some weird, I don't know, country code that's, the browsers aren't fixed with that but in most cases that's been thought about. Okay, no. For the CRSF exploit you were talking about, do built-in protections in frameworks like Rails or Django, do they protect against that? That's actually a good question. I don't think they do. Yeah, I think so. I've looked at, I actually was playing a CTF and there was a Django application I noticed that they might just be comparing the cookie and form posts. I haven't verified that for sure but I suspect they might have similar problems. So they would be vulnerable if there was a huge sub-domain space and you had other applications that you could play this trick with. Yeah, the domain space would need to be big. And there's not that many huge domains, well maybe there are, I shouldn't make that assumption. Yeah, okay, I think we have at least one more question. Yeah, wouldn't signing cookies result in huge requests? Do all the browsers and service supporters? The request size when signing cookies, is it going to be a problem? Do browsers support such large requests? So when you're signing cookies, normally that's an application level mitigation so that should be browser agnostic. And signing's really not that big, right? I mean, it depends on the number of cookies you take but if your cookie's important and you're using it for something like CSRF mitigation then it could just be what's a standard hash, like 128 bits or whatever, 256 bits. Okay, we may have exactly one question left over there. I was a little bit shocked to see that someone is still using a browser that supports content sniffing. I thought we agreed five years ago that this was a stupid idea so did the last word exploit only work with Internet Explorer or is any other browser that's susceptible to that? So I assume you're talking about WordPress? So in that case, even if the content type was set to XML the whole thing is by design you want to allow for layer transforms, right? And so even if it was set and there was no sniffing involved that would still work. But my premise where if they didn't set content type on JPEG that would not work. That's correct. Okay, we don't have any time anymore. Please give them a warm applause.