This is a summary of the OWASP YouTube video I watched, hosted by Katie Paxton:
Check if the user has access to the resource being edited. You can check this by:
- Logging out and trying to access the resource OR
- Logging with a different user credential and try to edit the resource of someone else
- Check if you can find API keys by Google Dorking
- Check if the API has some form of generating API keys without securing them
- Test Login, logout, reset password, etc
- The endpoint returns too much information, it could be sensitive.
- Check what responses are you getting back.
- Check if the server has enough resources to match the demand of the users
- Giving users roles or levels of access, you can check if the API is granting permissions that the user role shouldn't have.
- Have a lower permission user and a higher permission user and check if they have access to resources they shouldn't
- Gives an endpoint the ability to modify things that aren't suposed to be modifyable by it. For example, an ednpoit to edit a user, should be able to change the name, email, etc but not the password. Say with additional parameters.
- This could be stuff like misconfigured http headers, resource sharing (CORS) and verbose error messages containing sensitive information
- Unsanitized strings by the API resulting in SQL Injection, or maybe Javascript injection on a mobile app
- This is common when atlking about different API versions. Sometimes the developer leaves versions of an API with bugs or open endpoints with less security
- If you don't have enoough logging how is a team supposed to trace an attack?
- Ffuf
- Kiterunner Http Proxies:
- Owasp Zap
- Burp Suite Pro/Community. Check addons: Autorize, InQL (GraphQL) Request Crafting:
- Postman