W3C home > Mailing lists > Public > public-usable-authentication@w3.org > September 2006

Re: Comprehensive list - known Threat and Protection table

From: George Staikos <staikos@kde.org>
Date: Tue, 26 Sep 2006 13:21:07 -0400
To: public-usable-authentication@w3.org
Message-Id: <200609261321.07271.staikos@kde.org>

On Saturday 23 September 2006 09:39, Chris Drake wrote:

> You correctly suggested that I'd overlooked XSS security problems in
> my list; there's a whole range of things here that I need to add in
> (I'd class the ones I've got in my own mind as "Implementation
> Oversights") - but before I pollute your own creativity with my
> interpretation of XSS problems - can you elaborate on the kinds of
> XSS threats I should add to my list, in case it's anything I've still
> not thought of yet ? :-)

  I will ask for feedback from some of our team.  I am surely going to miss 
some.  Stay tuned.

> XmlHttpRequests... interesting... since these are scripted, there
> could well be a whole new pile of problems that plain old frames
> didn't already provide.  I assume it's now possible for browser
> scripts from site X to "read" and/or parse HTML from site Y without
> the problems of security contexts like frames have now got - am I
> correct?  If so - yikes! - this should allow for a javascript in a
> browser to emulate a man-in-the-middle proxy attack (with some effort
> admittedly!)

  I'm not entirely sure that XmlHttpRequest opens new vulnerabilities beyond 
implementation issues.  I think anything done with XmlHttpRequest could also 
have been done with iframes.  It was just ugly and not as obvious.  Yes XSS 
is possible here too.  Same problem as above.

> >>     3.6.2. address bar hiding
> If you want to have a really long and hard giggle - take a look at the
> actual login web page for this - Australias most popular bank:-
> https://www.commbank.com.au/login/conditions_splash.asp (hint - you've
> got to click the button at the end to get to the login page) or try
> the "login" link from this: http://stgeorge.com/ - Another popular
> Aussie bank.  Hackers don't have any address-bar spoofing security
> problems "down under": the banks are all doing it for them!

  No big surprise here.  It's been happening forever.  In 
_George's_Traveling_Security_Talk_ I often reference sites that kill all the 
chrome and draw a PNG padlock or say "This is a secure site." - sometimes 
even when they don't use SSL!

> >>    5.1. back button
> I mean - by way of example - imagine you walk up to a free public
> internet terminal in an airport - then click the "back" button on the
> browser a few times.  You get all kinds of fun stuff - personal
> emails, bank statements, corporate intranets, etc etc...

  I don't think this is a solvable problem.  It's I/O error.  I could leave my 
wallet on the cashier counter and lose all my money and credit card/SSN/etc 
numbers too.

> Thanks heaps for your contribution.  I'm not sure if the lack of other
> contributions means I've thought of almost everything, or that nobody
> else cares or understands or is able to see past the solution
> distractives...

  I'm trying to keep up. :-)  Actually your list was very comprehensive.  I 
think you did a great job!

George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/
Received on Tuesday, 26 September 2006 22:22:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:15 UTC