Opting-in to plugins in Firefox

11 April, 2012 § 84 Comments

Whether you hate them or love them, content accessed through plugins is still a sizable chunk of the web. So much so, that over 99% of internet users have Flash installed on their browser. However, plugins can also carry with them extra vulnerabilities and system slowdowns.

A couple days ago I landed an initial implementation of “click-to-play plugins” in desktop Firefox. To see and play with the feature, download a Nightly build of Firefox, go to about:config, and enable the plugins.click_to_play flag.

When plugins.click_to_play is enabled, plugins will require an extra click to activate and start “playing” content. This is an incremental step towards securing our users, reducing memory usage, and opening up the web.

I’m currently working on implementing the ability for plugin activation settings to be remembered on a per-site basis. I hope to get these changes landed within the next week before the deadline for Firefox 14.

If you are curious and want to learn more about our plans for opt-in activation of plugins, you can take a look at the feature page on our wiki.

Two-step authentication: a necessity for secure webapps

21 June, 2011 § 2 Comments

Recently, my girlfriends Gmail account showed that it had been accessed from Poland, France, and the United States, all within a couple hours of each other. This breach of security was horrifying, and pointed out how easy it can be for someone to access another persons account.

We’re not sure how her password leaked. Maybe it was through a phishing site or some malware/key logger on her machine. But that was neither here nor there. The plain fact is that her account was granting access to unknown parties without her permission.

Not too long ago, Google announced 2-step verification for Gmail. With 2-step verification, the user logs in with their password, and then enters in a code that was obtained using their mobile phone. A friend of mine also uses a similar procedure for his World of Warcraft account.

I’ve signed up for 2-step authentication as well, and don’t mind the subtle inconvenience. If you are a Gmail user, you should try it out today.

Features like these make account security much stronger, and it is time that more secure websites start offering it (especially online banking).

The (lack of) security at PayPal

18 June, 2011 § 2 Comments

PayPal has had a tough week in the news. Earlier this week, a user claimed to find a way to reset an arbitrary account’s password through the Forgot Password workflow. From his description, it seemed like a low-sophistication attack (aka something he accidentally stumbled upon).

Much of the reaction on Hacker News was to quickly remove your bank account from your PayPal so an attacker wouldn’t be able to steal your money.

As I saw the news, I quickly logged in to PayPal to remove my bank account. I had about $25 sitting in my PayPal account, so I decided to transfer the remaining funds to my bank account before disassociating it. Except it turns out when you do this you lock the association of your bank account for up to 3 to 4 days.

In the meantime, I decided to update the primary email address on the account to one that I check more often. I typed in my newer email address, they sent me a confirmation to the new email address, and I was done. Wait… I was done? It was that easy?

They never gave my older email address an opportunity to cancel this new primary email address. I logged in to my older email account and saw an email from PayPal saying that my primary email address had been changed and if this was a problem to call them. Huh?

So not only can someone claim a way to get access to any PayPal account, they can also change the primary email address of the account without giving the owner any opportunity to stop it before it’s too late?

PayPal needs to make a lot of changes

There is no way that I can cover all of the things that PayPal should do to protect their customers, but I can try a few.

First, they need to give account owners an opportunity to guard themselves against people changing crucial account information. It shouldn’t be so easy to add/remove an email address from the account.

Second, they need to advertise their Security Key feature (aka two-step authentication) more prominently. I didn’t know that they had one until I started writing this blog post.

Third, they should set up a secret passphrase that is included in all emails from them. The bank that I use does this, and it is a very low-tech but successful way to know if an email is from a phishing scam.

Fourth, it turned out that the security vulnerability the original user claimed wasn’t the security vulnerability that had been found. PayPal doesn’t require you to confirm your email address before you can continue with creating your account. Some user signed up with this guys email address and that is how he got access. None of this would be news if they required you to confirm your email address.

Last, PayPal needs to do a better job responding to these allegations. At least let people know that you are looking in to the issue.

XSS Prevention in GMail

28 February, 2011 § Leave a comment

Many popular web applications use JSON as their data interchange format. The format is very compact, easy for humans to read, and is based on a subset of JavaScript.

I’ll start by showing an example. Consider a website that wants its clients to query the server for the most recent 3 public messages. The client may send a GET query to the following address: https://mail.google.com/recent_messages/

The response can be written as follows:

var messages = [
   {"user": "foo", "m": "I like turtles", "t": 123423550},
   {"user": "bar", "m": "Turtle power!", "t": 1234543245},
   {"user": "baz", "m": "Cowabunga dude", "t": 1234567643}

When mail.google.com requests this JSON feed, it could then run eval() on the source code. Afterwards, it will have a messages object in global scope that it can reference.

This could work out good for GMail, but it can also allow other websites to make the same call. Modern web browsers will not allow asynchronous HTTP requests to cross domain boundaries, so it is easy to think that this is safe. However if the location is added as the src attribute of a script tag, then the browsers will load the content.

To work around this, GMail adds while(1); to the beginning of the JSON response.

When requesting JavaScript through a script tag’s src attribute, the DOM does not give access to modifying the content of the response. This keeps the while(1); present. If a client tries to eval() this JSON request, their browser will simply hang.

Pretty interesting, huh? There still are workarounds that can defeat this, such as setting up a server-side proxy that will make the request and strip the while(1).

If you’re looking for more details, Adobe Labs has a page on their website that covers Preventing the Execution of Unauthorized Script in JSON.

JavaScript Injection proof of concept

26 February, 2011 § Leave a comment

Following up from my previous post about XSS Session Hijacking in Google Gruyere, I decided to write a post covering a JavaScript injection vulnerability.

The color attribute on profiles lack input validation, and thus are susceptible to JavaScript injection. Simply put, this means that a user can edit their profile and insert code that will run on the computers of other users.

Some of the possible uses of this attack would be to:

  • Spam the user with advertisements
  • Increase visits to another website
  • Spread malware

In this proof of concept, I used the following as the “color” setting for my profile:

red' onmouseout='window.open("http://www.msu.edu/~weinjare/ad.html", "", "height=220,width=450");return false;

The JavaScript for the onmouseout event handler will launch a new popup window that could include spam. This code will be executed if the visitor moves their mouse over my username.

I’ll try to explain the source code above. The HTML that is generated for the page uses single quote characters to specify attributes. Adding a single quote to the setting, appearing after the word “red”, allows arbitrary HTML to be injected within the page. The following code is treated as another attribute for the element, adding an event handler for when a mouse moves on to the element and then leaves the element.

The value of the attribute starts with a single quote and lacks an ending quote. This is because the generation of the HTML will append a single quote to the value. This will allow the generated HTML to remain valid.

To show this in action, I created the following video:

Where Am I?

You are currently browsing entries tagged with security at JAWS.