mailing list archives
Re: Intacct.com: Multiple bugs at financial services company
From: "Chris L. Mason" <cmason () UNIXZONE COM>
Date: Wed, 6 Sep 2000 07:48:01 -0400
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
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
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
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
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
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
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.
(who has banged his head against the wall explaining this to too many