November 27, 2020

API Security

Web services were originally designed to communicate using SOAP (Simple Object Access Protocol), a messaging protocol that sends XML documents over HTTP. Today, most web-based APIs use REST (Representational State Transfer)

API Attacks

REST API

  • MitM
  • SQLi
  • XSS
  • DDOS
  • Can resources be accessed using HTTP instead of HTTPS?
  • Do all endpoints require authentication?
  • If file upload is supported, what happens if you upload a potentially malicious file, with the mimetype that is expected by the application?
  • If the web-app that consumes the API embeds user-supplied information on the page, what happens if you supply malicious javascript instead?
  • Can you access resources that your token isn’t authorized to access?

API Defenses

Use an API Gateway

  • Akamai API Gateway
  • AWS API Gateway
  • Azure API Management
  • Google API Gateway

Authentication

  • Don’t use Basic Auth. Use standard authentication instead (e.g. JWT, OAuth).
  • Don’t reinvent the wheel in Authenticationtoken generationpassword storage. Use the standards.
  • Use Max Retry and jail features in Login.
  • Use encryption on all sensitive data.

JWT

  • Use a random complicated key (JWT Secret) to make brute forcing the token very hard.
  • Don’t extract the algorithm from the header. Force the algorithm in the backend (HS256 or RS256).
  • Make token expiration (TTLRTTL) as short as possible.
  • Don’t store sensitive data in the JWT payload, it can be decoded easily.

OAuth

  • Use a random complicated key (JWT Secret) to make brute forcing the token very hard.
  • Don’t extract the algorithm from the header. Force the algorithm in the backend (HS256 or RS256).
  • Make token expiration (TTLRTTL) as short as possible.
  • Don’t store sensitive data in the JWT payload, it can be decoded easily.

Access

  • Limit requests (Throttling) to avoid DDoS / brute-force attacks.
  • Use HTTPS on server side to avoid MITM (Man in the Middle Attack).
  • Use HSTS header with SSL to avoid SSL Strip attack.

Input

  • Use the proper HTTP method according to the operation: GET (read)POST (create)PUT/PATCH (replace/update), and DELETE (to delete a record), and respond with 405 Method Not Allowed if the requested method isn’t appropriate for the requested resource.
  • Validate content-type on request Accept header (Content Negotiation) to allow only your supported format (e.g. application/xmlapplication/json, etc.) and respond with 406 Not Acceptable response if not matched.
  • Validate content-type of posted data as you accept (e.g. application/x-www-form-urlencodedmultipart/form-dataapplication/json, etc.).
  • Validate user input to avoid common vulnerabilities (e.g. XSSSQL-InjectionRemote Code Execution, etc.).
  • Don’t use any sensitive data (credentialsPasswordssecurity tokens, or API keys) in the URL, but use standard Authorization header.
  • Use an API Gateway service to enable caching, Rate Limit policies (e.g. QuotaSpike Arrest, or Concurrent Rate Limit) and deploy APIs resources dynamically.

Output

  • Send X-Content-Type-Options: nosniff header.
  • Send X-Frame-Options: deny header.
  • Send Content-Security-Policy: default-src 'none' header.
  • Remove fingerprinting headers – X-Powered-ByServerX-AspNet-Version, etc.
  • Force content-type for your response. If you return application/json, then your content-type response is application/json.
  • Don’t return sensitive data like credentialsPasswords, or security tokens.
  • Return the proper status code according to the operation completed. (e.g. 200 OK400 Bad Request401 Unauthorized405 Method Not Allowed, etc.).

Processing

  • Check if all the endpoints are protected behind authentication to avoid broken authentication process.
  • User own resource ID should be avoided. Use /me/orders instead of /user/654321/orders.
  • Don’t auto-increment IDs. Use UUID instead.
  • If you are parsing XML files, make sure entity parsing is not enabled to avoid XXE (XML external entity attack).
  • If you are parsing XML files, make sure entity expansion is not enabled to avoid Billion Laughs/XML bomb via exponential entity expansion attack.
  • Use a CDN for file uploads.
  •  f you are dealing with huge amount of data, use Workers and Queues to process as much as possible in background and return response fast to avoid HTTP Blocking.
  • Do not forget to turn the DEBUG mode OFF.

CICD Pipeline

  • Audit your design and implementation with unit/integration tests coverage.
  • Use a code review process and disregard self-approval.
  • Ensure that all components of your services are statically scanned by AV software before pushing to production, including vendor libraries and other dependencies.
  • Design a rollback solution for deployments.
  • Broken Object Level Authorization. APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.
  • Broken User Authentication. Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising system’s ability to identify the client/user, compromises API security overall.
  • Excessive Data Exposure. Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
  • Lack of Resources & Rate Limiting. Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.
  • Broken Function Level Authorization. Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.
  • Mass Assignment. Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.
  • Security Misconfiguration. Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.
  • Injection. Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
  • Improper Assets Management. APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.
  • Insufficient Logging & Monitoring. Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.