4. Before testing
• Enumerate your attack surface
• Use the 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
8. Authentication and Authorisation
• Especially, endpoints that use tokens instead 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?
9. Injection attacks
• Any state changing request (POST, DELETE, PUT 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
10. Lookout for client side data consumption
• Any data that 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
11. Data categorisation and response data
• Categorise and identify if the data that is being received, is that
sensitive or not
• Context of sensitivity is important
• Is the transport layer secure
• Is the data inside the transport layer secure
12. Verify response content type
• In some cases, it may 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
13. Lookout for Denial of Service condition
• Test your input 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
14. Data smuggling through middleware
• Most modern APIs get written 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
15. CSRF with APIs?
• APIs are not normally vulnerable to CSRF attacks
• Simply because the condition to perform a CSRF requires the
presence of an authentication token and APIs are designed to use
headers to pass tokens and not cookies (mostly)
• To set headers, you need to have created the request in the same
origin or your request will be subjected to CORS
• That said, CSRFs should be tested incase the server accepts requests
from any reflected origins and uses cookies to implement “Remember
Me” sort of functionality by maintaining state on the server
• Any unconventional stateful API implementation that uses cookies
must be tested like any other web application being tested for CSRF
16. Insecure Direct Object References
• Insecure Direct Object References form 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
17. APIs and Cross Origin Requests
• If the API uses 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
18. Impersonation logic
• Sometimes APIs may be written with the 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:
otheruser@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)
19. Body data in non 2XX responses
• Look at different 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
20. API rate limiting
• Test APIs for rate-limiting as well. 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!!!!
21. API rate limiting
• How the data is being sent 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
22. Demo apps to learn API security testing
• Here are 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
