We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

The Mike Rothman Security Report

ebizQ

What's So Scary About CSRF? Plenty! Rothman Talks to Nitesh Dhanjani

user-pic
Vote 0 Votes

In this month's Mike Rothman Security Report, Mike rolls up his sleeves with Nitesh Dhanjani of Ernst & Young to really dig into and understand the Cross Site Request Forgery (CSRF) attack. Nitesh goes through the mechanics of the attack, and what developers can do to address it. Suffice it to say, this is a nasty attack vector and in all cases, neither the user or the web site being attacked knows what happened. It's one step short of black magic, and the answer isn't to throw a firewall in front of the application because it won't work.

In the free association section, Nitesh rails on PCI a bit, as well as talk about how the Black Hat conference has changed and why he takes time out of his busy schedule to attend every year.

Listen to or download the 18:20 minute podcast below:



Download file

---Transcript---

MR: Hello everybody, this is Mike Rothman. Welcome back to the latest edition of the Mike Rothman Security Report here on the ebizQ Network. This month we are going to tackle the devious and nefarious Cross-Site Request Forgery attack, otherwise known as CSRF.

I have enlisted a good friend as well as a well-regarded security researcher named Nitesh Dhanjani to come on and be a guest on the show this month to really talk about CSRF, talk about why it’s a pretty nasty attack, and also what developers can do to really protector their environment against this type of attack vector. So let’s check in. Nitesh, are you there buddy?

ND: I’m here. Thanks for having me.

MR: That’s great, Nitesh. So why don’t you just kind of give everybody an idea about who you are, who you work for, as well as some of the things that you’ve done just so people can have an understanding about kind of what you’ve done in the past.

ND: Sure. I’m Senoir Manager at Ernst & Young’s IT Enablement Practice. My job is to help E&Y’s client build, install solid security and IT solutions. And my job is also to make sure that E&Y’s current services are cutting edge and to incubate new service lines when it makes sense.

For the purpose of this discussion, we talk a little bit more about how I’ve been involved with application security a little more with emphasis on Web application security. My core job responsibility here at E&Y is to lead our application security efforts from helping clients understand how to relate apps and goals to their overarching enterprise wide security strategy to helping them develop a roadmap to increase their capability, all the way to tactical processes and best practices, application portfolio management, methodologies for attack and penetration threat modeling, source code security reviews, training and metrics.

I’m personally fond of application security because of the huge attack surfaces applications have. A typical large sized internet facing application has a couple million lines of code and a single bug can allow somebody with just a Web browser to steal intellectual property and cause havoc.

I’m also particularly fond of application security because it’s a key point where the business and technology intersect. And some of the intelligent CIO’s understand this and leverage this to their advantage to kind of lend appreciation from the business, which is key because security is often perceived as an expense account.

So besides my job at E&Y, I blog at the O’Reilly. I’ve written two books and I’m thinking of doing one more. I like to speak at conferences and that sort of a thing.

MR: Thank you Nitesh. That’s a great overview. And I also do want to point out our guest’s modesty as well. Nitesh is one of most highly regarded application security experts out there. He’s the one that worked on the Safari corporate bombing attack, which was a huge exploit that was uncovered about Apple’s Windows based Safari browser.

So Nitesh is not only an expert but he’s also a modest dude. So welcome to the show. Let’s kind of jump right in and talk a little bit about Cross-Site Request Forgery. So if you just take the listeners through a little bit of an idea about how the attack works and why it’s pretty dangerous I think that would be a great way to start things off.

ND: Okay. Sure. I’d be glad to. Cross-Site Request Forgery is really an attack against the Web browser and the user. So before we kind of dive into that, let’s go back to the early stages of the World Wide Web. Now, HTML is something that allows you to link and include resources from different locations and that is a core design principle of the Web, that’s how it’s designed to work.

For example, my Web page can just have your browser display an image that is really hosted on someones else's server. This is the World Wide Web by design. So you keep that in mind. And now let’s take upon a scenario. Let’s say you’re logged into your bank account online and the Web application that your bank uses is -- lets consider -- let’s assume that is one about the Cross-Site Request Forgery.

Now, lets assume that you log on to this bank account, this application and you stay logged on and you open up another browser tab or another browser window and you browse to a malicious site. This malicious site can now abuse your browser to by way of Cross-Site Request Forgery into making your browser perform a money transfer transaction on your banking applications that you did not authorize or intend.

This really explains the real world scenario and illustrates the impact of Cross-Site Request Forgery. So before we talk about what just happened, let’s talk about the design of the application first. Consider that this banking site that we’re talking about had a section called money transfer consisting of simple form you fill out that asks you for the amount you want to transfer and the account number you want to transfer the amount to.

You fill out that information, click on submit and that’s how it’s supposed to work. The browser then connects to the Web server, issues a post request because it’s the form to its particular URL, which is then parsed by the application and computed. That’s really poor logic. You have simple Web application, a simple form, straightforward.

Now, since this application that we were talking about, the Web application for the bank was susceptible to Cross-Site Request Forgery, here’s what really happened. When the victim logged into the bank application and opened another browser window and browser through the malicious site, the malicious site simply all it did was served up an HTML form that had the account number and the amount they want to transfer hard coded into the form and used Java Script to submit the form to the Web application URL.

So what really happened is from the perspective of the banking Web application, the incoming request that came in looked exactly like the request that would have come in if the victim had legitimately performed the transaction. So that is really Cross-Site Request Forgery. Cross-Site meaning from a malicious site to the victim’s site and request forgery meaning a request or a transaction that the victim did not need to execute.

MR: Right. So let me get this straight. So basically, I could be on --I’m just doing my business, right. Whether it’s on Gmail, or a banking account, or something else. I open up another tab which I think everybody does, right.

ND: Yes.

MR: I tend to have five or six different tabs open on a slow day, right. So I open up a different tab. That tab opens and goes to a malicious Website, which then launches an attack against my bank or my Gmail site, which is actually accepted by that site because it thinks it’s me. Is that how this thing works?

ND: Exactly. And because you’re already logged in, the malicious site submits to the same URL that your legitimate application would if you performed the transaction. Your browser will go ahead and send the right cookies and everything because what is the browser? The browser thinks, well, I have established a session to the domain. I have a cookie for this domain and I’m sending a request to this domain.

I’m going to send to the session ID and the request. Of course, one to note is unless the malicious site has abused Cross-Site scripting as well, which -- let’s assume it has not just to keep things simple. The malicious site in this case, well in most cases, depending on how things are. In most cases, will not ever get to even see the result of what just happened but too late the damage has already been done.

MR: Right. So and the user or the browser never knows anything happened. So it’s totally transparent to both the user as well as the malicious site?

ND: Exactly. And the key thing here is even if you are the victim Web application owner, and you look at your logs, the IP addresses you will see will be your customer’s IP address.

The thing you might be able to perhaps in some cases kind of figure out which malicious site is doing this is by looking at the referrer tags. So from a perspective of instant response, that’s sometimes you may uncover some information of what are the malicious sites that have abused Cross-Site Request Forgery on my application.

MR: Right. Wow. So if you’re the Website owner, obviously, trying to protect your customers against something like this, what are a couple of different techniques that you could use on your site to make sure that a malicious site doesn’t or is enabled to perform some type of CSRF attack against you?

ND: The key is to be able to differentiate somehow between -- its supposed -- if I had learned about Cross-Site Request Forgery for the first time today, and somebody asked me to brainstorm, what I would do, I would start off with a thought process that says, Well, what I really need to do is be able to differentiate between a legitimate user click or a transaction compared to something that looks like one.

So I think a good solution is to design the application that has the application assign a random server side token that is not present in the cookie and that the applications expects it back when an important transaction is submitted by way of get or post. It’s a good idea to make this, make sure this token is random, hard to guess, and that’s not contained the cookie.

If the application will then have to embed this parameter at a static variable in HTML as it renders its HTML so that it can be echoed back by its browser for every important get or post request. So what this will do is it’ll make it impossible for someone to write a malicious site that submits to a particular URL, your URL. Because in order for that submission, by way of get or post to be successful, the attacker will also have to guess this random token that changes every time a user logs in.

MR: Which is unlikely.

ND: Exactly.

MR: Yeah, never impossible but certainly unlikely.

ND: Yeah. Yeah, if I may. One of the other things from the impact perspective for the Cross-Site Request Forgery that I think is really interesting, I think it’s interesting from the perspective of demonstrating the building of the parameter. Cross-Site Request Forgery facilitates an inside out attack scenario that provides more evidence to the hypothesis that the DMC based network parameter controls strategy is no longer as effective or as valuable as it has been in the past.

So consider the scenario where you have an HR or payroll application vulnerable to Cross-Site Request Forgery in the company’s intranet, so it’s internal only. Now, an internal employee browses to a vulnerable site on the internet, right. This vulnerable site can now make the victim’s browser perform a transaction on the internal payroll site.

So what you have now is an inside out, out attack scenario where the victim initiated the attack process by browsing outbound to the internet. So the interesting point is your -- in addition to blurring of the parameter is that the Web browser itself is a trusted piece of software because it has access to both the intranet and internet.

MR: Yeah, I think the -- one of the most interesting things that you said in the dialogue to me was it gets back to application design. This is not an attack that you can necessarily stop with an application, firewall, or any other type of mechanism because, again, you think it’s a -- if you’re the Website owner, you think it’s a legitimate transaction.

You really have to design additional validations and verifications on important transactions because we can't necessarily make the assumption that the browser is that trusted piece of security software. Because again, I think we’ve shown through history that the browser exploits tends to be the path of least resistance for a lot of the attacks nowadays.

ND: Yeah. I think from a tactical perspective, from what do we do now. I think you’re exactly right. I agree with you that we have to educate developers to make sure they understand that they have to build this thing by design. But that’s one way of looking it and that is the immediate fix. And if somebody asks me what would they do for Cross-Site Request Forgery against the enterprise, I would say you got to let your developers know that -- and this should be a design principle -- It should be building to their DNA of how they write applications.

But one of the other things that I’m kind of thinking about and I’ve had some debates with other security professionals is that sometimes in our jobs as security professionals is not only to expect developers to keep but with attack vectors, but to give them platforms and tools that make it impossible for them to write an application that is susceptible to Cross-Site Request Forgery even on progress, right.

So if you look at what Java and Dot net did when, there’s they’re kind of -- Java and Dot net want a virtualized environment, right. And so today, if you want to write a buffer overflow, an application vulnerable to buffer overflow in Java.net, you can't, right, because by design, it won't allow you to do that unless, of course, you’re attacking the reimage cell, which I don’t think it’s a fair argument. But I think what I want to see from companies like Sun and Microsoft who develop these applications that are code upon. I would love to see them come up with new ways of developing lab research that if I’m a developer, I can't even write an application vulnerable to Cross-Site Request Forgery even if I wanted.

MR: You bet. And I think that’s critical and I think that’s a great way to kind of wrap the first session about Cross-Site Request Forgery. It’s obviously a new kind of attack. It’s a new way of thinking this whole inside out approach of really attacking the Web application via the browser and that was just tremendous information. So now let’s transition into the old free association part where everybody is a long time reader or listener of the Mike Rothman Security Report, we basically just go through. I’ll blurt something out and then Nitesh I’ll give you a sentence or two just to give me whatever comes off the top of your head. So let’s start with PCI 6.6.

ND: PCI -- my response to any sort of compliance regulation like that is...be secure and you’ll be compliant and it does not work the other way around. That’s what the first thing that pops up into my head when I think about PCI.

PCI. A lot of corporations look at security from a compliance perspective first. And so what they end up doing is spending more money than they should. So may take a look at one application. You look at it from the PCI lens, you look at it from the SOX lens. You look at from any other lens and they end up spending on parallel efforts on these problems. What you should be doing is approaching it from a pure security perspective and then doing a gap analysis to see how you can satisfy these requirements. I mean these requirements like PCI are not there to make you secure, it’s for the reasons that I probably don’t want to get into but its not to make you secure.

MR: Right. Exactly. And I think that’s a great point. I think it’s also a matter of 6.6, specifically, hits on a lot of the application security issues and there’s just been a lot of confusion about it. But again, if you look at the problem from the standpoint of making sure that you’re protecting your data, especially, credit card data, that the other stuff tends to fall into line. So one more. What do you think about Black Hat, the big conference? I know you’re speaking there next. So just, give me a couple of thoughts on Black Hat.

ND: I love Black Hat just mainly for the social networking opportunity I get over there. As far as the talks are concerned, I spend less time going to talks than I used to because everybody has blogs now and everybody’s so well connected. Usually, what ends up happening is you have a researcher that’s blogged about certain things and if you follow him, and go to see his speech, you’re not going to really find anything --

ND: -- you haven’t heard about before. So I mean it’s a good opportunity for me really to connect with people. I think that is so valuable and that makes Black Hat and any other conference like that totally worth it. And if -- there are a lot of people who go in there for the talks also but I would really, really recommend that they branch out and connect with people. I think that’s key.

MR: You bet. Because people like you and people like me. I’ll be at Black Hat next week as well. So looking forward to seeing you there Nitesh. Thanks again for ---

ND: You too.

MR: --sharing some of your time with us and as well as a lot of your expertise about Cross-Site Request Forgery. Is there someplace -- you guys in the IT Enablement Group with E&Y have some kind of Website where you can point people to, or just to find out how to get in touch with you, or if you got a blog that people can read, or follow what you’re up to. Just why don’t you let people know how they can get in touch with you.

ND: One of the things with the IT Enablement Practice that it is so cutting edge and its so brand new, we’re working on a site. I don't have a URL for that yet but we will have one really soon. I’ve actually seen some designs of it. I’m really happy. But until then, my personal site is at Dhanjani.com.

MR: Great. So check out Nitesh. Again, thanks again so much and thank everybody out there for listening to another edition of the Mike Rothman Security Report here on the ebizQ network. We will see you next month.

ebizQ is proud to bring you Security Incite's Mike Rothman, who podcasts and writes on application security and related topics.

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT