On Thu, Jan 28, 2010 at 1:59 PM, John Locke
<..hidden..>
wrote:
Hi,
Chris,
Wow, that sounds like a pretty sophisticated attack. I would tend to
think it would be much easier to trick the sysadmin with the root pw
into granting sudo rights that let you into the database itself... how
much prevention is really necessary?
Long-run I would like to see this and every form of possible attack
against the application addressed. I don't think this is sufficiently
likely to be a clear and present danger because clickjacking, etc. can
have a similar effect and might not be that much harder to accomplish
(one thing I am working on documenting countermeasures for).
I do see the need for good CSRF protection, and I think Drupal has a
pretty solid approach built into their form API that does something
similar--stores a session and form identifier while a user has a form
open, changing it on each request. It also has an easy way of bypassing
this check if you're interacting with the form api directly (bypassing
the browser). It's fairly convoluted but seems like a pretty well-tested
approach that might be worth borrowing.
But I'd tend to echo Michael's comment about a good audit logging
system, that the best way of addressing the type of attack you outline
below is through a separate control, making it so that each transaction
has some extra verification log that could be scanned to find
discrepancies.
Audit logs are generally useful when you already have a good idea of
what to look for (i.e. you already have a suspicion that something is
amiss and have narrowed down the candidates to a few options).
There are some addons to provide very high quality logging for
customers/vendors in 1.3, and it should be easy to add similar addons
for the financial data.
After all, the attack you describe could be done by the CPA or any
bookkeeper with appropriate access level, without additional technical
help, no need for a CSRF attack. Isn't that the whole point of controls,
to make it so that you can easily detect malicious activity of insiders?
Well, there is a difference though. The current audit logs, when
enabled, would allow you to determine who posted the questionable
invoice, and in 1.3, you can configure it so that the CPA can't enter
invoices at all but can only approve them.
This sort of attack is problematic because it allows someone to
impersonate another user and thus interferes with auditing. It could
also get around separation of duties controls.
I guess I'm just suggesting that after doing the easy stuff to block
CSRF attacks, I'd rather see a really good audit log that's very
difficult to forge and easy to understand, rather than a whole lot of
work protecting privilege-escalation attacks that are already quite
difficult to exploit. For most of the businesses likely to use
LedgerSMB, the more significant/damaging attacks are likely to come from
those who already have the privileges!
For the financial data, I expect to have a trigger-based package
available shortly which basically:
1) Restricts delete on affected tables
2) On affected tables, logs the user, the table name, the inserted id,
and now().
For customers and vendors, Aurynn has put together a module using
tablelog which can do proper auditing on updates as well. However, we
don't want to allow updates of financial tables more than necessary to
accomodate the current codebase (and only until that can be removed).
Hope this helps,
Chris Travers