RESTful web services security

Consider the following topics when you are doing security planning for RESTful web services.

User authentication by WebSphere Application Server

WebSphere® Application Server authentication is used to do user authentication for RESTful web services, which means that users must be defined in the user repository that is used by WebSphere Application Server. The supported authentication methods are shown in the following list:
  • Basic
  • Parameter
  • Cookies
  • Client certificate
Note: Basic authentication provides the user credentials in the request header instead of in the URI, similar to the parameter authentication method. For better security, strongly consider doing HTTPS and basic authentication for RESTful web services.

Certificate-based client authentication extracts the username from the certificate that was used to establish the SSL connection between the client application and the WebSphere Application Server Liberty server. Configure the certificate to username matching in the user registry that is used by the WebSphere Application Server Liberty server. For more information about how to enable this authentication by using configuration drop-ins, see the security configuration documentation that is contained in the documentation fix pack that is available to entitled users.

Lightweight Third Party Authentication (LTPA) configuration

The following WebSphere Application Server configuration that is specific to LTPA is required when LTPA tokens are used:
  1. Ensure that application security is enabled.
  2. Configure LTPA key generation according to your needs.

LPTA token expiration

The initial web service invocation authenticates the user ID and password by using either basic or parameter authentication. The response to this initial web service invocation contains a Lightweight Third Party Authentication (LTPA) token, named LtpaToken2. The LtpaToken2 token can be used as a credential by subsequent web service invocations that use cookie-based authentication. The advantage of using the cookies authentication method is that the password does not have to be provided with every request.

A disadvantage of using the cookies authentication method is that the LTPA token on the WebSphere Application Server can expire. When the token expires, the client application receives a WebServiceException with status code 401 indicating that the attempt to log in was unauthorized. Because this error cannot be differentiated from any other standard authorization failure, consider implementing a way to retry the authentication. For example, retry the authentication by sending the credentials by the basic authentication method whenever this error is received.
Note: The LTPA token expiration time is at least 2 hours and is configured by using the WebSphere Application Server administrative console. The timeout value is changed in Global security → LTPA. The LTPA token expiration time is the value that is configured for the timeout plus 2 hours.

HTTP header security

By default, the web services use the no-cache and no-store options in the Cache-Control header field in the HTTP response header. For better security, consider setting these same options in the Cache-Control header field in the HTTP request header too.

A default HTTP response header is appended to each web services response. You can customize the response header that is used for the web services by changing the HTTP Response Headers property on the system properties page.

HTTP header logging security

Some of the web services build a request URL that includes the specific values that are used to query information. The information from these query parameters can be logged by any server that receives the request. If you do not want this information to be logged, ensure that all of the servers that receive the request are configured to suppress the logging of URL query parameters.

For example, see the NCSA access log setting information in the WebSphere Application Server documentation.

Encode or escape output properly

These web services are provided for your applications to use. However, the web services do not modify the data values that they return. You must determine whether your application needs to escape or encode any of the values that are returned by the web services.

The following list shows some examples of when an application might need to escape or encode the data that it receives from a web service.
  • A browser-based application needs to escape characters that might be interpreted as JavaScript and rendered in the browser.
  • An XML-based application needs to escape data that might be interpreted as XML tags.

For more information about encoding and escaping output, see the OWASP website: https://www.owasp.org.

Disable the welcome page for WebSphere Application Server Liberty

By default, WebSphere Application Server Liberty shows a welcome page. This welcome page can cause hidden directories or files, such as images or JavaScript files, to be available to everyone without requiring the appropriate authentication. To avoid this problem, disable the welcome page for every WebSphere Application Server Liberty server that is hosting your web services. You can use the following configuration to disable the welcome pages. 
<httpDispatcher enableWelcomePage="false"/>

JSON input representation

All RESTful web services can accept JSON formatted input by default. The input name and value pairs are parsed from the JSON that was received. If the value for an input parameter is surrounded by quotation marks, the parser treats it as character-based input. If the value for an input parameter is not surrounded by quotation marks, the parser treats it as numerical input.

Consider the following example JSON.
{
   "participantAddressCity": 111
}

In this example, the participantAddressCity parameter is probably expecting a character or string value. However, because the value that is provided for participantAddressCity in this JSON does not have quotation marks, it is interpreted as a numerical value. The value is converted to 111.0 and is stored in the FTM database as the value for participantAddressCity. This example input does not cause a security problem because the numerical value can be stored in the database and it is displayed as a string on the user interface pages.

However, to prevent confusion or other problems, ensure that your JSON input for a web service is correct. For example, make sure to use quotation marks around the values that are provided for input parameters that expect characters or strings. And, make sure that numerical values are not surrounded by quotation marks.

References

For more information, see the IBM WebSphere Liberty documentation in IBM Documentation.