On 20 March 2008, I wrote about CommSec’s use of non-SSL frames pages for its online banking. Although the CommSec homepage is delivered using SSL with an Extended Validation Certificate, once you log in you’re presented with a non-SSL frames page:

gHacks posted recently that you can use NoScript, an add-on for Firefox, to force the browser to use HTTPS for specified domains. You can use it to force CommSec to use HTTPS too.

To do this, download NoScript from here. Open the options for NoScript and go to the HTTPS sub-tab on the Advanced tab. Under ‘Force the following sites to use secure (HTTPS) connections’, enter ‘*.comsec.com.au’:

Now, the CommSec website should always use HTTPS:

You can use this same method to force other websites to use HTTPS too, like Facebook or Twitter.

Remember, though, that NoScript’s primary function is to block scripts and other active content found on most websites. This is useful for security conscious users, but it’ll break most websites.

If you want to force certain websites to use HTTPS but don’t want to block scripts or other active content, you have to disable that blocking in the NoScript options.

Update: It turns out that forcing HTTPS connections for *.comsec.com.au breaks some functionality. Forcing HTTPS connections for only www.comsec.com.au achieves the same goal, but without breaking anything (that I know of):

The reason why *.comsec.com.au doesn’t work is that CommSec doesn’t support HTTPS connections to prices.comsec.com.au. So when you try to get a stock quote, your browser will attempt an HTTPS connection, which will fail.

Now, quotes should work, but they will be delivered over HTTP. And your browser will give you a warning to that effect.

In June 2008, CommSec introduced an integrated banking and trading solution. The idea is that you can do all of your securities trading and all of your banking using the one website. And you get a tastefully designed CommSec Debit MasterCard too. Why wouldn’t you sign up?

Logging In

You arrive at the CommSec website. You’re greeted by the CommSec homepage sitting comfortably underneath a green address bar.

Protected by an Extended Validation Certificate, you enter your Client ID and password. You’re taken to the next page.

Your browser prompts you to remember your password. That’s okay, though, because CommSec uses a second password, one that you can’t save, when you actually want to execute a financial transaction. But what else is missing?

Oops. We’ve lost the SSL. And this appears to be by design.

By Broken Design

CommSec uses frames. The navigation bar is in one frame and the content is in another. The content frame uses SSL only when the content is sensitive. For example, it uses SSL when displaying account balances, but not when displaying market prices.

But the parent page and the navigation frame never use SSL. Since the link to, say, ‘Cash Management’ is itself on an unsecured page, a man in the middle can change the link to point anywhere.

That means you never know where you’ll go when you click ‘Cash Management’. And since you never know (without some serious digging) whether the content frame is at the www.comsec.com.au domain and whether it’s using SSL, you’ll never know whether it’s safe to enter your details there.

Mitigating Factors

CommSec’s site has some characteristics that make man-in-the-middle attacks more difficult. First, the authentication cookie is an SSL-only cookie.

A man in the middle cannot, therefore, acquire that cookie. He or she would need to use some social engineering to get your credentials. For example, the man in the middle could prompt you for your Client ID and password. You’re likely to trust such a prompt, since you came to the site independently and CommSec does itself prompt for such confirmation.

The second mitigating factor is that CommSec uses (optional) SMS security. Whenever you make a payment to a third party (and in certain other circumstances), CommSec will send you a one-time code to your mobile phone.

But, again, social engineering should work. The man in the middle can merely ask you for the code when you go to check your balances, or your details, or when you attempt to perform some transaction.

Conclusion

Delivering sensitive information over HTTPS within an HTTP frame is just bad design. It hides the nature of the connection from the user, who then has no way of telling whether the information is being sent securely or not.

From the perspective of the user, an attack might look like this: they type the CommSec URL, making sure to include ‘https://’. They see a green address bar. They login. They’re taken to an HTTP page (as they always have been). They click the ‘Cash Management’ link, but they’re prompted to confirm their identity first by entering their details and then an SMS code. Having no reason to suspect the site, having accessed it over HTTPS with a green bar, they enter their details. They’re taken to their cash management page. Only now there’s several thousand dollars missing.

I understand that there are performance considerations for delivering market data, charts, etc over SSL, but this kind of design is unacceptable. It confuses already confused users, making social engineering too easy.

Steve Gibson would roll over in his grave, if it weren’t for the fact that he’s still alive doing a great security podcast.