API Security Testing PDF
API Security Testing PDF
API Security Testing PDF
• 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
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
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
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
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
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
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
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
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:
[email protected]` 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)
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
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!!!!
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
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
References
• https://medium.com/@the.bilal.rizwan/wordpress-xmlrpc-php-common-vulnerabilites-how-to-
exploit-them-d8d3c8600b32
• https://smartbear.com/blog/test-and-monitor/api-security-testing-how-to-hack-an-api-part-1/
• https://smartbear.com/blog/test-and-monitor/api-security-testing-how-to-hack-an-api-part-2/
• https://smartbear.com/blog/test-and-monitor/api-security-testing-how-to-hack-an-api-part-3/
• https://github.com/riyazwalikar/injection-attacks-nosql-talk
Questions
• Riyaz Walikar
• @riyazwalikar
• @wincmdfu
• https://ibreak.software
• https://blog.appsecco.com