Re: Intacct.com: Multiple bugs at financial services company

["Chris L. Mason" <cmason () UNIXZONE COM>]

On Tue, Sep 05, 2000 at 06:15:36PM -0700, Jeffrey W. Baker wrote:
...
> > 3. Cookie Feature / Cross-scripting
> >
> > The cookie feature was designed for those users who wanted the
> > convenience of being able to enter and re-enter the system without an
> > additional login. However, there was a risk if a user visited a "evil"
> > site without logging out of the Intacc system, an operation could be
> > performed on behalf of the user from that site.
> >
> > It should be noted here that this problem is pervasive on the internet
> > which makes many prominent web services (I won't name them here)
> > vulnerable. The common advice offered is to logout from any web
> > service deemed critical before visiting sites of questionable origin.
> >
> > We are in the process of changing our application to no longer make
> > use of Cookies for session identification. We expect to have these
> > changes available in our web site within the next 10 days. These
> > changes will eliminate any vulnerability from cross-scripting.
>
> The best way to defend against unwanted user action is to use a 1-time key
> for every form submission.  If the one-time key is not submitted with the
> form, the form's action should not really be taken, and the user should be
> alerted.
>
> Not using cookies is a significant change, but the fact remains that you
> will be using some sort of persistent authentication mechanism, and that
> the key will reside on the user's browser in some fashion.  Therefore an
> attacker may still be able to retrieve the key using javascript and
> cross-site scripting.  A vigilant defense against cross-site scripting is
> required of any website which wants to be take seriously.
>
> Of course you are right that almost all web sites, including financial
> services, banks, and trading institutions, are vulnerable to cross-site
> scripting attacks.  But that doesn't mean that your fine service needs to
> fall into that trap.


I think there's a solution to this "problem" that is far too often
overlooked.  More sites simply need to start using HTTP Basic
Access Authentication.  This is the mechanism that causes those a "pop-up"
box to appear where the user must enter their username and password.

The beauty of this method of authentication is that the username and
password are not just sent once, but are actually sent with *every* single
request (for html, form submission, even image files.)  The user only sees
the pop-up box once, because the browser caches this username and password,
but only for the session.  If you exit and restart the browser you will be
prompted to re-enter it.

So what advantages does this provide?

You don't need session management in the first place!  This means your code
can be dramatically simplified.  Authentication can happen at a higher
level meaning CGI or other programs won't even be allowed to run until the
authentication happens.  If they *are* run, the web server just gives them
the valid username and they can process the request and exit without
worrying about doing authentication or following complex session management
schemes.

What advantages does this provide your customers?

1.  It's easy to use and more secure.

2.  Users can bookmark pages *within* a site and return to them and still
        be properly authenticated.  With fake login/logout paradigms forced on
        the user this isn't possible.  Use the web the way it's supposed to be
        used!

3.  Your URLs look simpler and more professional (and easier to remember!)

4.  One user of a service can email another a URL from within the site, and
        the other user can actually use it, *and* be authenticated properly
        with their own id!
        
        (Say for example, a customer checks out a stock research page on Red
        Hat.  Their friend also subscribes to the same research feature, so why
        not mail him/her the URL?  This should work!)

5.  Load-balancing and other schemes are simplified.  With complex session-
        and key-management it can be difficult to spread load across a group of
        systems.  Since HTTP Basic Access Authentication is stateless, you
        don't care anymore which server a user goes to.  Each subsequent
        request can go to a completely different server and everything will
        still work.  This makes things much easier meaning it can be cheaper,
        faster, and more reliable.

The advantages here are numerous, so why do so many large financial sites
*not* do this?  (Some do, but not enough)  Usually it's based on their
previous experience with terminal based computing and more recently
client/server based computing.  As Jakob Nielsen (www.useit.com) would
point out, the web is a different medium.  Usability issues on the web are
different than with client/server applications.  Well, security issues are
different too.

The only real argument I've ever heard against using this method of
authentication is that you can't force the client to time-out after a
certain period (10 minutes, etc.)  Well, guess what, you're just deceiving
yourself if you think you can.  Remember that:

THE CLIENT IS *UNTRUSTED*!!!

If you use a form-based system to allow logins, what's to stop someone from
writing a new browser, or modifying an existing one (or using a plug-in,
or proxy) to automatically re-submit the form every 5 minutes so that the
user doesn't have to login manually?

On the other hand, someone could modify Netscape so the pop-up box in Basic
Authentication happens for every page.  Annoying, but possible.  The
"apparent" security of each system will then have been reversed according
to the "time-out" argument.

The point is you can never control what the client will do.  What if they
just write their password on a yellow sticky and put it on their monitor?
Anyone walking by could use it then!

I wish companies would focus on providing services as secure as possible at
their end.  You only control *your* systems, so focus on securing *them*.
I think if you consider the benefits to yourselves and your customers it
should be obvious which architecture is better.

Thanks,


Chris
(who has banged his head against the wall explaining this to too many
companies!)