Security by Design in OTRS 8
11/05/2020 |

Security by Design in OTRS 8

OTRS 8 was designed using Security by Design principles.
Read what has changed in the new release.

Laptop shows OTRS screen on a desk with headline tech talk

This blog article explores six significant improvements in the software security of OTRS 8 over previous versions. We’ll look at how they affect developers, administrators and users.
The principle Security by Design affects different aspects of the OTRS software. It:

  • Secures software architecture,
  • Aids developers in writing secure code,
  • Encourages users to work with their system in a responsible way, and
  • Supports administrators in configuring their system securely.

In the following, we’ll look at six examples of Security by Design in OTRS 8. After looking at some technical details, we’ll analyze who can benefit from each in which way.

Content Security Policy

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of cyberattacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement to distribution of malware.

You can think of using a CSP as giving the web browser instructions about what resources (pictures, videos, etc.) are allowed for use and what should be prohibited. This is important to prevent others from executing code or loading external resources on your website.

Users can trust that OTRS works with their browser to protect them against common cyberattacks.

With OTRS 8, a Content Security Policy is set up on the OTRS frontend application, restricting access to the current server only. All resources are restricted as much as possible. Examples:

  1. JavaScript can only be loaded from the server folder where the app is stored. Other scripts are discarded. This is a major improvement over ((OTRS)) Community Edition 6 in which inline scripts had to be allowed for technical reasons.
  2. External images cannot be loaded within the application. If a user or attacker tries to use external images, the browser will refuse that request and log the error.

How does this affect:

  • Users: They can trust that OTRS works with their browser to protect them against common cyberattacks.
  • Administrators: They may need to update the system’s configuration to allow external content if it does need to be integrated into the application.
  • Developers: They don’t have to care – this is active by default.

 

JSON Web Tokens

JSON Web Tokens are an open, industry-standard technology that allows for secure communication between two parties. It’s like using a digital signature so that you can trust that you’re receiving the safe information. In OTRS 8, JSON Web Tokens are used to identify users in a secure way. Key benefits over the previously used cookies are:

  • The tokens are not visible to the user (for example, via the URL).
  • They are not automatically sent by the browser.
  • Their built-in cryptographic signature prevents user manipulation of the token.
  • The tokens can be checked or removed by the administrator on the server.
  • As before, tokens are limited to remote IP address by default (but this is configurable).

How does this affect:

  • Users & Administrators: The system continues to work in a most convenient but more secure way.
  • Developers: Requiring a valid token is easy.

 

Restricted Cookie Usage

Unfortunately, there are still some components of web-based applications that require cookies. For example, loading inline images and loading an iFrame still rely on built-in browser mechanisms to check that the source is trustworthy. This isn’t as safe as the aforementioned JSON Web Tokens.
So, to mitigate the possible negative consequences of cookie usage, the following changes were made:

  • Cookies will contain the same secure JSON web token to prevent manipulation.
  • Cookies are now restricted as much as possible to guard against cross-site request forgeries, which is when someone attempts to gain access to your site and force you to take unintended action (like sending money or upvoting content).
Validating input data becomes fun after all!

Deep Input Validation

Input validation is an important topic for application security. You want to make sure that data coming from the outside world into the application matches what is expected. In a security context, this is partly to make sure that the data does not contain any hidden code that could work like a cyberattack, such as a SQL Injection, Cross Site Scripting and so on.
OTRS 8 contains a new API that can be used for deep input data validation. It is very easy to use:

  • First, determine the type of validation you need from a growing list of 38 built-in data validation modules. These range from simple validations, like “this is a positive integer,” to more complex ones, like “valid ticket number that exists in the database” or “valid JSON document.”
  • Second, API Endpoints just need to specify what data they expect. Then, validation happens automatically.

How does this affect:

  • Developers: validating input data becomes fun after all!

 

Extended Password Policies

OTRS 8 has much more effective password policies than before:

 

  1. Password complexity rules can be established, like in previous versions. We leave the more philosophical question of “What makes a good password” to the admin to decide as they configure their system.
  2. Passwords now expire automatically after 30 days by default.
  3. Users are prevented from re-using their previous passwords.
  4. After their first login, users have to choose a new password.

Of course, all of these are configurable – including exceptions for certain users or groups.

How does this affect:

  • Users: This might make life of OTRS agent users a bit harder, but hopefully it will help them handle their credentials in a responsible way.
  • Admins: The restrictive default configuration helps admins to operate their system in a secure way, while offering full flexibility to adapt.

 

2 Factor Authentication

OTRS 8 now has modern real-life 2 Factor Authentication support made possible with three different authentication methods:

  • Apps – use your favorite app like Google Authenticator. Configuration is easy via QR code.
  • SMS – provided via SMS cloud service from OTRS Group.
  • Email – can be used as a fallback option, since all agents usually have valid email addresses. It does support encryption.

In an OTRS 8 system, 2 Factor Authentication is required by default. Of course, it can be made optional for all or selected users, or it can be turned off altogether. It can be used even in Single-Sign-On scenarios where agents use a central login service: In such a situation, users would still have to provide a token for the login to OTRS.

 

How does this affect:

  • Users: Logging into the system takes a little more effort.
  • Admins: The restrictive default configuration helps admins to operate their system in a secure way, while offering full flexibility to adapt.

 

Conclusion

Security by Design in OTRS 8 means:

  • Making the system more secure through its design and architecture.
  • Aiding developers in writing secure code with little effort.
  • Encouraging users to work in a responsible way.
  • Supporting inexperienced admins in the secure operation of OTRS by way of restrictive default configuration while offering much flexibility to adapt.

Interested in learning more about OTRS 8 and how its security options can keep your company safer? Get in touch today.

Text:
Photos: Startup Stock Photos from Pexels; Screenshots from OTRS Group

Leave a Reply

Your email address will not be published. Required fields are marked *

Share the Story