mailing list archives
Re: Intacct.com: Multiple bugs at financial services company
From: "Jeffrey W. Baker" <jwbaker () ACM ORG>
Date: Tue, 5 Sep 2000 18:15:36 -0700
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.
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
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
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.
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.