The Open Banking Directive and Application Security




Pwned: The Information Security Podcast show

Summary: Show Notes: https://www.nuharborsecurity.com/open-banking-directive-and-securing-web-application-vulnerabilities/<br> <br> <br> <br> Sponsor: https://www.nuharborsecurity.com<br> <br> <br> <br> Contact Me: https://justinfimlaid.com/contact-me/<br> <br> <br> <br> Twitter: @justinfimlaid<br> <br> <br> <br> LinkedIn: https://www.linkedin.com/in/jfimlaid/<br> <br> <br> <br> Application Security Checklist for Web Applications and API's. Also @ NuHarbor Security.<br> <br> <br> <br> I have not seen an Open Banking Web Application Checklist, so hopefully this is a good starting point for some.<br> <br> <br> <br> 1.Ensure HTTPS: <br> <br> <br> <br> 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.<br> <br> <br> <br> 2. Security Tokens:  <br> <br> <br> <br> 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.<br> <br> <br> <br> 3. Access Control:<br> <br> <br> <br> 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.<br> <br> <br> <br> 4. Input Validation:<br> <br> <br> <br> 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.<br> <br> <br> <br> 5. Restrict HTTP Methods:<br> <br> <br> <br> 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.<br> <br> <br> <br> 6. API Keys:<br> <br> <br> <br> API<br> Keys can reduce the impact of denial of service attacks. However, when their<br> issue to third-party clients, they are easy to compromise.  There are a couple things you can do to<br> mitigate security risks including require API keys for every request to the<br> protected endpoint. You can also returning a 429 message "too many<br> requests" if the volume of requests are to high. Do not rely solely on API<br> keys to protect high-value resources.<br> <br> <br> <br> 7. Validate Content Types:<br> <br> <br> <br> A<br> rest request a response body should match the intended content type in the<br> header. Otherwise this can cause misinterpretation at the consumer/producer<br> side lead to code injection/execution. <br> Some additional things to think about:<br> <br> <br> <br> Validate Request Content TypesSend Safe Response Content Types<br> <br> <br> <br> 8. Manage Endpoints: <br> <br> <br> <br> 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.<br> <br> <br> <br> 9. Error Handling:<br> <br>