Sign up to save your podcasts
Or
Share The Open Banking Directive and Application Security
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
The Open Banking Directive and Application Security
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:
View all episodes
By Justin FimlaidShow 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: