Akana recently surveyed over 200 architects, managers and DevOps experts about their API security practices, and it is clear from the below graphic that many are seeking advice and a solution to mitigate a wide array of API attack vectors as they attempt to do business in the public cloud securely.
1. Man/Bot-In-The-Middle / Session high-jacking / Identity Theft
- API Attack Vector: A Man or Bot-In-The-Middle using packet capture technology on shared public circuits between the API consumer and the API server could intercept authentication credentials in the request URL as a query parameter or in the Authorization header. Identity theft is also possible by acquiring the credentials of a valid user as a result of a data breach, brute force password cracking, or social trickery such as phishing sites.
- API Gateway Mitigation Technique: Mutual TLS certificate checking on the client and server side with the use of pinned certificates reduces the probability of this occurring by encrypting the socket, however certificate pinning https://www.owasp.org/index.php/Pinning_Cheat_Sheet is still vulnerable to DNS attacks that trick the API client to request a pinned certificate from a phishing site pretending to be the actual API server. The use of antiquated authentication protocols such as basic authentication that send an encoded password with each request message should be avoided, in favor of tokens that last for minutes instead of hours or days. Use an HMAC signature and a nonced MAC OAuth token http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03 instead of a BEARER token to further reduce the probability that a token intercepted on a public unencrypted Wi-Fi network or copied from a server log file may be replayed to the API gateway. For information on the Akana API Gateway OAuth Security Policy, see http://docs.akana.com/ag/cm_policies/using_oauth_security_policy.htm
2. SSL Protocol Downgrade
- API Attack Vector: Bot-nets or malicious API clients may attempt to take advantage of legacy exploits not yet deprecated in the client or server. For example the recent “POODLE” https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566 vulnerability was present in web browsers and even the Oracle JVM until February 2015 because SSL v3 (an 18 year old protocol) was still shipping and enabled which permitted the SSL handshake to be performed using a weak process that leaked certificate details, thereby enabling those with the stolen keys to decrypt any packets captured by a man-in-the-middle. If you are not sure if your client is vulnerable to the POODLE SSL v3 downgrade, then find out at https://poodletest.com
- API Gateway Mitigation Technique: Ensure that API clients and API servers and API Gateways are continuously patched to ensure that recent zero day vulnerabilities are addressed and any antiquated encryption algorithms and protocols are deprecated from environments connected to public networks. Pay attention to the new HTTP/2 RFC http://tools.ietf.org/html/rfc7540 as it is the most recent advancement being made to improve network encryption security protocols by requiring the use of TLS 1.2 http://www.ietf.org/rfc/rfc5246.txt with compression disabled to further reduce the probability of accidental data leakage. For information on properly installing and configuring Akana API Gateways, and how to change to a current JRE http://java.com/en/download/ and BouncyCastle http://bouncycastle.org/ version, see http://docs.akana.com/ag/pm_install_guide_v7.2.html
3. Authenticated but not Authorized API Clients
- API Attack Vector: User A authenticates with the API Gateway using a valid ID and credentials, but then reconstructs the API request being made by the client application to guess a different account number parameter in attempt to execute a transaction or request data belonging to a different user.
- API Gateway Mitigation Technique: SAML http://www.rfc-editor.org/rfc/rfc7522.txt and OAuth http://tools.ietf.org/html/rfc6749 tokens may be decorated with attributes to correlate an account number with the e-mail address, user ID, or app ID used to request the token. Verify the account number as an authorization factor prior to responding with the data requested to prevent accidental data leakage or the execution of a transaction. This may be accomplished on an API gateway by leveraging a mediation and orchestration patterns such as a BPEL process that does not connect to the protected API behind the gateway until after the multi-factor authorization step passes verification by invoking a fraud detection / account owner verification API prior to invoking the protected API. For information on using Akana Policy Manager to design a custom BPEL process that executes on an Akana API Gateway, see http://docs.akana.com/ag/processes/process_management.htm
4. Rooted Mobile Devices leaking client application IDs and shared secrets
- API Attack Vector: Mobile Applications that use shared secrets to request OAuth tokens may be a source of credential leakage if the application ID and secret is stored in clear text in the client application code.
- API Gateway Mitigation Technique: Instead of using shared secrets to request tokens, configure the API Gateway OAuth token endpoint to integrate with a secured keystore to verify a certificate stored in a p12 encrypted X.509 client certificate keystore to connect to the API gateway with Mutual TLS. Consider a mobile device container to encrypt the entire process on the mobile device that is running the client application code. And rather than relying on protocol level encryption alone, leverage X.509 keys to encrypt/decrypt body of the message payload itself. For more information on integrating an Akana API Gateway with an External Keystore on a Hardware Security Module (HSM), see http://docs.akana.com/sp/key_management/using_external_keystore.htm
5. Malicious Code / SQL Injections
- API Attack Vector: Authenticated API consumers may still be malicious even though they are valid users and authorized to use the API with their own credentials. API requests containing escape characters followed by SQL queries such as ‘select * from tablename’ in the REST URL GET path or query parameters, headers as well as the XML or JSON body of a POST request expose the database connected to the API to SQL injections which may leak or corrupt significant amounts of protected data.
- API Gateway Mitigation Technique: Leverage an API Gateway to inspect the parameters of API requests for such patterns using Regular Expression to detect and stop such requests from ever leaving the API Gateway. Since the API Gateway has no direct connect to the SQL database, even if the SQL injection ran on the API gateway there would be no connection to a database for any data to be returned, yet another value proposition to introduce a mediation (aka DMZ) tier in front of the app/database tier with a tolerable added latency of 2-20 milliseconds to perform such input validation on each message. For information on how to use the Akana Malicious Patterns Detection policy to mitigate this threat, see http://docs.akana.com/ag/policies/using_http_malicious_pattern_detection_policy.htm
Many survey respondents are also focused on compliance with regulatory standards such as PCI to protect credit/payment card data and privacy directives such as HIPAA and the EU Privacy Directive to ensure that protected health information is kept confidential.
By governing the usage of APIs with an API Gateway and properly managing the SDLC process to ensure that security technologies are properly configured one will be well on their way to passing their next vulnerability assessment to obtain certification that the current industry specific security and privacy best practices are implemented properly.