Security
Computer and data security are fundamental components of software development, particularly in an application where read / write actions are performed, such as Editor. Editor can provide editing access to potentially sensitive information, so it is important that you understand how DataTables and Editor handle software security and the options available to customise the actions taken.
Overview
This page will discuss web security attacks that are directly relevant to DataTables and Editor, along with methods for how you can combat them. Web security is a very wide ranging topic and it would be impossible to cover all topics here. For more general information about web and software security, refer to the excellent OWASP site.
Software versions
The first thing to do when considering software security is always to run the latest version of the software that is available. The latest versions will contain fixes for known issues, while those issues may be present in older versions. The latest version of Editor is always available on the Editor download page and the latest version of DataTables and its other extensions are available on the DataTables download page.
Attack types
There are typically four attack types that are important to consider when working with Editor:
- Privilege escalation
- SQL injection
- Cross-Site Scripting (XSS)
- Cross-Site Request Forgery (CSRF)
Privilege escalation
Privilege escalation is where a user, or attacker, has access to data that their account should not have access to. This could simply be not checking for a valid login account when loading data, or showing more data to a user than they should be able to access. In the case of Editor this could also be the result of providing editing options when a specific user should have read only access.
Prevention
Account access levels is something that is primarily a function of whatever login / session software you are using, although that will have a direct impact upon Editor's access options. The PHP and .NET libraries both provide methods that control the read / write access for each field in the table (Field->get(), Field->set() and Field.Get(), Field.Set() respectively), which you can define using the account access options of your login / session software.
For example, consider the following PHP example where access control is provided by $_SESSION['access'] (this will likely be different in your own software!). The name and location fields can be read by anyone, but only edited by those with editing access. The salary field can be read and written only by those with admin access:
Editor::inst( $db, 'staff' )
->fields(
Field::inst( 'name' )
->set( $_SESSION['access']['editing'] )
Field::inst( 'location' )
->set( $_SESSION['access']['editing'] )
Field::inst( 'salary' )
->get( $_SESSION['access']['admin'] )
->set( $_SESSION['access']['admin'] )
);
The same example in C# with the Editor .NET libraries:
new Editor( db, "staff" )
.Field( new Field( "name" )
.Set( Access.Editing )
)
.Field( new Field( "location" )
.Set( Access.Editing )
)
.Field( new Field( "salary" )
.Get( Access.Admin )
.Set( Access.Admin )
)
Additionally, on the client-side you may need to adjust the number of columns in the table (columns) and fields in the Editor form (fields) to ensure that the interface reflects the access level the user has available to them.
SQL injection
SQL injection is one of the most common attack types since it is such a simple attack to perform. In this type of attack an SQL query is executed from user input data and is nicely demonstrated in this popular XKCD strip.
Prevention
The Editor PHP and .NET libraries will automatically "bind" all data that is submitted by the client, ensuring that an SQL injection attack cannot happen when using these libraries.
Both libraries also have the option of using conditional expressions which do not automatically bind, but do provide APIs to allow you to safely use submitted data if you are using such conditional expressions - see PHP and .NET Editor documentation.
XSS
An XSS attack is performed by allowing arbitrary Javascript or HTML to be executed on your site. The injected Javascript could then perform actions with the current user's account or steal information. In the case of Editor consider a user entering <script>alert('Hi');</script> into a text field. If this wasn't correctly handled, when displayed by DataTables the script would be executed and the alert shown. While this simple case is potentially annoying, much more sophisticated attacks could be performed.
Prevention
The Editor PHP and .NET libraries have built in XSS prevention and will automatically escape any potentially dangerous data before it is saved to the database. This effectively mitigates any potential XSS attacks against Editor based software.
The XSS prevention mechanism used by the libraries can be controlled by the Field->xss() method in PHP and Field.Xss() in .NET. They both provide the following abilities:
- Built in protection: htmLawed in PHP and the Microsoft XSS library in .NET
- Disabling the XSS protection by passing in
falseto this method. If you do this ensure that you use a DataTables renderer to prevent XSS attacks when outputting data. - Providing a custom XSS prevention method by passing in a method that will take a single string parameter and return the protected string.
CSRF
A CSRF attack can force an end user (typically without their knowledge) into executing unwanted actions on a site or application on which they are currently authenticated. In the case of Editor, this could be creating, editing or deleting data from a table.
Prevention
As described on the DataTables security page, the most common method to mitigate this type of attack is to use a known token which is submitted to the server - the server will then authenticate the token to ensure that the request is valid.
Generation and handling of the token is outside the scope of this documentation (please refer to the framework documentation if you are using a framework, or to the OWASP guide if you are creating your own system). However, we do need to detail how the CSRF token is transmitted to the server.
The Editor ajax configuration object can be used as an object which accepts all of the same options as the $.ajax method, including the ability to submit headers and data. Depending on how your application excepts the CSRF token, you can use one of a number of methods:
Setting a global header (this ensures that all Ajax requests from the page have the CSRF token):
$.ajaxSetup( {
headers: {
'CSRFToken': TOKEN
}
} );
Submitting the token as a header value from the ajax configuration:
new DataTable.Editor( {
ajax: {
url: '...',
headers: {
'CSRFToken': TOKEN
}
}
} );
Submitting the token as part of the request data:
new DataTable.Editor( {
ajax: {
url: '...',
data: function ( d ) {
d.CSRFToken = TOKEN;
}
}
} );
where in all cases TOKEN is the CSRF token (again, how you get this token is a matter for the application or framework you are using).