WebApps with LocalStorage and AppCache/White List Server Access

Introduction

In the context of web applications, a whitelist is a security feature that restricts the application's ability to communicate with external servers or domains (see also Commercial Data Harvesting). The primary purpose of a whitelist is

• to prevent malicious scripts to be executed or
• unauthorized access to sensitive data by limiting the application's communication to only trusted and approved server backends.

Workflow for Whitelists

A whitelist is basically the list of trusted servers resp. server backends. Data formats of the whitelist are selected are depended on software environment in which the whitelist should be used. A whitelist as JSON could contain an array of allowed domains for further processing in the software environment.

{
  "type":"whitelist",
  "domains":[
     "www.example1.com",
     "www.example2.com",
     "111.222.131.141"
  ]
}

The example JSON file above can be used as a whitelist in a server backend itself. The type specifies if list of domains is a "whitelist" or "blacklist" and the array of domains is interpreted according to the list.

• Definition of Whitelist: A whitelist as mentioned above is a list of approved domains, IP addresses, or URLs that the application is allowed to communicate with. This list is typically defined by the application developer or administrator, because he/she know which application endpoint is relevant to obtain all the relevant data for the application.

• Restriction: When a whitelist is implemented, the application is restricted from communicating with any server or domain that is not on the whitelist. This means that any attempt to access a non-whitelisted domain will be blocked or rejected. In contrast to a blacklist on which the untrusted servers are listed. The blacklist has the disadvantage that blacklist might miss a few servers that the administrator did not know about or the domain changed and blocking the IP address does not work anymore.
• Security benefits: By limiting communication to only trusted servers, a whitelist helps prevent various security threats, such as:
  • Cross-site scripting (XSS) attacks: Malicious scripts cannot be injected into the application to steal sensitive data or perform unauthorized actions. This could happen when script files are loaded from domains as a child process of domain that is coming from a trusted server.
  • Cross-site request forgery (CSRF) attacks: Unauthorized requests cannot be sent to non-whitelisted servers, reducing the risk of loading data to other servers for which the communication was not intended. Furthermore to prevent executing other malicious activities within the application.
  • Data leaks: Sensitive data cannot be sent to non-whitelisted servers, reducing the risk of data exposure, loss of intellectual property.
• Implementation of Whitelist Access Restrictions: Whitelisting can be implemented in various ways, depending on the application's architecture and requirements. Some common methods include:
  • Content Security Policy (CSP): A CSP is a set of rules that define which sources of content are allowed to be executed within a web page. By defining a whitelist of allowed sources, a CSP can restrict communication to only trusted servers.
  • XMLHttpRequest: The XMLHttpRequest object can be used to send requests to servers. By implementing a whitelist, the application can restrict the domains or URLs that can be accessed using XMLHttpRequest.
  • Server-side configuration: The server-side configuration can also be used to implement a whitelist. For example, the server can be configured to only client requests from specific IP addresses or domains are allowed.

Example of a Content Security Policy (CSP) whitelist defines the default source of communication as "self", i.e. the server the web application is loaded from:

Content-Security-Policy: 
  default-src 'self'; 
  script-src 'self' https://trusted-script-server.com; 
  connect-src 'self' https://trusted-api-server.com;

In this example above the CSP defines with whitelist that:

• Scripts to be loaded only from the application's own domain ('self') and in addition to the own domain also from a trusted script server (https://trusted-script-server.com).
• Connections for data retrieval and the submission of collected data to a specific server can be made only to the application's own domain ('self') and a specifically mentioned trusted Application Programming Interface server specified as (https://trusted-api-server.com).

With the interventions mentioned above HTML5 applications or in general client-server-communication can significantly reduce the risk of security threats and protect sensitive data from unauthorized access. These activities can be part of wider strategy of reduction of vulnerability.

Learning Task

• Create a WebApp that is able to communicate there host server of the WebApp and to specific server for data retrieval (e.g. geospatial data relevant for the current geolocation of the user.
• Explain why the exposure of
  • geolocation,
  • remote search engine of chatbot usage

could leak sensitive intellectual properties e.g. of a company or a research and development unit.