CommSec uses a non-SSL frameset to deliver sensitive financial data. You never know (without some digging) whether the content frame is at the www.comsec.com.au domain and whether it’s using SSL or not.

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.

Broken by 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 digging) whether the content frame is at the www.comsec.com.au domain or 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. A 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.