SEVEN things about API security
Abstract
Good presentation about API security. The speaker talk about the fact that API security differs from the other web security because it’s quite different. There’s also a top 10 OWASP API security that can be useful to look at. The speaker made a demonstration on a basic way to find out if a login is already used or not, which can be critical if the login is an email (which often is):
- If the error message differs when an account does not exist and if the password is wrong, then the attacker knows which email they can socially attack (by sending a phishing email for example).
- Mitigate by having the same error message for both situations.
- In general, the password is encrypted by using an asymmetric algorithm, like BCrypt, so it takes some compute time to encrypt and check the encrypted value against the one stored in database (along with the salt, of course). So the attacker can verify the existence of the account by checking the response time.
- Can be mitigated by encrypting a false password if the account does not exist, which will make the response time the same for both situations.
Another security aspect the speaker talk about is the fact that API are returning too much information, and an attacker can investigate and knows which API can be used to fetch some sensitive information, like an email or postal address. This can be mitigated by returning only the necessary data to the clients, but I think it can be difficult in some situations (otherwise, we would have to implement a backend for frontend for every client…).
There’s other common security breaches, especially on authorization:
- Using role based can be difficult to scale and maintain, e.g. `hasRole(“ROLE_FAMILY”).
- Use permission-based instead, e.g.
canAddFamilyMember
, and have roles that contain a collection of permissions instead.- Ensure the resources are also scoped to the right users, e.g. do not let other user add new role.
Reviews
Why did I want to read/watch this? Security is really important, but often neglected because we want to deploy new features all the time. However, it’s often after the evil is performed that we remember that security must be taken into account in our product design.
What did I get out of it? I expected to not learn much from this presentation, but I was quite surprised to learn some stuff, especially the response time on the login form to know if an account exists or not. That’s quite logical in after thought. That makes me wonder that lots of situations where some use cases are abused by attackers, and we may not know we’ve been infiltrated. I can bet there are lots of companies that are already compromised, but the attacker just collects data to sell them, and the companies do not even know about it. Anyway, lots of things to learn from this presentation, and the top 10 OWASP API security to check out.