beer planet » xss

How Not To Implement A Web Application That Handles External Authentication, Using BeTwittered.com As An Example

Artem Russakovskii — Thu, 04 Feb 2010 02:29:04 +0000

Today I'm going to look at how not to handle user authentication in a web application, taking BeTwittered.com authenticating with Twitter as an example (sorry, guys).

BeTwittered is a simple and comfortable gadget that you can add to your site, such as your iGoogle homepage.

Since BeTwittered is just a bridge between you and Twitter, it has to first log you into your account. Here is where things go horribly, horribly wrong.

1. BeTwittered does not use SSL to secure requests to its servers

All authentication information is transmitted to BeTwittered servers in plain text and is easily sniffable by an attacker, both on your own network and outside of it. You can read more about SSL encryption here.

Since BeTwittered passes your Twitter username and password unencrypted as GET parameters, it may as well be serving them to potential attackers on a silver platter (note that passing this data in a POST request would change nothing, security-wise).

Here is an example request:

http://betwittered.com/api/?_=1265242511260&req=verify_credentials&username=foo&password=bar

Ugh…

2. BeTwittered stores your username and password in unencrypted cookies

Because BeTwittered tries to keep you logged into Twitter, it caches the username and password, unencrypted, inside browser cookies.

This means that an attacker needs to simply look at your cookies to steal this information. This can be done using these methods, among others:

using an XSS vulnerability
sniffing the network traffic
walking up to your computer

3. Because BeTwittered passes your authentication information to its servers, it's already insecure

If someone gets access to BeTwittered servers, it's safe to assume at that time that all accounts are potentially compromised.

Smaller sites generally cannot dedicate appropriate resources to securing their servers, which can make breaching them easier for hackers. Even Twitter itself was hacked numerous times.

The Alternative Solution

oAuth

If the endpoint application supports oAuth (Twitter has for months), do us all a favor and use it. Please.

oAuth allows delegating authentication to Twitter itself and only giving the application easily revokable limited access.

If BeTwittered were using oAuth, the user would be redirected to Twitter, where he or she would login. Then, the user would be sent back to BeTwittered, but now bearing special tokens. Any requests to Twitter would then be accompanied by these tokens, which would be validated by Twitter every time they're used – all of this without ever passing your password around.

You can find a nice overview of the oAuth architecture here.

Otherwise

If the endpoint application doesn't support oAuth, then

use SSL encryption (https)
store the authentication information on the server side instead of the client side in a cookie. Instead, use the cookie to store some sort of an internal ID pointing to this server-side data. Alternatively, encrypt the username and password via a secure salted two-way hash and only then store the encrypted version in a cookie
make sure to stay on top of securing your servers (and give your sysadmin a raise). It's a time-consuming commitment, please take it seriously

Conclusion

What other secure authentication technique or tips do you know about? Feel free to share in the comments.

Oh, and this goes without saying – stop using BeTwittered, at least until they implement a more secure login option. I've alerted the creators about the issue and also started these threads on HN and Reddit.

Modern-Day Frame Busting With X-FRAME-OPTIONS And "This content cannot be displayed in a frame" Warnings

Artem Russakovskii — Fri, 30 Oct 2009 01:10:32 +0000

Today I found out something entirely new about framebusting and specifically clickjacking protection techniques.

I was working with a site that was using frames. Suddenly, one of the frames (which was hosted on a domain that differed from the one it was embedded in) displayed the following message (in Firefox 3.5.4):

This content cannot be displayed in a frame
 
To protect your security, the publisher of this content does
not allow it to be displayed in a frame.
 
Click here to open this content in a new window

Notice how this is a native Firefox window and not a web page rendering. Quite stumped, I started looking at the frame response and finally found that it included this little header:

X-FRAME-OPTIONS: DENY

Turns out that modern browsers like ~~Firefox 3.5~~ (turns out it's the NoScript addon that does this and not Firefox itself) and IE8 treat this header as a precautionary measure and display a generic "warning" to the user instead of the page content in certain conditions described below. This effort, led, surprisingly, by Microsoft, was really to protect users from clickjacking (I wrote about clickjacking here earlier) but can be viewed as an alternative to framebusting.

Microsoft introduced the new X-FRAME-OPTIONS header with the following possible values:

DENY – prevents the page from being rendered if it is contained in a frame
SAMEORIGIN – same as above, unless the page belongs to the same domain as the top-level frameset holder.

~~Firefox adopted this technique a few months later~~ (again, I was wrong here – it was NoScript that did it), and I expect other browsers to follow.

So what does it mean to you, the developer?

setting such a header will essentially render frame busting code unnecessary in modern browsers
but it has a downside of displaying a relatively ugly warning to the user
no automatic redirect is done as your page (including any framebusting code) is not loaded
thus requiring an extra click
and popping up a new tab or window
it will work even if the user has Javascript disabled, which is more secure

Some useful discussion on the issue can also be found in this post on Hackademix.net.

So is it good practice to use this new X-FRAME-OPTIONS header instead of the traditional framebusting code? I definitely think so, especially if Firefox and other browsers start supporting it. What do you say?

How To Fight Clickjacking (Using The Recent Twitter Hijacking As An Example)

Artem Russakovskii — Thu, 12 Feb 2009 19:43:53 +0000

Introduction

Clickjacking is a malicious technique of tricking web users into revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. A vulnerability across a variety of browsers and platforms, a clickjacking takes the form of embedded code or script that can execute without the user's knowledge, such as clicking on a button that appears to perform another function (credit: Wikipedia).

Clickjacking is hard to combat. From a technical standpoint, the attack is executed using a combination of CSS and iFrames, which are both harmless web technologies, and relies mostly on tricking users by means of social engineering. Additionally, the only server side technique against clickjacking known to me is “frame breaking”, which would cause a legitemate site to break out of any iFrames it may be embedded in. This is not always the desired behavior and is generally frowned upon.

XSS and CSRF are examples of similar malicious web attacks.

Generic Example

In laymen’s terms, clickjacking means that it is quite possible for websites to trick you into, for example, clicking a button to show a cute kitty while in reality prompting a deletion of all your hotmail email. A malicious site uses an iFrame (which essentially allows embedding sites within other sites) with hotmail loaded inside and hidden using CSS (which is a web language for styling HTML elements). A button named “Show Me The Next Awwww Kitty” is then placed by the malicious site and positioned below the iFrame layer (manipulated by CSS, yet again). However, because the iFrame is hidden, it looks like the “Aww” button is all you’re clicking. Wrong!

Latest Example: Twitter

This morning a new, though harmless, epidemic hit twitter. Hundreds and thousands of messages saying “Don’t Click: http://tinyurl.com/amgzs6” started showing up. Clicking the link shows a simple page with 1 button:

Clicking (which I of course did) uses clickjacking to repost the message to your own twitter account. Take a look yourself: http://search.twitter.com/search?q=don%27t+click.

All of these are a result of an experiment by some French guys to mess around with twitter and show the effects of clickjacking. Thank you for that, French guys. Creating awareness via the most social platform on the web is the best thing they could do for us.

Twitter rolled out a quick fix, using the very “frame breaking” technique I mentioned earlier. Now any site trying to embed twitter in an iFrame will redirect to it.

Fight Clickjacking

James Padolsey recently wrote an excellent blog post about clickjacking and mentioned Twitter specifically. Because clickjacking relies mostly on social hacking (i.e. tricking people into clicking malicious links and buttons), Twitter is nothing but a perfect platform. James gives some nice background info and code examples. He correctly highlights, as I did earlier, that clickjacking is not a software bug – it’s a malicious technique exploiting harmless technologies.

So how does one fight clickjacking?

At this point the most reliable way is to use Firefox and the NoScript extension. NoScript provides a simple, yet amazingly effective feature, called ClearClick. From their site:

“…it's enabled by default, protecting NoScript users from Clickjacking everywhere: it even remains active if you switch NoScript in the less safe Allow scripts globally mode. How does it work? Clickjacking hides or displaces or partially covers something you wouldn't want to click, if you could see it in its original context. ClearClick does the opposite: whenever you click a plugin object or a framed page, it takes a screenshot of it alone and opaque (i.e. an image of it with no transparencies and no overlaying objects), then compares it with a screenshot of the parent page as you can see it. If the two images differ, a clickjacking attack is probably happening and NoScript raises a "ClearClick warning", showing you the contextualized and "clear" object you were about to click, so you can evaluate by yourself if that was really something you wanted to do.”

Did ClearClick work in the earlier twitter attack? Sure did! After I clicked the “Don’t click” button Noscript promptly popped up a warning showing the hidden iFrame (since the original malicious page has been removed, I found another similar page from the same author for screenshot purposes).

So, even if you don’t want to enable NoScript globally, install it anyway, just for ClearClick.

Using a browser other than Firefox? The best technique you should use is, as a general rule, don’t click on suspicious buttons and links on pages you are not familiar with. Remember: you’re on the Internet and it is full of traps.

That about covers what I had to say about clickjacking. Stay safe, folks!