Why Javascript Remote Procedure Calls beget more Cross Site Request Forgeries

This is going to be a long blog post. I've tried to cut it down, but I've been thinking a lot about this topic for over a year and it's hard to walk all the way through this vulnerability without explaining a lot.

A few days ago I posted a small rant about how there were no "web 2.0 vulnerabilities" that did not also affect older websites. While that's true, the increasing popularity of sites using various javascript RPC methods is definitely leading to a rise in XSRF vulnerabilities, and I wanted to write something on my thoughts on why that is.

I'm not going to talk about vanilla-HTTP-form-post-with-no-secret-token cross site request forgery here. That vulnerability has been about unchanged for a long time, and I'm going to pretty much ignore it- I don't have anything new to say on it at the moment.

In 1995, when I first had web access, websites were pretty basic in comparison to what we have now. To run, say, a search engine, you'd have a handler on a webserver that took user input and wrote out response HTML. It might branch off a new process to do a search, depending on the software, and then it would collect the responses and return them via HTTP to the browser.

Very shortly webpages started getting a little bit more complex. When these first dynamic web pages were made it was very difficult to decouple "backend" software from the pages that it generated. There might be a database behind the web site, and maybe that was on a different server. Most likely, though, the code that wrote to the database was wrapped up in the same binary that generated the HTML for the webpages and processed the inputs and all that was just on one webserver. Everything would be in, perhaps, 1 perl file and a few perl modules.

RPCs, Services, and tiers

So then, "services" started to appear. And front end code, that printed out HTML, was often split out into new binaries, and CSS arrived. So we got some decoupling of "code that writes HTML" from "code that inserts data into the DB" in larger websites. Soon, "code that inserts data into the DB" was moved off to another server entirely. It was the start of "multi tiered" websites.

This is a great way to build complicated websites, and there's so much written about multi tier website architecture that I'm not going to explain it here. We'll just note that the middle tier servers that, perhaps, performed various actions and returned data to the web front ends probably had a bunch of protections in place limiting who could talk to them and involving swanky authentication. And this was generally over internal network connections, entirely within a particular data center. More service layers might be written, caches added and so forth, but the general architecture was the same. So let's say that a site wants to display to a user "here are the groups you belong to".

Probably this was what happened:
1. the user clicks to a URL like "example.com/showmemygroups.cgi", and the browser sends her login cookie with the request
2. the webserver gets the request and determines it's user "annika" from the cookies
3. the webserver software assembles a request object for the groups that user "annika" belongs to and makes a request to a middle tier server over some networking protocol (over an internal network connection, remember)
4. the middle tier server works magic and assembles an object that holds annika's groups, then dispatches the result to the web server software
5. the web server parses the groups object and builds a HTML page to display the data. that is returned to the user's browser via HTTP

Web 2.0
In recent years, a lot of sites have realized that you can make RPC calls in javascript. (RPC = Remote Procedure Call. Again, there's a lot written on this on the web so I won't explain it much here) This is pretty cool, website applications no longer are bound by "click, load a page, click, load a page" and can now behave more like desktop applications. I think that this is a good thing in general. Again, many other people have written wonderful things about the rise of web services and Ajax and mashups and "the programmable web."

But now in the programmable web world, developers don't want to have to make the user go to a new page to see, perhaps, that they joined a cool group on a social networking site. They want to be able to show the user "here are your groups" on the page that they are on right now.

The browser rendering the webpage makes a GET or a POST to get the groups data, but it might talk directly to the server that used to be "the middle tier server" sitting alone in a data center and only speaking to the frontend web server. In the new model, it might talk directly to browsers. Or the code that ran on it might now run on our webserver. The data isn't just going over internal network connections, so you can't easily limit what IP addresses can make these RPC calls- it's now the users browser making the RPC call, from the user's IP address. The data that it returns is in a nice, portable format generally, like a javascript list.
Remember those steps above? Here's what they are now:

1. the user performs an action that triggers a "getGroups" function in the "myutilities.js" file (that the page we're on included)which perhaps triggers a getXMLHttpRequest (or similiar) call to the webserver. Then the browser sends her login cookies along with the javascript-triggered HTTP request.

2. the request goes not to the webserver software that wrote the HTML but maybe gets forwarded right to the middle tier (potentially via some URL rewriting on the server side or a some other methods)

3. the middle tier server inspects the cookies it was given, sees that they belong to "annika" and works magic and assembles an object that holds annika's groups, wraps it into a javascript list object, then dispatches the result to the browser

4. the browser takes the returned JS and writes it to the page that annika is viewing

So what just happened? For one, we changed who can make the RPC calls and who can access the data returned by it. And we changed the format of the request and the format of the response.

Notice how we lean only on cookies for authentication now. This is where I tend to lose people- there are still all those "determine user" steps in there, so it might look more secure. It's not.

An Explanation of what's broken
What happens in that scenario is that calls like <script src="http://othersite.com/myutilities.js"> - what we made above- can be placed on www.example.com -and then calls to its getGroups function will work. And the site is sending back data in a format that can be used on any third party website making the RPC call.

If we have a call to othersite.com's getGroups fuction on example.com, the user's browser will send the othersite.com cookies along with the getGroups function... even though the function was called from a page that comes from example.com. That just jumped us out of the usual javascript Same Domain sandboxing. The groups will come back in a javascript list and be readable by the javascript on example.com - we used the user's othersite.com credentials to request data that we want which we wouldn't be able to request on our own. I could maybe see MY othersite.com groups, but without this technique, I can't see Annika's groups short of stealing her password.

Where most of the security vulnerabilities arise that I've seen is that people don't stop to think about disclosing private data. I've seen a few account change actions disclosed this way, but not as many.

What's mostly happened is that there's been a wrapper put around some old backend libraries to expose them via javascript, and then those have been used on the site. Let me point out something here- even if we did not remove the "talk to web server, web server talks to middle tier server, middle tier server returns an object" steps, this would still be insecure. The fact that we can call this code from any third party site but have the orginal site's cookies get sent is what's insecure. And the format that the data comes back in allows it to be potentially read by the third party site.

Another clarification here- for private data disclosure bugs, we need to have the return data from othersite.com in a format that the rendering webpage on example.com can read. For account information changing bugs- where hitting a URL will, for example, mark that "I give this group 4 stars!", the return data does NOT need to be readable by the page on example.com.

Fixing this
Can this be fixed? Yes, absolutely. It's just that I've seen a lot of naive implementations of frameworks of this sort. And a lot of people try to fix this and fail.

What is a bad fix? Checking referral headers. There was a way to use flash to break that, and it was fixed (but who knows how many users upgraded their flash to the fixed version). And now there's a new way to do it again... I wouldn't rely on that staying fixed. Using POST only isn't going to cut it either.

What is a good fix? Make sure that you don't return a JS list or other eval-able JS code in step #4 above. Boobytrapping is good. I linked a few days ago to a site which shows good and bad ways to return data from RPCs, but here it is again:
http://jpsykes.com/47/practical-csrf-and-json-security

This post is really a work in progress because I'm still trying to figure out how to explain all this in a way that's clear. Criticism and feedback welcomed, my email is on my domain's homepage.

teensy

teensy
Originally uploaded by wck

Thomas actually isn't really so teensy- he's almost to 12 pounds. And still the cutest little nephew ever. I love this picture, which my sister took- it's my cousin Chad holding Thomas a few weeks ago. He's such a laid back little baby, so unlike Ana who was fussy and really loud when she was fussy.

Automatically fuzzing for XSRF

Planet Websecurity has a great blog post up about the state of XSRF testing. In particular, there's a section that calls out one of the big difficulties in writing an XSRF fuzzer that would be as useful as most XSS fuzzers. This is mostly due to the fact that fuzzers, as they are mostly written now, use input/output matching to automatically flag vulnerabilities.

It is hard to write a zero knowledge signature for XSRF that is *accurate*. - Planet Websecurity

(it appears that the original of this post is over on O'Reilly: The Complexities of Assessing XSRF Automatically Yet Accurately by Nitesh Dhanjani)

It's true, it's not simple. It's not impossible, though, to write a generalized XSRF fuzzer. First, the fuzzer should be able to record a web app login and use it for fuzzing. Then there are three things to think about:
* the fuzzer should try every GET/POST both with the login cookies and without them
* it should try every POST request that it came across as a GET as well
* it should try GET/POST requests by swapping different subdomains or swapping out the subdomain


The reason to do the first is to identify actions that react differently when the user is logged in/not logged in (and flag ones where it's different as potential XSRF surfaces). The second one is similiar- web developers who are aware of XSRF sometimes try to protect their apps by making requests only work through POST (hint to those developers- that's not a good fix). The last one is because those developers also try to protect their web apps by only taking POST/GETs that modify acct information on certain subdomains of their website. Sometimes they do this for the same reason as the POST-only limitation, and sometimes they do it because they're trying to protect against XSS.

Why? If there's an XSS hole on foo.example.com and all the account changing actions have to be done on abc.example.com, you can't use the foo subdomain XSS to do a XSRF request on the abc subdomain because of the javascript engine's sandboxing. In addition, foo.example.com cookies will not be sent along by your browser with a request to abc.example.com. Note that example.com cookies, though, go to both.

more web security

So it appears to me that when it's in the upper 70s and not too humid, Greenwich Village is one of the most wonderful places ever. This evening I had a nice walk across Washington Square park...beautiful. So wonderful. How many times am i going to post "OMG I love this city?" Probably a bunch more until the crush wears off. I really can't believe how lucky I am to get to be here.

I realized this afternoon that googling for "json xsrf" will pull up my December post on this topic in the first set of Google results. That's pretty scary, seeing as I totally waved my hands around on that post and said "be careful" and not much more. And, well, I'm a big webapp sec nerd, but I'm not a javascript expert and certainly not anything like one of the most knowledgeable people on webapp sec.

If you want to really learn something useful about how to secure your JSON from XSRF holes, go read these two blog posts instead:

* http://www.matasano.com/log/752/fortifys-announcement-about-jeremiahs-attack-decoded/
* http://jpsykes.com/47/practical-csrf-and-json-security

What really concerns me, though, is that there is a lot of FUD out there about "web 2.0" security. There are no web application vulnerabilities that apply ONLY to "web 2.0 websites" (whatever those really are). XSS is still an issue, but getXMLHTTPRequest does not, on its own, make that any bigger of an issue. Really, there are very few actual new web application vulnerabilities. (I'm still digesting the stuff about registered URL handlers- I think that might be a new one, although it's obviously also tightly coupled with xss and xsrf.)

If you want to shut down XSS entirely on your site, there's very little you have to do.

1. escape <, >, single quotes, double quotes, and backticks in EVERYTHING you EVER get from a user, even if it's a cookie value that you think you put on their computer, even if it's a text string you think you're just writing to a database and never looking at
2. Explicitly set your charsets on every single page
3. Rewrite any user uploaded images that you present back to other users
4. escape or strip out every \r\n
5. be mindful of your charsets and character encoding

There. I swear, that will get you 99% of the way there. Ok, yes, re-writing images is a holy pain in the neck. but necessary.

XSRF is a little harder. Not much, but it's not as dead simple as XSS is. There is one fix for it that will work incredibly well, but you had better not have a XSS hole on your site and you need to devote the computational power to fix it.

1. Generate secure one time tokens for all of your "account modification requests" (for lack of being able to think of a better phrase)
2. Now check it on every single request and never ever let user B's token work on user A's information

That will cure most xsrf problems... if you don't have an XSS hole on your site. If you do, go google "samy is my hero" to see why you're hosed. One of the interesting parts of security web applications is that all of these vulnerabilities play together. You can do a lot of dumb stuff with XSS like drawing new login boxes to go phishing with, but you can also leverage it to expose xsrf holes in an otherwise secure web application. It's all a big house of cards, because of the statelessness of the web (even so called 'stateful web 2.0 apps' are not really stateful. they fake it by and large) and the craptastic rendering engines we have out there.

Like I posted back in December, and as the two JSON/XSRF blog posts above discuss, you need to think a little more about what information you pass back in JSON, or use it in a way that will protect you from yourself (ie only return code that needs to be tweaked before you eval it). The way that <script src> breaks out of the javascript sandbox is confusing. Go read those blog posts above, they're clear and come with actual sample code.

I was talking with a web dev today about why he had a XSRF hole with some RPC calls that used cookie authentication and returned JSON. He inadvertently pretty much summed up why we have web application holes despite this stuff not being rocket science. He was saying "but we modify the RPC's response before we eval the code... oh wait, just because we modify it doesn't mean you have to. I see, I need think about what other people can do not what we do." That is pretty much what all this rambling sums up to.

I'll write something soon summarizing web services and feed vulnerabilites, but as I noted above about so called web 2.0 vulnerabilities... it's nothing new and it's nothing that only touches them. And of course none of this even touches on SQL injection, buffer overflows, or attacks on specific pieces of software such as exploits against the linux that a particular website might run over.

apricot sunset

The sunset from the train window this evening is a fantastic apricot color. I just had a great evening walking around Greenwich Village with a friend- we got sandwiches, got lost, walked past the house where my maternal grandma grew up, and then got some delicious hazelnut gelato. Yum. It was an evening to remind me why I moved to NYC, there is really no where else quite like it. I do miss Belltown incredibly and I'm looking forward to spending a few weeks there soon, but it's hard to top the Village when the weather is perfect on an early Friday evening.

And to go with my appreciation of life as a Jersey girl, I'm listening to some 80s hair metal music on my ipod- Jump, Come on Feel the Noize, Lay Your Hands On Me. Also in there is Hunger Strike by Temple of the Dog because I realized recently it's long been one of my underappreciated favorites. I'm sitting sideways on the train, watching the sun setting out the opposite windows, just enjoying the glimpses of the sun through the trees as they run past. If summer could last forever I would freeze it right here.

USCGC Biscayne Bay

lifering
Originally uploaded by wck

I need to find my old HEALY photos. Would someone like to volunteer to find them on one of my old backup CDs? I've been on vacation, but I haven't gotten anything useful done with all this time, like organizing my photos. So here is one of the few photos from Dan's boats that's on flickr, from the USCGC Biscayne Bay in Michigan.

going places

My to-visit list next week:

* Ryan told me that decent lattes are available in Manhattan! at 9th St Espresso. I didn't make it this week, so I plan to go next week
* Battery Park City. I've never been to it, and it sounds like an interesting place to see
* The Christopher St PATH station, to see how long the walk to SoHo from it is

navy blue

This evening I stumbled over an old blog post I'd written about remembering what Dissolved Girl sounds like. It made me pause for a moment and think about my color memory vs my sound memory. I stopped at MJ Trim this morning to pick up a ribbon to match some green and blue material, and I've got the ribbon I picked out next to me. I haven't yet laid it next to the fabric it will go with, but I don't need to. For whatever reason, I can picture colors of things I've seen perfectly in my head, and when I looked at ribbons this morning I could see the exact olive and navy shades that I needed to match. Compared to my memory of songs, which are little soft, too loose, memories that unravel rather than get crisper when I dive in closer. Anyway. I like my color memory, but I wouldn't mind having a better memory for songs. When I read a lot of what I've written about music, I talk about what I see when I hear it and describe it in terms of spaces it suggests. I have a one track visual mind sometimes.

Kittah

This page, on the evolution of "kittah"/"lolcat" speak, was making the rounds today, and since I wanted to bookmark it so I'd be able to find it in the future, I figured I'd just toss it up on my blog.

A Special In-Depth Analysis of the cat image macro speak world.

On a similiar note, I was thinking this week about 1800s era novels. There's a particular feature of many of these novels that characters are called "Mr. R---" or "Mrs. L---". It's kind of cute, and occurs in a lot of writing from that time. This came up because I had four different conversations with friends who I've worked with in the past/work with now and in each coversation we were typing "A" and "G" (where "A" == amazon.com and for today you can guess what "G" is). This occured independently in each of those separate conversations, and it occured to me that it's a sort of convention among some circles these days to refer to employers by a single letter. For one, it's much shorter to type, but for another, it's a weak defense against the monitoring of email/IM/network traffic/etc that we all know goes on. It's just a little quirk that I noticed, and I was kind of fascinated how conversations adapt to limitations like the realization that the text being transferred between the participants is almost certainly being logged somewhere. Anyway, go read the kittah blog post. It's a neat analysis.

Thomas

Thomas
Originally uploaded by wck

Isn't he just the cutest little boy ever? He's finally waking up a little and peeping around instead of sleeping nonstop.

a snowy treat

I almost burned to a crisp walking through the West Village today (easily 90F) so here's a nice, cool, snowy treat- Declan in a rare Seattle snowstorm!

Lullaby of London

I haven't posted about music in a long time, and certainly not the long essays I used to write. One part of that is that I've been too busy to track down new music much these days, and I'm now cut off from Amazon's great music editors.

One piece of music that I've recently fallen for, though, is "Lullaby of London" by the Pogues. It's probably about as old as I am these days but it's a beautiful song. When I first moved to NYC, I was working in Times Square, but moved down to Chelsea at the end of last summer. Midtown and Times Square are quite literally the canyons of NYC while Chelsea and the West Village area are not so tall. One bitterly cold day this winter, I set out up 7th Ave to walk to Penn Station, with the Pogues playing on my ipod. As I walked up 7th, wrapped and bundled in a coat and scarf to my eyes and still shivering, I sort of fell into this song. As I kept walking, the huge towers of Midtown started looming over me, making the wind sharper and colder and darker. It all fit together, the appearance of the gray bleakness near Penn Station, the cold, this incredibly beautiful song. Whenever I have to walk up 7th Ave, even now in the warm spring, I try to play it at least once, as it's so tied to this one area for me.

Lilacs and Rhubarb

I left work early today, and my grandpa met me at the train station so that we could pick rhubarb. While we drove over to his farm, which is very close to the train, we talked about the Mets game I'd seen yesterday (I'm a lifelong Yankees fan, but I will happily admit that was a truly inspiring 9th inning yesterday!), and baseball games he went to when he grew up in Quincy, Mass. Then we went out to the field and picked tons and tons of rhubarb. As always, he tried to get me to take a bite of one of the stalks, which I didn't fall for. Rhubarb with strawberries and lots of sugar in a pie is wonderful. Raw rhubarb is...bitter.

Their lilacs are all blooming, so I also picked some of those, and a bit of arugula. What inspired this blogpost is that I just yawning and rubbing my forehead and I smelled the rhubarb and lilac on my fingers still. That's what spring always smells like to me, a sharp mixture of both tangled together.

Kate on the Train

Kate on the Train
Originally uploaded by wck.

and to go with my other train post, here is Kate riding the train into NYC

sunrise

Sometimes I wonder at the ability of my brain to drive down to the train station and get on the right train on basically autopilot every morning. My brain is not particularly functional before I've had 2 cups of coffee, and I only have one before I leave home. This morning was a nice example of how useless I am uncaffinated; last night I'd sat on the right side of the train heading out from NYC and had horrible sunglare in my eyes the whole way. This morning in picking a seat my logic was:
1. the right side of the train had glare going West
2. we are now going East this morning
3. so that means that the right side of the train is on the other side in this direction
4. I'm sitting on the right side
Of course, you see the flaw there, right? Yes... the sun comes up on one side and goes down on the other. So I'm riding along... with the sun right in my face again. Oh well!