Upgrade to Pro — share decks privately, control downloads, hide ads and more …

API Security Testing - null Bangalore January 2020

riyazwalikar
January 18, 2020

API Security Testing - null Bangalore January 2020

A list of checks/test cases you can run on API endpoints to discover security weaknesses. Talk presented at null Bangalore January 2020.

riyazwalikar

January 18, 2020
Tweet

More Decks by riyazwalikar

Other Decks in Technology

Transcript

  1. API Security Testing
    By: Riyaz Walikar
    Appsecco | https://blog.appsecco.com
    @riyazwalikar | @wincmdfu | https://ibreak.software

    View full-size slide

  2. Quick talk on some things you can do while
    testing APIs for security weaknesses

    View full-size slide

  3. Before testing
    • Ask and obtain written permission!

    View full-size slide

  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

    View full-size slide

  5. Common Tools to Test

    View full-size slide

  6. Tools
    • Burp Suite
    • curl
    • Fiddler
    • Postman
    • newman
    • swagger
    • SoapUI
    • Rest-Assured

    View full-size slide

  7. What to test for?

    View full-size slide

  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?

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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)

    View full-size slide

  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

    View full-size slide

  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!!!!

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  24. Questions
    • Riyaz Walikar
    • @riyazwalikar
    • @wincmdfu
    • https://ibreak.software
    • https://blog.appsecco.com

    View full-size slide