Security Guide

SplendidCRM Security Guide

Introduction

SplendidCRM was designed from day-one with security in mind.  Our security measures are intended to protect against both an external hacker trying to break into the application and an internal hacker (i.e. an employee), trying to access data that has been restricted.  Some of the security measures take the form of architectural design whereas others are well-documented best practices.

Architectural Security

Globally Unique IDs (GUIDs)

The foundation of security for the SplendidCRM application is the use of Globally Unique IDs (GUIDs) as primary keys.  While there are many reasons to use a GUID as a primary key, and even though there are some performance disadvantages to using a GUID as a primary key, the use of the GUID is critical to the over-all security of the application.  It is important to note that the benefits of the GUID are only fully realized when the actual SQL data type used in the tables is a “uniqueidentifier”, which stores the GUID as a 16-byte binary array.  This note is intended to warn against database platforms, such as MySQL, that require GUIDs to be stored as 36 characters.

The GUID is a 128-bit number with 3.4×1038 possible combinations (http://en.wikipedia.org/wiki/Globally_Unique_Identifier).  A GUID is typically rendered as a 36-character string of hexadecimal numbers, separated by hyphens, such as 492A7A4C-BCD6-468D-B7E8-20BDD95677C7.  By using randomly generated IDs it becomes impossible for a hacker to guess a particular ID of a desired record.  By storing the GUID as a 16-byte binary array instead of a 36-character string, we can ensure that only hexadecimal characters are used.

In contrast, some CRM systems have been designed to use integers as primary keys.  While there is certainly a performance gain to using a 4-byte integer as a primary key, it also leaves the system open to a hacker who sequentially queries the database starting with a primary key of 1.

The use of GUIDs also ensures a certain level of database referential integrity.  Whereas a database foreign key constraint would not be able to distinguish between two integer keys with different meanings, it can easily distinguish between two GUIDs.

Database-level Security

The SQL code used to create the SplendidCRM database has been specifically designed with security in mind.  As a general rule, all data being retrieved from the database is done so using a SQL view and all data going into the database is done so using a SQL stored procedure.  This design allows us to apply security rules at the database level to prevent direct table access.  Therefore, the tables are created without public-read or public-write access.

The goal of this design is to prevent a hacker from arbitrarily modifying tables even in the worst-case scenario of the hacker having control over the web server.  This design also provides an additional level of protection against SQL injection.

Database-level Auditing

SplendidCRM provides deep auditing at the database level by leveraging SQL triggers.  Using triggers for auditing, instead of middleware application-style logic, ensures that any change to the database from any source is properly tracked.  In the worst-case scenario of a hacker having control over the web server, all actions in the database can be tracked and reversed by a skilled database administrator.

Parameterized Queries

As a general rule, all SQL code that is generated by the application at runtime uses parameterized queries.  This is a development style that leverages Microsoft ADO.NET code to ensure that text input, as provided by the end-user, is properly formulated (escaped, in programmer jargon) to prevent unintended consequences in the database.  The use of parameterized queries is the primary means to protect against SQL injection.

There is one notable exception to this rule.  SplendidCRM has a powerful Search Builder that allows the end-user to use Google-style syntax when querying for data.  This code does not used parameterized queries but instead takes special pains to ensure that each token in the string is properly escaped to protect against SQL injection.

SQL Stored Procedures and Views

The use of stored procedures ensures that all data going into the database matches the expected format in the expected order.  These procedures also ensure that only the fields that are allowed to be updated can be updated.

There is one notable exception to this rule.  Because of the dynamic nature of custom fields, such fields are updated using a traditional SQL update statement.  However, the layout editor specifically controls what fields can be updated, and where, in order to minimize the risk.


External Security

The most common techniques that hackers use to break-into an application are (a) SQL Injection, (b) Hidden Field Tampering, and (c) Cross-site Scripting.

SQL Injection

SQL injection is the practice of formulating data in a query in an attempt to trick the database into escaping out of its intended logic and appending additional logic.  Our solution against SQL injection is to make certain that all inputs are properly validated and escaped before the SQL statement is sent to the database.  The most common and best solution is our use of parameterized queries.

Hidden Field Tampering

SplendidCRM only rarely uses hidden fields because of the security risks.  When a hidden field is used, it is typically only used to facilitate the selection of data from a popup.  The use of GUIDs as primary keys effectively minimizes the risk of hidden fields as the data will be properly validated before use.

Cross-site Scripting (XSS)

Cross-site scripting is an extremely difficult problem to solve, especially in an application that is intended to allow the end-user to insert content.  Because of the broad audience for SplendidCRM, there is very little that we can do to prevent an end-user from entering bad data into various records.  This problem must be something that is policed by the administrators of the application.

One area where SplendidCRM does filter content is in its handling of inbound email.  Emails are generally not trusted and we therefore apply various filters to strip the content of unsafe HTML tags.


Internal Security

SplendidCRM supports multiple forms of security so that it can be used by almost any organization.  In all cases, security is applied when querying the database.  The goal is to ensure that data is not returned to the end-user if the user does not have access to the data.

Password Hashing

As a security precaution, SplendidCRM does not store passwords in its database.  Instead, it stores an un-reversible hash.  However, the preferred method of authentication is the use of domain-driven Windows Authentication.  This method ensures that the identity is indeed that of the person who has logged-into the client operating system.

Record Ownership

SplendidCRM can be configured to only show records to the users they are assigned to.  This is the simplest level of security but it also allows a manager to see all the data for all users that report to him or her.

Role Management

The Role-based management system allows administrators to define access rights at the module level.  Access rights are determined at login and stored in the Session cache to ensure optimum performance.

Users can be assigned multiple roles that provide different levels of access.  In the case of two roles with conflicting rights, SplendidCRM defaults to the least-access right.  This is similar to the way Windows access rights work.  If a user is assigned two roles, one that grants a right to an area and the other that takes it away, the result will be that the user does not have access to that area.

Team Management

SplendidCRM also supports a Team-based management system that provides a row-level access to data.  Users that are assigned to teams can only see data that is assigned to their teams.  For example, team management allows our customers to define sales teams based on specific geographical areas and ensure that each team can focus only on their area.

While the Role Management logic is applied at the UI level, the Team Management logic is applied at the database level.  When Team Management has been enabled, any time we retrieve records from the database, we make sure that we filter the data by the teams that are available to the current user.

Team Management also supports the concept of a manager.  This is accomplished by creating special private teams for each user in the system.  Then, this private team is assigned to the manager of each user so that the manager can see all the same data.


Additional Information

The SplendidCRM Application Platform is constantly being improved.  Please visit the SplendidCRM Software website to obtain the most recent version of the software:

http://www.splendidcrm.com

If you have any questions, please post them to the SplendidCRM Support forum:

http://www.splendidcrm.com/Forums/tabid/66/Default.aspx

 

References

ASP.NET 2.0 Security Practices at a Glance
http://msdn.microsoft.com/en-us/library/ms998372.aspx

Take Advantage of ASP.NET Built-in Features to Fend Off Web Attacks
http://msdn.microsoft.com/en-us/library/ms972969.aspx

Securing ASP.NET Applications
http://www.novologies.com/post/2009/04/08/Securing-ASPNET-Applications.aspx

Jeff Prosise on Hacking ASP.NET Web Applications
http://blogs.msdn.com/mikeormond/archive/2005/02/24/379562.aspx

ASP.NET Security: 8 Ways to Avoid Attack
http://www.devx.com/security/Article/20898/0/page/1

 

Errors and Omissions

If you discover any errors or omissions in this document, please email support@splendidcrm.com.