Api security-testing
1 like•1,567 views
1) The document provides guidance on testing APIs for security weaknesses, including enumerating the attack surface, common tools to use, what to test for (e.g. authentication, authorization, injections), and demo apps to practice on. 2) It recommends testing authentication and authorization mechanisms like tokens, injections attacks on state-changing requests, and how data is consumed client-side. 3) The document also discusses testing for denial of service conditions, data smuggling through middleware, API rate limiting, and cross-origin requests.
Api security-testing
- 1. API Security Testing By: Riyaz Walikar Appsecco | https://blog.appsecco.com @riyazwalikar | @wincmdfu | https://ibreak.software
- 2. Quick talk on some things you can do while testing APIs for security weaknesses
- 3. Before testing • Ask and obtain written permission!
- 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
- 5. Common Tools to Test
- 6. Tools • Burp Suite • curl • Fiddler • Postman • newman • swagger • SoapUI • Rest-Assured
- 7. What to test for?
- 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: [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)
- 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
- 23. 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
- 24. Questions • Riyaz Walikar • @riyazwalikar • @wincmdfu • https://ibreak.software • https://blog.appsecco.com