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:

Validate Request Content TypesSend 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 he…

Pin It on Pinterest

Share This