Thursday, November 11, 2010

Protecting Yourself From Firesheep with Strict Transport Security

Strict Transport Security is a great solution to protecting against Firesheep

Now ultimately the vulnerable website is supposed to fix this issue on their side. But, let's not wait around for them. Let's fix it on our side and protect our traffic now.

Step 1: Grab a browser that supports Strict Transport Security (Firefox 4 & Google Chrome both support STS)
Step 2: Install an addon that lets you add specific STS settings - STS-UI
Step 3: Configure STS-UI for the sites you're concerned about
Step 4: Be happy your data is more secure. However, securely transmitting data is only one piece of the security pie. But at least you're good in that department.

Configuring STS-UI
Go to tools->Manager Strict Transport Security
Enter the domain name of each site you wish to protect (e.g. force Strict Transport Security upon the site). For example enter "" and select "Force subdomains too"

 After adding and it should look like this

Done. Now you will always be using HTTPS for data exchanged between twitter or facebook.

Remember, this only protects you against sites that are either already using STS or sites that you have manually added.  This really isn't a scalable approach since could be vulnerable and you wouldn't know unless you inspected the traffic going back and forth.

For those that have access to company VPNs or SSH tunnels for their traffic, I'd recommend you also use those when accessing the network from a wireless hotspot. A VPN doesn't solve the problem, but it does remove access from the likely attackers (e.g. other random users of the wireless hotspot).

-Michael Coates

Saturday, November 6, 2010

Security 101 Flaws in Mobile Banking Apps

It might be a new platform, but we seem to be repeating the same old flaws yet again. - Banks Rush to Fix Security Flaws in Wireless Apps  

Poor designs are being made for the fundamental security design of mobile banking applications. Think clear text username and password stored on the client device. 

This would be an obvious mistake for a normal web application, but the risk is magnified when we move from a model where clients are using desktop/laptop computers into mobile devices that are much more prone to be lost or stolen.

In our rush to get new apps to the market, let's not forget our basic security design principles.

-Michael Coates

Thursday, November 4, 2010

Spotting Websites Vulnerable to Firesheep

Part 2 of the firesheep series (Part 1 - understanding firesheep attack)

Here is an easy way to determine if a website is vulnerable to the Firesheep attack.  (For the record, technically Firesheep is just a tool to easily exploit a website that does not send session cookies over TLS/SSL. You could perform this same attack with any number of tools.)

Easy Detection

An easy way to spot a vulnerable website is to look at the URL. 

  1. When you login is the URL HTTPS?
  2. After you login does the URL become HTTP?
If the answer is yes to both of these questions then the website is vulnerable.  Unfortunately answering no to question #2 does not necessarily mean the website is securely designed. Here is a better approach.

Fail Proof Detection
  1. Start up your favorite proxy tool (burp, webscarab)
  2. Login to the website
  3. Inspect the HTTP responses and look for the set-cookie
  4. For every set-cookie you should see the word SECURE at the end.  If you don't see that word then the website is vulnerable.
Vulnerable Example from Twitter:
HTTP/1.1 302 Found
Set-Cookie: auth_token=; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: lang=en; path=/
Set-Cookie: auth_token=b34e2aa91082da041371a9891db49333084f9b94;; path=/
Set-Cookie: _twitter_sess=BCh7DEoYcGFa37ec2bfd81b513a7;; path=/

Secure Example from PayPal - Notice "Secure" used for every cookie
HTTP/1.1 200 OK
Set-Cookie: navcmd=_login-submit;; path=/; Secure; HttpOnly
Set-Cookie:; expires=Tue, 03-May-2011 22:33:38 GMT;; path=/; Secure; HttpOnly
Set-Cookie: flow_back_cookie=;; path=/; Secure; HttpOnly
Set-Cookie: _3P0VieXqbXBuy=IuyJVqQ0CViZZuzOezihVTUgbUPrVsFvb56TSu;; path=/; Secure; HttpOnly
Set-Cookie: navlns=0.0; expires=Wed, 30-Oct-2030 22:33:38 GMT;; path=/; Secure; HttpOnly

A site could be designed to only use HTTPS and may argue that the SECURE flag is not needed. However, this is just not true. While that scenario is considerably more secure than the Facebook design (HTTPS login and then clear text cookie exchange) the website would still be vulnerable to session hijacking attacks that force the browser to send HTTP requests to site and thereby expose the session id in the clear.

A great table of popular sites and whether they are vulnerable or not can be found at

Post #3 in the Firesheep series: Protecting Yourself From Firesheep

-Michael Coates

Understanding Firesheep Attack

The recently released Firesheep tool caused quite a buzz.  Packaged as an easy to install Firefox add-on, the tool allowed an attacker to quickly identify nearby users that were insecurely accessing popular websites. The tool's easy to use design allowed a user with basic computer skills to see pictures of the vulnerable users in a buddy list style text box and enabled the user/attacker to simply double click on the user's picture in order to completely take over their account.

Brief aside: While I do work at Mozilla, this post is primarily focused on explaining the underlying website security controls that have failed to enable such an attack. To learn more about Mozilla's view of the Firesheep plugin I encourage you to read the post at the Mozilla Security Blog.

Why Is This News?
Firesheep does not exploit a new vulnerability. The vulnerable design of sending authenticated cookies over an unencrypted channel has been known for years. The reason Firesheep is making news is because of the ease of use to execute an attack and exploit this weakness in popular websites such as Facebook and Twitter. Perhaps all of this press, and a few angry users that are victim to unwanted status updates or tweets, may result in these large social networking sites actually fixing the issue. 

How Does Firesheep Work?
First, Firesheep does not steal the victim's password that they are using with a website (twitter/facebook/etc). In fact, the passwords are correctly and securely sent to those websites. Instead Firesheep steals the session identifier for the user. The session id is a long random number that is used to represent the user after the user has authenticated to the website with their username and password.  Without session ids a user would need to send their username and password with every request. The session id was created to eliminate this inconvenience and allow a user to simply provide their password once and allow the browser and website to handle the rest.  The browser remembers the user's session id and the web server makes  a record within their databases to associate the session id and user's identity. From this point on the web site knows that each time they receive the particular session id that the request is coming from the associated user.

Examples of session ids that would be stored on the web server
Session ID  - Associated User
  • 4364256265 - Joe
  • 1239086434 - Sue
  • 9938381123 - Bob
Where is the Security Problem?
Many users are aware that before logging into a website they should check that they are on a page beginning with HTTPS (instead of HTTP). HTTPS uses Transport Layer Security (TLS) (sometimes referred to as SSL) to ensure that the password is sent over an encrypted connection. This means that a network administrator, the coffee shop folks running a wireless hotspot, or even the coffee drinker sitting next to you, is unable to view your password when it is sent over the network.

The problem is in the next step. As we discussed above, the username and password is only sent once. After that, the web browser sends the session id to the website in order to identify the user.  Unfortunately many websites have decided not to implement TLS/SSL for the communication after the login process. This means that although your password is sent over an encrypted channel, the session id is not.  Since the session id represents the user's identity with the website, anyone that obtains the session id thereby becomes the associated user.

How Does The Attacker Obtain Your Session ID?
[EDIT 11/4/10: A man in the middle attack is not necessary on many open wireless networks. Simply monitoring network traffic will reveal the session id of all users since the traffic is broadcasted to everyone. See comments 1 & 2 below for more info.]
 The attacker, in this case the user running Firesheep, executes a man in the middle attack which tells your computer to send all of your traffic to the attacker's machine before it is sent out to the Internet.

This allows the attacker to easily view any data that is not encrypted like the session id. Encrypted data, such as the username and password, can not be viewed by the attacker even if he is executing a man in the middle attack. 

To summarize, although the attacker can't obtain your password, they can obtain your session id. And this is just as good.  Because with the session id the attacker can do anything in the website as you. In Facebook they could add new friends or make status updates and on Twitter they could tweet random messages. All of this would appear to normal just as if you had made these actions yourself.

Stay tuned for post #2 in the Firesheep series : Spotting Websites Vulnerable to Firesheep

-Michael Coates

Wednesday, November 3, 2010

Hey Chase, Take DoubleClick Out of Your Online Banking

Guess what I found today. The Chase online bank website uses iframes to inject tracking into the authenticated portion of online banking! What a failure for privacy and a big security risk. I'm at a loss as to what to say here.

Here's a little taste of their nastiness:

      <iframe src=";src=2299144;type=e-cus110;cat=e-cus876;u=123;ord=1;num=1?"
        width="1" height="1" frameborder="0"></iframe>  

Here are a few screenshots to demonstrate the issue. I discovered this little gift after installing the RequestPolicy addon.

Business Customer Site:

Normal Customer Site:

Here is the snippet from the HTTP response for /MyAccounts.aspx. As you see in the comments section, they new exactly what they were doing.  Copy of the code below the image:

<!-- Start of DoubleClick Spotlight Tag: Please do not remove-->

<script language="JavaScript">
document.domain = getDocumentDomain();

function getDocumentDomain()
    var d = document.domain;
    if(d.indexOf(".") > -1)
      var end = d.substring(d.lastIndexOf("."), d.length);
      d = d.substring(0, d.lastIndexOf("."));
      d = d.substring(d.lastIndexOf(".") + 1, d.length);
      d = d + end;
    return d;
    return null;

function openWamuSSOWindow(aUrl)
  var scLeft = window.screenLeft;
  var scTop = window.screenTop + 30;
    var, "WAMUSSOMortgage", "height=389,width=758,left=" + scLeft + ",top=" + scTop + ",screenX=0,screenY=0,location=yes,menubar=yes,resizable=yes,scrollbars=yes,status=yes,toolbar=yes");
    var agt=navigator.userAgent.toLowerCase();
    if(!(agt.indexOf("msie")!=-1 && (parseInt(agt.substr(agt.indexOf("msie")+5,1))==4))){
var _linkTrackingVersion = 2;

  <iframe src=";src=2299144;type=e-cus110;cat=e-cus876;u=123;ord=1;num=1?"
    width="1" height="1" frameborder="0"></iframe>   
<!-- End of DoubleClick Spotlight Tag: Please do not remove-->

-Michael Coates

Monday, November 1, 2010

Preventing XSS with Content Security Policy

[Cross post with OWASP blog]

An individual XSS can be easily remediated with contextual output encoding per the OWASP XSS Prevention Cheat Sheet. Although an individual XSS can easily be addressed, the overall cat and mouse game of effectively ridding an application of XSS can be very difficult.  To combat this problem a new security feature, Content Security Policy, has been introduced into the Mozilla Firefox browser.

Content Security Policy (CSP) is an opt-in white list approach for defining what external scripts sources are allowed to execute JavaScript or other content loading code (e.g. iframes) within the page.  By eliminating inline scripts and defining a white list of allowed external scripts it is possible to strictly control what JavaScript is executed within the page. In the event that a user injected script into the page via an improperly encoded piece of user controlled data, then Content Security Policy would identify that the JavaScript is not part of the white-listed data and the browser will disregard this unauthorized script.

Here's a basic overview of the CSP process:
  1. Externalize all JavaScript within the pages (e.g no inline script
    tag, no inline JavaScript for onclick or other handling events )
  2. Define the policy for your site and whitelist the allowed domains where the externalized JavaScript is located.
  3. Add the X-Content-Security-Policy response header to instruct the browser that CSP is in use.

Violation Reporting

 The violation reporting component is another huge benefit of using CSP that can be enabled by providing a value for the policy-uri field within the site's specific Content Security Policy.  In the event content (JavaScript, injected iframe, etc) is not allowed to execute due to CSP, the user's browser will issue a violation report back to the URL specified by the site's CSP.  This means that a website owner can receive real time notifications of CSP violations that could be potential XSS attacks. 

CSP Enabled Browsers
Content Security Policy is currently supported in Firefox 4. Although CSP is currently supported in only one browser, there are still many reasons to provide CSP support within a website. CSP will provide an added layer of protection to all web site users with a CSP enabled browser. In addition, CSP enabled browsers will also provide violation reporting feedback back to the web site owners in the event an XSS attack is somehow injected into the page. Finally, if CSP is well received then the intent is to formalize this into a standard and push for adoption within other browsers. 

More Information

Michael Coates (@_mwc) & Brandon Sterne (@bsterne)