Working draft of Application Security Policy for LedgerSMB 1.3

[Chris Travers <..hidden..>]

Comments and feedback are requested.

Best Wishes,
Chris Travers

Application Security Policy for LedgerSMB 1.3 Working Draft 1

by Chris Travers
March 2, 2010

=============================================================

1: Scope:
-----------

This document describes the current security strategy of LedgerSMB 1.2.x, an
open source financial accounting program which started as a fork from
SQL-Ledger in 2006.   This document only addresses the 1.2.x stable branch as
security standards would be weaker for 1.2.x and stronger for 1.4.x.

The process of improving LedgerSMB security is (still) an ongoing task.  Each
major release reduces the number and type of accepted security issues.
LedgerSMB 1.3 is the first major release to address the remaining OWASP Top-10
security vulnerabilities.  Consequently, this document provides a wider range of
security analysis than past branches.

2: Overview of Application and Security Goals
---------------------------------------------

LedgerSMB is an open source financial accounting application for small to
midsize businesses.  One of our goals is to provide industry leading security
and robustness.  However, since the original application we forked from did not
make this a priority, the road has been long, and is not yet completed.

This major branch addresses all OWASP Top 10 vulnerabilities based on current
working draft (2010 RC1) and adds substantial separation of duties features as
well.  These provide far more security than past releases.

The major vulnerability in a financial accounting program is the ability to
enter malicious data in order to cover for fraudulant activities, especially
when such operations are pinned on others.  Additionally, some sensitive data in
the application may be disclosed which could lead to financial losses.  Unlike
most other applications, attacks against financial accounting software can force
losses much in excess of the value of the data in the database.  Therefore this
is a truly critical type of application when it comes to security.

3:  Changes since 1.2.x
-----------------------

All OWASP top 10 vulnerabilities will be fixed upon verification, provided that
robust, server-side solutions are possible.  Where robust, server-side solutions
are not possible, we will document proper compensating controls to be run on the
client.  Additionally the scope of this document is far wider, including certain
types of application misuse instead of mere technical attacks.

4:  Known types of risks:
-------------------------

Risks that this software faces fall into roughly three categories:  technical,
social engineering, and fraudulent bookkeeping.

Technical risks include standard attacks agains the software.  These include
Cross-site scripting and similar attacks, as well as attempts to bypass
authentication, etc.  In most cases, technical risks can be fixed in the
software and in these cases, they will be.  In rare cases, the software may not
have enough information to properly address the technical attack and hence some
level of trust has to be placed in the client.

Social engineering attacks include phishing and similar approaches, as well as
other schemes directed at confusing users into reveal confidential information
or perform operations which they are authorized to perform in furtherance of a
third party's fraudulent scheme.  Social engineering attacks cannot be corrected
on the server and must be solved via user training.  The only party which can
address this type of risk is the organization using the software.

Fraudulent bookkeeping involves entry of data so as to cover fraudulent
transactions.  For example someone might write himself or herself a check and
enter a fraudulent invoice to a vendor that was paid for the same amount.  These
are not technical attacks and don't involve users exceeding their authorized
access privileges.  These are addressed via accounting controls.

5:  Known Technical Risks That Must be Mitigated by User
--------------------------------------------------------

The web server sees only what the client sends.  Some rare types of cross-site
scripting can exploit web browser capabilities to send a series of requests
which appear to be legitimate.  The most common type of attack of this sort is
called "clickjacking" where the web page is loaded in such a way as to be
invisible to the user and then the user is tricked into clicking on buttons in
the application to send fraudulent requests to the web server.  The web server
cannot distinguish this from a legitimate request because the web browser went
through a complete workflow.

This sort of attack cannot be avoided on the server side and must be addressed
on the browser level.  One option is to install a plugin like "NoScript" which
blocks certain things that browsers might do to accomplish such an attack.

A second major issue concerns the way authentication and authorization is
handled on LedgerSMB.  LedgerSMB 1.3.x runs as least privilege.  The application
itself has no access to the database or to anything security-critical.  Instead
these credentials are provided by the user at login time and resubmitted as part
of the authentication header to the server.  However this means that the web
server must have access to the username and password in a format which is usable
to authenticate against the database server.

There are two ways this can be done.  The first (supported out of the box) is to
use HTTP basic authentication, where the username and password are not encrypted
in transit.  In this case, SSL is absolutely required because an eavesdropper
could obtain username and password data by reviewing network traces.  Since this
is the typical configuration, the default install only allows connections from
localhost and contains warnings the requirement for SSL when changing this
setting.

As an alternative, one could use Kerberos and produce an authentication plugin
to authenticate (using the "negotiated" method) against a KDC.  This is not
supported out of the box but shouldn't be overly difficult.  It doesn't require
a plugin in Internet Explorer 8, but does with Firefox.  Presumably most other
browsers would be unsupported in such a configuration.  SSL would still be
recommended due to the sensitivity of financial data transmitted.

6:  Controls against fraudulent bookkeeping
-------------------------------------------

LedgerSMB 1.3 adds separation of duties requirements before certain types of
transactions are posted into the books.  This is not entirely complete because
of the complexities of addressing COGS handling along with transaction approval.
Further sales orders, quotations, etc., because they are not financial
documents, do not have separation of duties capabilities.  Separation of duties
is a key accounting feature which is used to prevent both human error and fraud.

LedgerSMB 1.3 will not add such separation of duties interfaces to invoices
containing inventory ("Sales" and "Vendor" invoices on the menu) but will
continue to support it for AR/AP Transactions, Journal Entries, bank
reconciliation, etc.

7:  Looking Forward:
-------------------

Minimally, 1.4 will finish moving all of the financial transactions code over to
a new framework.  At this point, we can expect full separation of duties for
invoices (allowing batch processing of invoices as well).