On Thu, Jan 28, 2010 at 1:59 PM, John Locke <[email protected]> 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
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Ledger-smb-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
