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

["Jeffrey W. Baker" <jwbaker () ACM ORG>]

On Tue, 5 Sep 2000, Nagi Prabhu wrote:

> Your advisory posting outlines three areas of concern. FYI, we have
> taken immediate action and have already upgraded our web service to
> remedy the concerns you raised.
>
> Specifically:
>
> 1. Clear Channel vs. SSL
>
> By design, Intacct initially built its system to optimize
> customization and give its users a choice of channels: clear (http) or
> SSL (https). The reason being, that some users have older browsers
> that cannot run SSL.
>
>   As of 8/30, users who request a clear channel (http)  are denied
> access.

Great!

> 2. Session Key This issue, was, in fact, a bug. We immediately fixed
> the bug and now the session key is working as it was designed.

The session keys now seem to be assigned at random.  I consider this issue
fixed.

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

[snip]
> To minimize the risk from security vulnerabilities Intacct has began
> the process of obtaining an AICPA SysTrust audit through one of the
> Big 5 accounting firms.

I would normally have a snide remark to put here.  Must be my old age.

-jwb