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.
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.
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.
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.
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.
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.
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 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.
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 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.
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.
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.
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.
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.
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
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
If you discover any errors or omissions in this document,
please email support@splendidcrm.com.