Question

We all know how hip it is to make our Ajax calls using address routing and HTTP-Get with parameters in the URL because the client side can cache those calls and thus server load is reduced, but where do you guys think the line is between “a neat way to address resources” and “disclosure vulnerability”? I’ll give some examples-

Let’s say I’m on my bank’s website. In the background, my browser is HTTP-Getting to /onlinebanking/AForster/transactions. Of course I’m very paranoid about people knowing my bank account login ID, so I always make sure “remember me” is unchecked. However, does the fact that my browser accessed a URL with my login ID in it constitute a disclosure vulnerability?

What about if I’m on a forum, and I’m reading a restricted thread that normal users shouldn’t know exists. My browser retrieves the contents of a thread by doing an HTTP-Get to /forum/Secret-Board/Im-Going-To-Kill-My-Brother/posts. Does the fact that I even accessed that URL with Ajax somehow reveal the existence of that thread to my brother?

Etc, etc. You can probably think of more scenarios. I really want the benefit of caching my Ajax calls on the client side, but in these instances, would Ajaxing to these URLs be considered a disclosure vulnerability?

Answer 1

So you’re question raises a couple of points that I wish I knew more about, but I’ll try my best to at least map things out…

Your browser is caching URLs that have private/secure information in the path, thus leaving a potential window to your private info to others. The implications:

1. Someone could walk up to your computer when you are away, or, perhaps access your computer remotely, or — if the proper precautions aren’t taken on several levels — use an XSS method to get your cached URLs via javascript.

And the concern is legit, but you have already indicated what some of the steps you can take to aleiveate them are:

• Don’t have multiple windows open, some private, some not-so-private. Use private browser sessions for your private browsing. I actually had an idea for a Firefox add-on that would allow you to create a “dark list” of sorts, a list of domains that should always be in Incognito mode. That way you can be on your bank site, hop over to twitter, and it knows to have different sesssions, etc.

• Set your browser to delete (or at least ask to delete) all personal data on each close.

• On the server-side, no responsible web-app designer should EVER use credentials or personal data in the URL for a secure site. That’s not slick, that’s lazy. I think ID numbers or session ID’s isn’t much better (I’ll get to that in point two). Your bank should use: /onlinebanking/UserServices/transactions as the RESTful url and should be confirming everything on each request, down to the IP, at the server level (mod_auth and a damn good cert). I get very exhausted hearing people talk about “reducing server load” or even “reducing database hits”. The software is explicitly designed for receiving LOTS of requests. My HP laptop built 6 years ago that sounds like an old refrigerator was NOT designed to ease the server’s work-load, and waiting 10 minutes for a poorly designed js script (see : new Yahoo! Mail client) makes me want to stab. And if there is nothing else the poor abused gigantic server should be expected to handle, it should be ensuring your security EVERY time.

Okay, that rant is over.

• Can your brother see your cached URLs? Maybe. My girlfriend can tell when I’ve hit up the xxx sites even when I clear the history (why? because it still shows up in recently closed tabs! Yay privacy!) And those aren’t being cached for RESTfulness, they are being cached cuz that’s what browsers do. So you should taken the same precautions after going to a site withiamgoingtokillhimtonight/postsin the URL as you would to cover your…self…when you’ve gone to the pron sites or when you’ve been looking up birthday present ideas.

On to part to of my interpretation:

So yes, the URLs are cached and that’s creepy for anyone who wants to peruse said cache to get in your business. But it seems the other concern you are expressing is what they can do with it, ie cross-browser-exploits. Can someone use that cached URL to make a script to get to your actual bank info and wipe you out? Yes. But, the advantage they gain if they already know how to do this is slight. It’s more like saving them a step then leaving your keys hanging in the door. If I can somehow see your cache via js, and thus see your secure bank URL, then I could just as easily see your bank’s URL if they didn’t use a cute URL, and just as easily write my XSS around it. And if I can see your cache, I can most certainly see your cookies and steal those (only on the web are cookies worth more than cache). So the same rules pre-AJAX apply:

• Users shouldn’t write down passwords
• Session cookies should expire at the end of sessions
• web apps need to use white-lists, certs, and nonces to secure the integrity and authenticity of the user’s requests.

I can not emphasize enough how much XSS success is based on the laziness (or ignorance) of developers (myself included) and the confusion and naivety of users. Most really big XSS scores involve social-hacking prior to internet hacking. A phishing scam or a letter from an old friend or Spanish prisoner, simply asking you to follow this innocent link or share some meaningless personal info. The one thing I could see with your bank example that would make it worse is that now I know from this site that your first name is Alex and from the URL that your last name is Forester. This may make digging up details to con you out of other information easier.

So the long and short of it, finally:

RESTfulness and AJAX doesn’t pose much more of a threat then browser history and bad server-security ever has, and so the same rules apply both to users and to developers. But you are totally right that such RESTful URLs point out that we are getting worse about these practices instead of better; using the technology to be lazier instead of using the advantage to focus on the real hard work.

Well that was fun. Back to the salt mines.