Comments on: Force CommSec to Use HTTPS with NoScript http://www.orzeszek.org/blog/2009/04/02/force-commsec-to-use-https-with-noscript/ An inchoate upside-down perspective Tue, 07 Feb 2012 18:26:06 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Chris http://www.orzeszek.org/blog/2009/04/02/force-commsec-to-use-https-with-noscript/comment-page-1/#comment-4668 Chris Wed, 04 Nov 2009 09:17:46 +0000 http://www.orzeszek.org/blog/?p=396#comment-4668 @tradedogg: You’re right that, when there is no attacker, the content frame loads a page over SSL and that that particular page is encrypted and secure. The problem is that the page that contains that frame is itself delivered without SSL. That means that that parent page can be changed by a man-in-the-middle. And if a man-in-the-middle can change the parent page, he could change it so that the page in content frame, which would normally be delivered over SSL, would be delivered without SSL. If you entered any information into the content frame then, it could be read by an attacker. So long as you check that the page in the content frame is being delivered over SSL and from comsec.com.au each and every time (by right-clicking on the page and selecting Properties, as you suggested), you would be safe. But you would have to do this for every single page in the content frame before you enter any data into it. No one’s going to do that regularly. Do you? If you don’t do that, then you’ll be secure only so long as there is no man-in-the-middle attacker. See <a href="http://www.orzeszek.org/blog/2009/03/20/commonwealth-insecurity-banking-over-http/" rel="nofollow">here</a> for further details. @tradedogg: You’re right that, when there is no attacker, the content frame loads a page over SSL and that that particular page is encrypted and secure. The problem is that the page that contains that frame is itself delivered without SSL. That means that that parent page can be changed by a man-in-the-middle.

And if a man-in-the-middle can change the parent page, he could change it so that the page in content frame, which would normally be delivered over SSL, would be delivered without SSL. If you entered any information into the content frame then, it could be read by an attacker.

So long as you check that the page in the content frame is being delivered over SSL and from comsec.com.au each and every time (by right-clicking on the page and selecting Properties, as you suggested), you would be safe. But you would have to do this for every single page in the content frame before you enter any data into it. No one’s going to do that regularly. Do you?

If you don’t do that, then you’ll be secure only so long as there is no man-in-the-middle attacker.

See here for further details.

]]> By: tradedogg http://www.orzeszek.org/blog/2009/04/02/force-commsec-to-use-https-with-noscript/comment-page-1/#comment-4664 tradedogg Wed, 04 Nov 2009 06:04:26 +0000 http://www.orzeszek.org/blog/?p=396#comment-4664 if you right click on any secure page while logged into commsec and go to properties you will see that even though the address bar does not show https, the actual content on all secure pages is https. So yeah in other words dont waste ur time the commsec website is secure.. if you right click on any secure page while logged into commsec and go to properties you will see that even though the address bar does not show https, the actual content on all secure pages is https. So yeah in other words dont waste ur time the commsec website is secure..

]]> By: Online broker CommSec criticised for weak passwords, lack of SSL | Zero Day | ZDNet.com http://www.orzeszek.org/blog/2009/04/02/force-commsec-to-use-https-with-noscript/comment-page-1/#comment-27 Online broker CommSec criticised for weak passwords, lack of SSL | Zero Day | ZDNet.com Wed, 29 Apr 2009 15:43:11 +0000 http://www.orzeszek.org/blog/?p=396#comment-27 [...] newly introduced password best practices come a month after another security design flaw was exposed at the online broker - CommSec’s use of non-SSL frames pages potentially resulting in [...] [...] newly introduced password best practices come a month after another security design flaw was exposed at the online broker – CommSec’s use of non-SSL frames pages potentially resulting in [...]

]]>