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: Fri, 8 Sep 2006 13:02:14 -0400
To: public-usable-authentication@w3.org
Message-Id: <200609081302.14177.staikos@kde.org>

2 months later, I catch up. :-)

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)

  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)

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

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

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

> 5. Implementation Oversights
>    5.1. back button

  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)

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

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


George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/
Received on Friday, 8 September 2006 20:34:48 UTC

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