Security considerations

Using the CrossmarX Platform you are able to build any functional system you like. Also you are able to introduce security risks/leaks. This document describes what the risks are, commonly made mistakes, what CrossmarX does to prevent them and what you can do yourself.

CrossmarX gives you the tools to build a web based application and website. All data and files can contain data you prefer not to share with others. Also you do not want to enable identity fraude in some way. Malignant users have easy access to a free available set of tools on the net. It is shockingly simple to take over someones identity or destroy someones database.

Exposing data to the public with caution

A CrossmarX Application has three major components that are at risk of exposure:

A database; user data and system data.
Database related objects like images, pdfs stored as files on the filesystem. We call them blobs (short for binary large objects)
Application files; HTML files, style sheets, images, Javascript files and all Velocity scripts.

These three major components do contain data that might be vulnerable and should not be exposed or used by false users.

In general the CrossmarX Engine already has tools to prevent false exposure or illegal usage of your data.

Encryption of certain important data fiels in the database. Examples are passwords, creditcard data
Use a fine-grained permission system to define which user can see, edit, or delete a specific data object or parts of it. Aso the download of blobs are organised in that way.
Use secure SSL sockets to communicate with the users device or browser.
Gives you a detailed automated report of risks during development or production through use of the security analyzer.
IP restriction for some usergroups.
XSS (Cross-site scripting) prevention and/or possible XSS detection.

Application files

Generally speaking, all files in your application directory are directly accessible by browsers. The only exception are Velocity files using the .vm, .pm or .am extension. Velocity files with extension .vm are executed by the engine to generate content. Files with the .pm extension are hidden for the public and only visible for other .vm or .pm velocity scripts.
Mind you every other file is visible for the public. This means they are also found by searchbots. Searchbots can be disallowed access to files through use of the robots.txt file. For more information on the use of robots.txt, see this page.

Blobs

Public blobs: When a blob field is ticked as public it is visible for all. This means the blob is accessible directly without permission checks. If you do not want your blobs to be visible in Google or others, untick the public property of a blob field.

Private blobs: A private blob is only visible for users with matching relevances.

If you changed a blob field from public to private (or vice versa) you need to check the location they are stored. Use the blob location checker at the application panel under database.

Session life time

Keep the session time out as short as workable. Some application managers tend to use long time outs. It can be tempting to do so for of ease of use.
This is a risk because the longer a session cookie is valid the easier it is to steal it. Or use your computer while the user is away.
Banks therefore keep the session timeout as short as possible. 30 minutes is a good secure value.

IP restriction per usergroup

The engine is able to restrict access to an application and usergroup from some IP addresses only.

XSS

The risks of Cross-site scripting are commonly known. In our security report you can see which field in the blueprint can be vulnerable for XSS.
Be careful with injecting values from requests into Velocity pages. These are not checked by the security report generator. (See Access of request variables further below)

Encryption of data in the database

Refer to this page, to learn how to encrypt data in the database.

HTTP/HTTPS

When possible use the "HTTPS only" property in the blueprint properties. The whole application will only be accessible using https.

If no https certificate is available for your domain, you can use a CrossmarX certificate on our production server (only if your app is hosted on a cx server) to logon. Use the "Use https for login" property in the blueprint security tab.

Some general DO's and DON'Ts

A number of field properties can be set to alter the permissions relevant to the field. Use these properties with caution!
- Apply read permission of foreign class. This property is used for fields with a foreign class to determine if the read permission of the foreign class should be used to make up the lookup list. When this property is set to false the user will be able to see and select foreign records without having read permissions. Be mindful of the information that is contained in the labels of the foreign class. If, for example, these labels are the first and last name of a person, the user will be shown a list of all persons in the application.

Be careful with injecting sources from thirdparties in your webpages. A <img> tag with a src to a different domain NICE_BUT_DANGEROUS can lead to Javascript injection when the owner of NICE_BUT_DANGEROUS changes the image to a Javascript snippet.
Prevent the use of http requests in a https page.
When you want variables from requests to be embedded in a HTML page, be very careful. If you use #set($var = $request.get("var")) and you display $var two things can happen:
- Possible XSS javascript injection. We detect possible injections. But there is always a risk hackers find new ways to inject. Read more about XSS on this page.
- Or fancier: hackers add HTML attributes with dangerous or unwanted content. This might happen when you embed the result of a $request.get("var") into a HTML attribute. Smart injections can inject a new attribute to the existing HTML tag. If you really need to embed the value into a HTML attribute please prevent this by always using #set($var = $session.getStringOps().escapeHtmlSpecialCharacters($var)) first.