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

Re[2]: Comprehensive list - known Threat and Protection table

From: Chris Drake <christopher@pobox.com>
Date: Sat, 23 Sep 2006 23:39:58 +1000
Message-ID: <1853133320.20060923233958@pobox.com>
To: George Staikos <staikos@kde.org>
CC: public-usable-authentication@w3.org

Hi George,

Sorry for the delay - just returned from Vacation.  I plan to flesh
out my threat table some more in the coming months - mostly to explain
all these things to "non hackers" :-)

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 ? :-)

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!)

>>     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!

>>    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...

>>    5.7. accepting auth info over NON-SSL
I'm listing security *problems* (not solutions). That's a biggie.
Eventually I hope to convert my list into a table and list solutions
and techniques and vendors and whatever else might be helpful to folks
who are genuinely interested in creating a secure environment for
their users.

I'm deliberately not putting solutions in just yet, because they
provoke far too much emotional and heated debate, which always leads
to distraction from everything else.

I'm attempting to draw merely the "big security picture", while
avoiding all the "strobe light" solution distractiveness.

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...

Kind Regards,
Chris Drake


Saturday, September 9, 2006, 3:02:14 AM, you wrote:



GS> 2 months later, I catch up. :-)

GS> On Sunday 02 July 2006 00:28, Chris Drake wrote:
>> Hi All,
>>
>> Has anyone attempted to document the threats and/or what protection
>> we're trying to provide to users ?
>>
>> If so - please point me - if not - please add-to or amend my list:
>>
>>    1.5. online phishing
>>     1.5.1. pop-up/pop-behind windows to spoof sites
>>     1.5.2. floating <DIV> or similar elements (eg: emulating an entire
>>            browser UI)

GS>   Maybe XSS too?

>> 2. Remote Technical Tricks
>>
>>    2.1. spoof techniques
>>     2.1.1. vanilla fake look-alike spoof web sites
>>     2.1.2. CGI proxied look-alike web site (server CGI talks to real
>>            site in real time - "man in the middle attack")
>>     2.1.3. popup windows hiding the address bar (3.4.1/3.4.2)
>>     2.1.4. <DIV> simulated browsers (1.5.2)
>>
>>    2.2. iframe exploits (eg: 1.5.1/1.1.3) (spammers buy iframes to
>>         launch 1.5 and 1.4 attacks)

GS>    Also XmlHttpRequest based.  XmlHttpRequest is great.  It allows so many fun
GS> hacks.  Maybe most(all?) of them were possible before with iframes, but it
GS> seems to me that people really weren't considering security when this one was
GS> designed.

>>    3.6. Visual tricks
>>     3.6.1. browser address bar spoofing
>>     3.6.2. address bar hiding

GS>   I'm really embarrassed that we still have this listed here in 2006.

>> 5. Implementation Oversights
>>
>>    5.1. back button

GS>   What do you mean here?

>>    5.7. accepting auth info over NON-SSL (eg: forgetting to check
>>         $ENV{HTTPS} is 'on' when performing CGI password checks)

GS>    The problem is, even if the site does check this, what can be done?  The
GS> password was sent over non-HTTPS.  We could return "error" and redirect to
GS> SSL, but the damage is done.  We can lock out the user at that point, but
GS> we've created a DoS.  The only solution is for such sites/apps/pages to not
GS> support non-SSL connections at all.  I know of some live examples of pages
GS> where you can simply changes the https: to http: and it will accept the POST.


GS>    Do you have an updated copy of this document?  I find it very useful.

GS> Thanks!
Received on Saturday, 23 September 2006 13:40:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:14 GMT