Getting Started with API Security Testing
Download as pptx, pdf24 likes19,587 views
The document discusses the vulnerabilities and hacking techniques related to API security, emphasizing the importance of understanding API technologies, protocols like HTTP, and various attack vectors such as fuzzing, injection attacks, and cross-site scripting. It outlines methods for detecting attack surfaces and testing for common security flaws, stressing the need for automation in testing and ongoing awareness of vulnerabilities. Additionally, it provides resources and best practices for conducting thorough API security assessments.
Getting Started with API Security Testing
- 1. Ole Lensmar, @olensmar API SECURITY TESTING
- 2. What do these companies have in common?
- 3. Their APIs have been hacked!
- 4. If you wanted to hack an APIโฆ HOW WOULD YOU DO IT?
- 5. Hacking an API โthe basics ๏ต REST and SOAP APIs predominantly use HTTP as their protocol ๏ต Arguments are sent as part of the URL, as HTTP Headers or in the request body ๏ต Message payload is predominantly JSON for REST and XML for SOAP
- 6. Understanding HTTP Transactions Request Response
- 7. Security Standards for Web APIs ๏ต SSL commonly used for transport-level encryption ๏ต Message level encryption and signatures: โ SOAP/XML: WS-Security and related standards โ REST: JSON Web Algorithms ๏ต Authentication โ SOAP: WS-Security/SAML โ REST: Oauth 1 + 2, OpenID Connect, SAML, custom
- 8. So, weโre hackersโฆ WHERE DO WE START?
- 9. API Attack Surface Detection ๏ต We want to know as much as possible about an APIs endpoints, messages, parameters, behavior ๏ต The more we know โ the better we can target our attack! ๏ต Unfortunately though โ an API has no โUIโ that can show is the attack surface
- 10. Attack Surface Detection: API Metadata The more we know, the easier it isโฆ ๏ต api-docs.json ๏ต WSDL/XML Schema ๏ต Swagger, RAML, API-Blueprint, ioDocs, etc ๏ต Hypermedia (JSON-LD, Siren, etc) ๏ต Documentation / Developer Portals Choosing between usability vs hackability
- 11. Attack Surface Detection: API Metadata the point of attack HTTP Method: Are other methods handled correctly? Oauth 2.0: are tokens enforced and validated correctly? Is access validated? Are ids sequential? Injection point?,etc What if we send multiple? Or none at all?
- 12. Attack Surface Detection: Other Methods ๏ต Discovery โ Record traffic via proxy or network sniffer to record and โlearnโ an API ๏ต Brute force โ Try commonly used endpoints (/api, /api/v1, etc) โ Use error messages to uncover possible paths
- 13. With an Attack Surface, we canโฆ ๏ต Fuzzing ๏ต Injection attacks ๏ต Invalid / Out-of bounds content ๏ต Malicious content ๏ต Cross Site Scripting ๏ต Cross-site Request Forgery
- 14. Why Hack an API? ๏ต Provoke error messages or responses that give us system details โ Database names โ File paths โ Component versions โ Etcโฆ ๏ต Find security holes that give us access to system resources ๏ต Put the API in an unavailable or unstable state (DOS)
- 15. API Attack Methods HOW DO WE TEST FOR THEM?
- 16. API Fuzzing What is it? ๏ต Send random content as input parameters ๏ต Automation can help us send millions of permutations ๏ต Recursive Fuzzing โ try all possible values ๏ต Replacive Fuzzing โ try common attack vectors How do we test for it? ๏ต Create automated fuzz tests that validate response messages to: โ Not conceal system information โ Return correct error messages / status codes ๏ต Run them for a long time ๏ต Run them in parallel / as load tests
- 17. Injection Attacks What is it? ๏ต Using SQL, XML, Xpath, JSON, JavaScript etc, attempt to inject code that is executed where it shouldnโt be ๏ต Primary injection: code is executed on the server ๏ต Secondary injection: code is executed by 3rd party ๏ต Example: "SELECT * FROM pets WHERE petID='" + petId +"'"; http://petstore.com/api/v1/pet/123 -> SELECT * FROM pets WHERE petID = โ123โ http://petstore.com/api/v1/pet/' or '1'='1 SELECT * FROM pets WHERE petID = โโ or โ1โ = โ1โ How do we test for it? ๏ต Understand how the API works: SQL? NoSQL? Other APIs? ๏ต Use well known injection vectors โ validate for โunexpectedโ responses ๏ต For example: validate that login call does not log you in ๏ต Automate security tests
- 18. Invalid / Out-of-bounds attacks What is it? ๏ต Send input that we know is invalid โ Out of range numbers โ Invalid dates โ Invalid enumeration values โ Invalid data-types / formatting ๏ต Can be auto-generated if the API has โgoodโ metadata How do we test for it? ๏ต Send input that you know is invalid โ Out of range numbers โ Invalid dates โ Random enumerations โ Etc. ๏ต Validate for: โ Not displaying system information โ Returning correct error messages / status codes
- 19. Malicious Content What is it? ๏ต Where files/images are uploaded/โattachedโ; attempt to upload executable files/scripts/etc ๏ต Exploit server side parsing of content ๏ต Example of XML Bomb: How do we test for it? ๏ต Attempt to upload files that do no harm but indicate that they have incorrectly handled ๏ต Both corrupt versions of accepted formats, and invalid formats. ๏ต Validate that you get the right error messages! ๏ต Test for parse vulnerabilities โ use known Vectors Be careful with this oneโฆ
- 20. Cross-Site Scripting What is it? ๏ต Reflective XSS: Malicious script is included in link and โreflectedโ back to user ๏ต Persistent XSS: Malicious script is injected into backend system and retrieved by user How do we test for it? ๏ต In either case โ create functional API tests that upload common attack vectors ๏ต For Reflective XSS tests: validate that they are escaped (or removed) in the response ๏ต For Persistent XSS tests: create end-to-end test that simulates the โother clientโ and validates correspondingly
- 21. Cross-Site Request Forgery (CSRF) What is it? How do we test for it? ๏ต The common workaround is to include an unpredictable token with each request ๏ต Create functional tests that validate: โ The API call fails without that token โ Tokens can not be re-used ๏ต Run a fuzzing test on the token itself to validate that it canโt be spoofed or bypassed Point of attack!
- 22. Insufficient SSL configurations What is it? ๏ต Eavesdropping on API traffic ๏ต APIs should always use SSL โ but sometimes they donโt, or it isnโt enforced (HTTP works also) ๏ต Is the SSL certificate self-signed? (browsers will warn you โ but code in a native mobile apps might silently allow access) How do we test for it? ๏ต Create simple tests that fail if HTTPS is not enforced ๏ต Create simple tests that fail if certificates are self signed ๏ต Run these in production as monitors โ small system configuration changes/tweaks could have side effects
- 23. Insecure Direct Object References What is it? ๏ต For parameters that are IDs and seem to be sequential, try submitting IDs to get access. ๏ต In Query Parameters, Headers and Message Bodies ๏ต Call methods/operations that you shouldnโt have access to How do we test for it? ๏ต Inspect actual API requests / metadata You should question usage of direct object references! ๏ต Create functional tests that validate authorization enforcement ๏ต Combine with fuzzing or boundary tests on IDs
- 24. Other things to think aboutโฆ Bad Session/Authentication Handling ๏ต Are session tokens re-used or sequential? ๏ต Do session tokens timeout correctly? ๏ต Are tokens exposed in unencrypted traffic? ๏ต Are tokens added to URL when sending links? ๏ต Are login endpoints restricted? Bad security configuration ๏ต Based on error messages and system information exposed by previous attacks ๏ต Target all layers โ Network โ Server โ Application โ Client ๏ต Examples: โ exposed management consoles โ directory listings โ stack-traces โ default passwords
- 25. So where does this leave us? GENERAL CONCEPTS TO REMEMBER
- 26. API Security Testing requires you to ๏ต Understand API Technologies ๏ต Understand the API and its implementation ๏ต Understand how Security Vulnerabilities work
- 27. Putting it into practice ๏ต Automate Basic Security Tests using free tools ๏ต Run automated Security Tests simultaneously as Load and Functional tests ๏ต Stay up to date on Vulnerabilities
- 28. Resources OWASP: http://owasp.org WS-Attacks: http://ws-attacks.org/ Zed Attack Proxy (ZAP): https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Ready! API Secure: http://smartbear.com/product/ready-api/secure/overview/