Security by Design in OTRS 8

Martin Gruner25. Sep 2019 | Cyber SecurityDevelopment

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
  • Support 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 attacks, 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 this as putting the browser in a sandbox mode by instructing it what should be allowed for the current application and what should be prohibited, for example executing code or loading external resources.

With OTRS 8, Content Security Policy headers are set for 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 statically deployed. 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 inject external resources, the browser will refuse that request and log such an error:

How does this affect:

  • Users: they can trust in the cooperation of OTRS and the browser to achieve a high level of built-in application security and protection against common attacks.
  • Administrators: the restrictive default setting requires additional configuration if external content does need to be integrated into the application.
  • Developers: they don’t have to care – this is implicitly used in all API endpoints.

JSON Web Tokens

JSON Web Tokens are an open, industry-standard RFC 7519 method for representing claims securely between two parties. In OTRS 8, JSON Web Tokens are used for cryptographically secured, client-side storage of authentication information. 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 analyzed and revoked on the server.
  • As before, tokens are limited to remote IP address by default (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 as easy as:
with qw(
    Kernel::WebApp::Controller::API::Role::RequiresAgentAuthentication
);

Restricted Cookie Usage

The bad news about authentication information storage and transfer is that some endpoints still require cookies. 🙁 For example, loading inline images and loading an iFrame still rely on browser built-in mechanisms of transferring the authentication data.

To mitigate the possible negative consequences of cookie usage, the following changes were made:

  • Cookies contain the same JSON web token content and are therefore also cryptographically protected.
  • Cookies are now restricted as much as possible to guard against CSRF:
    • Their httpOnly attribute is set, so they cannot be (easily) accessed by JavaScript.
    • Cookies are only accepted by a few endpoints that really need it: Most endpoints don’t accept them.

Deep Input Validation

Input validation is an important topic for application security. You want to make sure that data coming from the outside world to the application conforms to what is expected. In a security context, a part of this is to make sure that the data does not contain any hidden attacks like SQL Injection, Cross Site Scripting and so on.

OTRS 8 contains a new API for deep input data validation which is very easy to use:

  • There is currently a growing list of 38 built-in data validation modules.
  • They range from simple (e. g. “positive integer”) to complex like “valid ticket number that exists in the database” or “valid JSON document.”
  • API Endpoints just need to specify what data they expect, validation happens automatically. As an example, the following snippet shows how an endpoint declares that it receives one mandatory parameter via URL, which is expected and validated to be a TicketID that exists in the database. No further code is needed, the validation happens automatically in the background:
sub ValidationUriParameters {
    return {
        Fields => {
            TicketID => [ 'Required', 'Ticket::TicketID' ],
        },
   };
}

How does this affect:

  • Developers: validating input data is 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 »What makes a good password« to the admin to decide and configure in their system.
  2. Passwords now expire automatically after 30 days by default.
  3. Users are prevented from re-using their previous passwords.
  4. After the 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 helps 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 transport, since usually all agents have valid email addresses. Supports encryption.

In a new 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 – then they still have to provide a token for the login to OTRS.

How does this affect:

  • Users: logging into the system becomes 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 by way of 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.

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

This site uses cookies. By continuing to use the site, you agree to the use of cookies. More information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close