Draft for 1.2.x Security Policy (Feedback Requested)

[Chris Travers <..hidden..>]

Hi;

Last night I was reading the OWASP developer guide and I was thinking
about the recommendation that each organization keep a security policy
on file.  With a rapidly developing and improving security framework
for LedgerSMB, it occurred to me that a solid security policy for each
branch (at least until 2.0) would be better than a single policy.  So
here is a draft.  Feedback is requested.  Please note that 1.3 will be
far more secure than 1.2 is, and the security policy will be
appropriately tightened.  The known vulnerabilities in 1.2 which are
accepted or mitigated are ones which are of issue in SQL-Ledger and
this is only transitional until they can be removed.

Best Wishes,
Chris Travers



Application Security Policy for LedgerSMB 1.2 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.1.x and stronger for 1.3.x.

The process of improving LedgerSMB security is an ongoing task.  Each major
release reduces the number and type of accepted security issues.  For this
reason, the security policy for this release is entirely focused on OWASP Top 10
issues.


2:  Changes since 1.1.x
-----------------------
SQL Injection attacks are no longer "accepted" and will be fixed.

3:  Considerations in Determining What is to be Fixed/Mitigated/Accepted:
------------------------------------------------------------------------

LedgerSMB 1.2 is designed for small businesses.  It provides no separation of
duties or other higher-end accounting controls.  These change the security
calculus in part because opportunities for useful attacks against the financial
data are possible without breaking the security model of the application,
assuming that many people have access to the application within an organization.

Furthermore, LedgerSMB's security is very much a work in progress.  Each major
release has added major security improvements as we re-engineer the architecture
to produce what we hope to eventually be industry-leading security.

4:  OWASP Top 10 Issues to be fixed.
-----------------------------------
This section is based on the 2010 RC1 of the OWASP Top 10 list.  This may be
updated as newer versions emerge.  In general, these are characterized as being
correctable in the current codebase.

A1:  Injection:  SQL Injection attacks are to be fixed.  HTML injection attacks
are not practical to fix in this release, which leads to XSS issues.  System
command injection issues are to be fixed as found.

A3:  Broken Authentication/Session Management

A6:  Security misconfiguration:  The default installation parameters (with the
exception of SSL, see below) shall be secure.

A8:  Unvalidated Redirects and Forwards:  As of 1.2, redirects are handled
inside the Perl script.  If a third party redirect occurs (outside of an HTML
injection), it will be fixed.

5:  OWASP Top 10 Issues to be Mitigated.
----------------------------------------

A2:  Cross-Site Scripting (XSS):  Due to the prevalence of HTML injection
attacks against LedgerSMB 1.2.x, these attacks will be mitigated in this branch.

Business Impact and Client-Side Mitigation of XSS:  XSS can be used to install
malware on users' computers, to forge requests (in the same site with the user
logged on) to enter fake data onto the books, etc.  These have different threat
signatures and different responses on our part.  The goal of mitigation is to
prevent malware installations and access to third party web sites, and to
provide the administrator a chance of detecting and correcting XSS attacks
against financial information.  To this end we recommend a client-side solution
(like the NoScript plugin for Firefox) and we require that no forms be submitted
in parallel.  Parallel requests delete the session, thus usually triggering a
call to the customer's support organization.

A5:  Cross-Site Request Forgery (XSRF):  It is not practical to address XSRF
issues in 1.2.  The same mitigation strategy applies however.  We also recommend
short session timeouts as a way of mitigating this risk.  The business impact is
similar to the XSS attacks against financial data, and could be used to inject
HTML into pages triggering XSS attacks on other users.


6:  OWASP Top 10 Issues to be Accepted
--------------------------------------

A4:  Insecure Direct Object References:  LedgerSMB 1.2 has not yet moved to a
robust permissions framework inside the application.  It is not practical to add
such controls in this version.  We have documented mitigation strategies in our
manual, however.

A7:  Failure to Restrict URL Access: With the mitigation strategies documented
in our manual, it is possible (with much effort) to prevent useful operation of
restricted URL's.  Adding robust controls is beyond what can be done in 1.2.

A9:  Insecure Cryptographic Storage:  LedgerSMB 1.2 uses separate application
and database passwords, with many users mapped to a single db user.  For this to
work, the web server must have access to the password to log into the db.  While
SQL-Ledger merely obfuscates the password, we have concluded that there is no
perfectly secure way to address this issue within 1.2, and therefore leave these
passwords in plain text.  Our reasoning is that it is better to ensure that the
administrator takes responsibility for protecting this information than to
provide a false sense of security.

A10:  Insufficient Transport Layer Protection:  LedgerSMB 1.2 does not document
the need for SSL in intranet communications or between the web and db servers.
It is expected that generally this is installed only on small networks, and that
usually the web and db server are running on the same system.

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

LedgerSMB 1.3 will address two fundamental technical issues with LedgerSMB 1.2
regarding security architecture.  First, permissions will be robustly enforced
at the database level, meaning that it will no longer be possible to bypass the
application security checks to write or read from the database.  This will also
eliminate the need to store database passwords in a way accessible to the web
server.

Secondly, the user interface will move to a template system, where all output to
the web browser in the portions of the application we can get to will be
validated and escaped for the appropriate format.  This will allow us to remove
the XSS and HTML injection issues at once.

Finally, the accounting controls will be improved in 1.3, making it more
important to deal with XSRF and related exploits, and an infrastructure is in
place to address XSRF as well.

As of 1.3, all of the OWASP Top 10 issues on the 2010 RC1 document will be
listed as those to fix immediately.  At that point, we will also see far more
discussion of overall attacks beyond the OWASP top 10.