Show Notes: https://www.nuharborsecurity.com/open-banking-directive-and-securing-web-application-vulnerabilities/

Sponsor: https://www.nuharborsecurity.com

Contact Me: https://justinfimlaid.com/contact-me/

Twitter: @justinfimlaid

LinkedIn: https://www.linkedin.com/in/jfimlaid/

Application Security Checklist for Web Applications and API’s. Also @ NuHarbor Security.

I have not seen an Open Banking Web Application Checklist, so hopefully this is a good starting point for some.

1.Ensure HTTPS:

This one is pretty simple but HTTPS protects authentication credentials in transit for example passwords, API keys, or JSON Web Tokens. It also allows clients to authenticate the service and guarantees integrity of the transmitted data.

2. Security Tokens: 

There seems to be a convergence toward using JSON web tokens as the format for security tokens. JSON web tokens are JSON data structure containing a set of claims that can be used for access control decisions. If you are looking for more on JSON formats, here’s a good starting point.

3. Access Control:

Non-public rest services must perform access control at each API endpoint. Web services in monolithic applications implement this by means of user authentication, authorization of logic in session management.  To this right at scale, user authentication should be through a centralized Identity Provider which issues their own tokens.

4. Input Validation:

Anyone developing for a while knows this is a requirement.  If you don’t sanitize inputs your application days are numbered.  Contact me if you want the full-list on this one.

5. Restrict HTTP Methods:

Apply a whitelist of permitted HTTP Methods (e.g. GET, POST, PUT) and make sure the caller is authorized to use the incoming HTTP method on the resource collection, action, and record.  Leverage 405’s when rejecting all requests not matching the whitelist.

6. API Keys:

API Keys can reduce the impact of denial of service attacks. However, when their issue to third-party clients, they are easy to compromise.  There are a couple things you can do to mitigate security risks including require API keys for every request to the protected endpoint. You can also returning a 429 message “too many requests” if the volume of requests are to high. Do not rely solely on API keys to protect high-value resources.

7. Validate Content Types:

A rest request a response body should match the intended content type in the header. Otherwise this can cause misinterpretation at the consumer/producer side lead to code injection/execution.  Some additional things to think about:

  1. Validate Request Content Types
  2. Send Safe Response Content Types

8. Manage Endpoints:

There is a couple things you can do to securely manage your end points. Avoid exposing your management and points by way of the Internet. If your management and points must be accessible to the Internet, make sure that all users authenticate using strong authentication mechanisms such as multi factor authentication. Security by obscurity is not always a good strategy, but exposing management endpoints by way of different HTTP ports or host on different/restricted subnets can also reduce some risk.  Lastly restrict access to these endpoints by firewall ACL’s.

9. Error Handling:

Keep error message is generic in nature. Try to avoid revealing details of any and all failures when necessary. This will help prevent giving the potential attackers the information they need to game the system or perform a secondary attack with the new information.

10. Security Headers:

This one is sometimes overlooked, but to make sure the content of the given resources is interpreted correctly by the browser, the server should always send the “content-type” header with the correct content type, and preferably the “content-type” header should include a charset.  The server should sent the “X-Content-Type-Options: nosniff” security header to make sure the browser does not detect a different “content-type” that what is actually sent as that can lead to XSS.

11. Cleanse Sensitive Information in HTTP Requests:

Penetration testing companies make a living on gleaning sensitive information from HTTP requests. When using RESTful web services should be careful to prevent leaking credentials. Passwords, security tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them intrinsically valuable.

  • In POST/PUT requests sensitive data should be transferred in the request body or request headers.
  • In GET requests sensitive data should be transferred in an HTTP Header.

12. Cross Origin Resource Sharing (CORS)

CORS is a W3C standard to flexibly specify what cross-domain requests are permitted. By delivering appropriate CORS Headers your REST API signals to the browser which domains, AKA origins, are allowed to make JavaScript calls to the REST service.

  • Disable CORS headers if cross-domain calls are not supported/expected.
  • Be as specific as possible and as general as necessary when setting the origins of cross-domain calls.

13. Audit Logs:

Write audit logs! I can’t stress this enough – I see many organizations that do not log their web activity before and after a security related event.  The result is those organizations can not appropriately investigate or remediate a security problem on in their application.