guide security quick S8 Basic Data Protection

Table of Contents

• S8 Basic Data Protection
  • S8-1
  • S8-2
  • S8-3
  • S8-4

S8 Basic Data Protection

This package describes basic data protection controls.

S8-1

All forms containing sensitive information have disabled client side caching, including autocomplete features.

Purpose: All sensitive data cannot be cached beyond the scope of the users request, as this would open door for a potential data leak.

Solution: First of all the system owner must define what information is sensitive in the systems context. Please note: there is no clear definition of what sensitive information is. Usually this category includes (this list is not exhaustive):

• law protected data,

• data protected by a customers policy,

• passwords.

For all form fields containing sensitive information the browser caching must be disabled with autocomplete=off.

Note	The Chrome browser ignores the autocomplete=off attribute. If it is explicitly required by the system owner to suppress the client side caching in Chrome as well, this web page describes a workaround.

S8-2

All sensitive data is sent to the server in the HTTP message body (i.e., URL parameters are never used to send sensitive data).

Purpose: There might be a technical need to turn on request logging on the web server on any part of the application platform. Should this be the case, we will not want any sensitive data to be exposed in the application logs.

Solution: For an explanation what sensitive data is please refer to solution S8-1. Compliance with this requirement is not be enforced by the devonfw platform. The systems architects and developers must follow the rule of never using URL parameters to send sensitive data.

S8-3

The application sets appropriate anti-caching headers as per the risk of the application, such as the following: Expires: Tue, 03 Jul 2001 06:00:00 GMT ; Last-Modified: {now} GMT ; Cache-Control: no-store, no-cache, must-revalidate, max-age=0 ; Cache-Control: post-check=0, pre-check=0 ; Pragma: no-cache

Purpose: It is usually a good idea to turn off caching for every request to dynamic system data (like HTML and REST calls) per default. It is not allowed to store or cache sensitive data in the users browser, as they could be recovered by the attacker with physical access to the user agent (after the legitimate user session ends).

Note	You can (and probably should) use caching for static, non-sensitive data like images, JS and CSS files, …​

Solution: Spring Security sets some default response headers which is a nice secure default of the Spring platform itself. Header definition like Cache-Control: no-cache, no-store, max-age=0, must-revalidate and Pragma: no-cache is enough to turn off caching for the modern browsers. All the developer needs to do is not disable the default headers definition.

S8-4

Data stored in client side storage (such as HTML5 local storage, session storage, IndexedDB, regular cookies or Flash cookies) does not contain sensitive data or PII.

Purpose: As in S8-3, this could expose sensitive data to an attacker with physical access to the user agent.

Solution: This needs to be handled by the DEV team this way.