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. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
