1 of 83

Crash Course into the�OWASP API Security Top 10

Alan Shen

Lead Security Software Engineer at Alteryx

2 of 83

whoami

Lead Security Software Engineer at Alteryx

  • Security critical coding projects
  • Threat Modeling / Vulnerability Remediation
  • Code/Design reviews�(SnowFROC 2023 Secure Code Warrior Tournament 1st Place)
  • Data analytics platform
  • Support 90+ data sources
  • Tools for creating custom API integrations
  • We connect to and maintain a lot of APIs

3 of 83

Agenda

  • Introducing APIs�
  • An overview tour of the 2023 Top 10 API vulnerabilities�
  • Newsworthy examples of the API vulnerabilities�
  • Analogies for non-technical stakeholders

�

4 of 83

Introducing APIs

5 of 83

Application Programming Interfaces �are contracts for communication between systems

For example:

  • REST
  • GraphQL
  • RPC

6 of 83

Vending Machine Analogy

7 of 83

Why focus on APIs

8 of 83

crAPI

​

  • Vulnerable API application sandbox
  • https://github.com/OWASP/crApi �
  • Publicly hosted: crapi.apisec.ai

9 of 83

What’s new in the OWASP�API Top 10

10 of 83

Open Worldwide Application Security Project

11 of 83

OWASP API Security Top 10�

​

(2023)

  1. Broken Object Level Authorization
  2. Broken Authentication
  3. Broken Object Property Level Authorization
  4. Unrestricted Resource Consumption
  5. Broken Function Level Authorization
  6. Unrestricted Access to Sensitive Business Flows
  7. Server Side Request Forgery
  8. Security Misconfiguration
  9. Improper Inventory Management
  10. Unsafe Consumption of APIs

(2019)

  • Broken Object Level Authorization
  • Broken User Authentication
  • Excessive Data Exposure
  • Lack of Resources and Rate Limiting
  • Broken Function Level Authorization
  • Mass Assignment
  • Security Misconfiguration
  • Injection
  • Improper Assets Management
  • Insufficient Logging and Monitoring

https://owasp.org/www-project-api-security/

12 of 83

OWASP API Security Top 10

​

What stayed the same:

​

(2023)

  • Broken Object Level Authorization
  • Broken Function Level Authorization
  • Broken Authentication
  • Security Misconfiguration
  • Improper Inventory Management

(2019)

  • Broken Object Level Authorization
  • Broken Function Level Authorization
  • Broken User Authentication
  • Security Misconfiguration
  • Improper Assets Management

Naming tweaks for [User] Authentication and Assets/Inventory Management�to make those categories more broadly applicable (but still essentially the same lessons)

https://owasp.org/www-project-api-security/

13 of 83

OWASP API Security Top 10

​

(2023)��

  • Broken Object Property Level Authorization

(2019)

  • Excessive Data Exposure��
  • Mass Assignment

​

Excessive Data Exposure and Mass Assignment were combined into their root cause: �Errors with validating Object Property Level Authorization

https://owasp.org/www-project-api-security/

14 of 83

OWASP API Security Top 10

​

(2023)

  • Unrestricted Resource Consumption

(2019)

  • Lack of Resources and Rate Limiting

More emphasis on resource consumption, and emphasizes less the “rate”

https://owasp.org/www-project-api-security/

15 of 83

OWASP API Security Top 10

​

​

(2023 - new)

  • Unrestricted Access to Sensitive Business Flows
  • Unsafe Consumption of APIs
  • Server Side Request Forgery

(2019 - removed)

  • Insufficient Logging and Monitoring
  • Injection

��� The two 2019 categories not specific to APIs

Anything in the general OWASP Top 10 is also potentially applicable!

​

https://owasp.org/www-project-api-security/

16 of 83

Common threads from the 2023 top 10

  • Allowing Unreasonable Client Access
    • Unrestricted Resource Consumption
    • Unrestricted Access to Sensitive Business Flows�
  • Forgetting to Validate Authorization
    • Broken Object Property Level Authorization
    • Broken Object Level Authorization
    • Broken Function Level Authorization�
  • Boundaries Being Bypassed
    • Broken Authentication
    • Server Side Request Forgery
    • Unsafe Consumption of APIs�
  • Lack of Visibility/Awareness
    • Improper Inventory Management
    • Security Misconfiguration
  • Broken Object Level Authorization
  • Broken Authentication
  • Broken Object Property Level Authorization
  • Unrestricted Resource Consumption
  • Broken Function Level Authorization
  • Unrestricted Access to Sensitive Business Flows
  • Server Side Request Forgery
  • Security Misconfiguration
  • Improper Inventory Management
  • Unsafe Consumption of APIs

17 of 83

“It’s obvious from recent news about mega breaches involving APIs, such as Optus and T-Mobile, that the API threat landscape is becoming more dangerous,” said Ivan Novikov, CEO of Wallarm�

  • “Briefly, we found that API threats tripled in 2022 with exploits available before we even know about the vulnerability,
  • the current OWASP API Security Top 10 list does not accurately reflect reality where �Injections are the primary attack vector,
  • and that open-source software, especially DevOps and cloud-native tools used to build new companies and technologies, is a growing target.”

​

https://www.helpnetsecurity.com/2023/03/08/api-threat-landscape/

18 of 83

Allowing Unreasonable

Client Access

  • Unrestricted Resource Consumption�
  • Unrestricted Access to �Sensitive Business Flows

​

​

19 of 83

Unrestricted Resource Consumption

20 of 83

Unrestricted Access to Sensitive Business Flows

21 of 83

Attacker approaches to bypass individual access limits

​

  • Tweaking request parameters�
  • Rotating user accounts�
  • Rotating IP Addresses�
  • Geolocation spoofing�
  • Scraping the user site instead of using the API

22 of 83

https://www.reuters.com/technology/musk-says-twitter-applies-temporary-limit-address-data-scraping-system-2023-07-01/

  • Outages in service for users�
  • Accusations of data scraping
    • e.g. LLM training�
  • Scraping attempts to bypass API limits

23 of 83

Controlling unreasonable client access

24 of 83

Forgetting to validate Authorization

  • Broken Object Property Level Authorization
  • Broken Object Level Authorization
  • Broken Function Level Authorization

25 of 83

Authentication vs. Authorization

  • Authentication:
    • Checking a user’s identity�
  • Authorization:
    • Checking that a user has enough �privileges to access a resource/action�
  • Authenticated roles still need to be checked for authorization

26 of 83

Object Oriented Abstraction Levels

  • Object Level
    • Resource associated with an ID
    • E.g. “Snowy” the dog�
    • Object Property Level
      • Property elements that describe the resource
      • E.g. Has_Fur, Has_Pilot_License�
  • Function Level
    • Actions in a system
    • May be associated with a object or not
    • E.g. Bark, Fly_Plane

27 of 83

Broken Object/Function-level Authorization

  • BOPLA: Access to Property in Object (e.g. isAdmin)
  • BOLA: Access to Objects (e.g. a specific user)
  • BFLA: Access to Functions (e.g. admin actions)

Table from https://university.apisec.ai/products/api-penetration-testing/ (Exploiting API Authorization)

28 of 83

Broken Object Property Level Authorization

When a user can read/write object properties that they should not have access to

​

  • Excessive data exposure �(broken authorization property on READ)
    • e.g. User Home Address�
  • Mass Assignment �(broken authorization property on WRITE)
    • e.g. Is Admin

29 of 83

Excessive Data Exposure

​

(API 2019)

Example anti-pattern:

  1. Client requests resource
  2. Server sends response
  3. Client gets resource
  4. Client filters resource
  5. Client displays filtered results�to user

​

30 of 83

https://nonamesecurity.com/blog/tomorrows-wordle-is-pwned/

31 of 83

Redactle solution exposure

https://redactle-unlimited.com/

32 of 83

33 of 83

Mass Assignment (API 2019)

34 of 83

35 of 83

Coinbase Unlimited Trading Exploit�(Feb 2022) Bounty: $250,000

https://twitter.com/Tree_of_Alpha/status/1495014907028422662

36 of 83

What pops out from this request?

37 of 83

>> changed to BTC-USD

38 of 83

>> changed to BTC-USD

changed to account with SHIB

39 of 83

https://blog.coinbase.com/retrospective-recent-coinbase-bug-bounty-award-9f127e04f060

  • Bounty: $250,000�
  • Allowed selling assets you didn’t own�
  • Underlying cause: missing logic validation check�
  • The validation service checked �whether the source account had a sufficient balance to complete the trade,�but not whether the source account matched the proposed asset to trade.

40 of 83

crAPI BOLA Example

GET /community/api/v2/community/posts/recent

(forum excessive disclosure)

41 of 83

Response

42 of 83

43 of 83

Authorization is hard

  • Enforcement is hard because it needs to happen in disparate locations in the architecture
    • How to enforce authorization is potentially not consistent across architecture
    • It’s hard for off-the-shelf authorization to work seamlessly with all possible components
    • Sometimes the usual frameworks don’t work if you implement custom logic�
  • Different architectures have tradeoffs
    • Monoliths can have fine-tuned control over authorization
      • But then your business and authorization logic is intertwined
    • Off-the-shelf solutions often attempt to separate authorization into an isolated service
      • But this adds complications to enforcing authorization
        • e.g. the overhead of calling from your business logic to an external �authorization service�
  • Modeling authorization can evolve into a mess
    • It’s difficult to anticipate how roles and permissions need to evolve for future needs.

Further reading: https://www.osohq.com/post/why-authorization-is-hard by Sam Scott

44 of 83

Boundaries being bypassed

  • Broken Authentication�
  • Server Side Request Forgery�
  • Unsafe Consumption of APIs�

​

​

​

45 of 83

Broken Authentication

46 of 83

Accepted JWTs only required a valid Email, no password/signature required �

​

https://eaton-works.com/2023/02/06/toyota-gspims-hack/

47 of 83

  • Corporate Toyota emails use a predictable format: �firstname.lastname@toyota.com
    • Lead generation sites like hunter.io can help figure this out�
  • Toyota employees, like most, post �their job details on business networking sites�
  • A Toyota employee was chosen by their likelihood of using GSPIMS

https://eaton-works.com/2023/02/06/toyota-gspims-hack/

48 of 83

  1. A Toyota employee was chosen by their �likelihood of using GSPIMS�
  2. Generated email address based on their name.�
  3. Input email guess into createJWT HTTP request, which returned a valid JWT�
  4. Confirmed a way to generate a valid JWT for any valid Email registered in GSPIMS

https://eaton-works.com/2023/02/06/toyota-gspims-hack/

49 of 83

Generating a JWT, and using gspimsAccessToken in a Cookie�completely bypassing the various corporate login flows (e.g. two-factor authentication)

https://eaton-works.com/2023/02/06/toyota-gspims-hack/

50 of 83

Impact: Internal API access allowed researching who had greater privileges�while JWT generation ability for any employees allowed increasing privilege escalation

https://eaton-works.com/2023/02/06/toyota-gspims-hack/

51 of 83

SSRF Preamble: What separates the “internal” side?

Potential barriers:

  • Firewalls
  • Load balancers
  • Proxies
  • Allowlist filtering

The

“DMZ”

GET /api/kitchen/make_sandwich {

"recipe_url": "https://sandwich.com/turkey"

}

52 of 83

Server Side Request Forgery

(1)

(2)

(3)

(4)

(Public)

(Internal)

GET /api/kitchen/make_sandwich {

"recipe_url": "file:///etc/passwd"

}

53 of 83

SSRF: Indicators of success

Two types of results:

  • In-Band: the outcome or resources requested are returned directly�e.g.
    • The resource requested
    • A response from the requested redirection
    • An error message�
  • Blind (Out-of-Band): No direct return, will need other hints of success/failure�e.g.
    • A URL redirect reaching an attacker controlled address
      • Burp Suite Collaborator
      • Request Bin
      • Webhook.site�
    • Noticeable differences in timing of the time it takes to return a response

GET /api/kitchen/make_sandwich {

"recipe_url": � "https://webhook.site/[generated_guid]"

}

54 of 83

Unsafe Consumption of APIs

55 of 83

Boundaries and Defense in Depth

(Kidwelly Castle)

~1275 AD

​

​

​

​

​

​

​

~1500 AD

56 of 83

Lack of Visibility/Awareness

Improper Inventory Management

Security Misconfiguration

​

​

57 of 83

Improper Inventory Management

58 of 83

Improper Inventory Management

59 of 83

Improper Inventory Management

60 of 83

Indicators of APIs/docs

  • Naming Schemes
    • https://target-name.com/api/v1
    • https://target-name.com/docs
    • https://dev.target-name.com/rest
    • /api, /api/v1, /v2, /rest, /swagger, /swagger.json, /doc, /playground�
  • HTTP Headers
    • "Content-Type: application/xml"
    • "Content-Type: application/json"�
  • Responses
    • {"message": "Missing Authorization token"}
    • {"error": {"code": "VALIDATION_ERROR",� "description": "Authorization is a required parameter.", � "field": "Authorization", � "instance": null}}

61 of 83

Improper Inventory Management

  • Outdated documentation
    • May leak details of deprecated APIs
    • Old documentation may be archived
      • e.g. Internet Archive’s Wayback Machine�
  • Deprecated/Abandoned APIs
    • May be outdated/vulnerable
    • Dev/Test/Sandbox APIs may be public by accident
    • Vulnerabilities may still be visible in source control history (e.g. “bug fix”)�
  • Anything else considered “inventory”
    • Tokens/keys, source code, addresses, etc.�
  • Dependencies are part of risk inventory
    • The technologies that APIs are implemented with share their vulnerabilities to the APIs
    • e.g. Log4J remote code execution vulnerability
      • Discovery led to widespread scrambling to figure out where Log4J was being used.

62 of 83

"Don't put credentials in your source code," says Chris Anley, chief scientist at NCC Group. "And certainly don't then publish that source code."

(According to GitGuardian)

63 of 83

crapi: Improper Inventory Management (forced browsing)

64 of 83

Security Misconfiguration

65 of 83

“The OAuth misconfigurations could have allowed for both large-scale account takeover (ATO) on customers’ accounts and server compromise”

https://www.itsecurityguru.org/2023/03/02/serious-api-security-flaws-now-fixed-in-booking-com-could-affect-many-more-websites/

66 of 83

Falling into the Pit of Despair

67 of 83

Falling into the Pit of Success

68 of 83

Takeaways

  1. Allowing unreasonable client access
    1. Unrestricted Resource Consumption
    2. Unrestricted Access to Sensitive Business Flows�
  2. Forgetting to Validate Authorization
    • Broken Object Property Level Authorization
    • Broken Object Level Authorization
    • Broken Function Level Authorization�
  3. Boundaries being bypassed
    • Broken Authentication
    • Server Side Request Forgery
    • Unsafe Consumption of APIs�
  4. Lack of Visibility/Awareness
    • Improper Inventory Management
    • Security Misconfiguration

Monitor for and limit suspicious access patterns

​

Enforce authorization consistently across the �system architecture

​

Build defense in depth to cover leakages in architectural/security boundaries

​

Automate inventory management, make secure by default, or at last resort have well-defined processes and checklists to minimize human error.

69 of 83

Where to learn more

  • OWASP.org/www-project-api-security/�
  • Books
    • Hacking APIs by Corey Ball
    • Black Hat GraphQL by Dolev Farhi, Nick Aleks�
  • ApiSecUniversity.com
    • Corey Ball is also an instructor�
  • APIsecurity.io newsletter�
  • github.com/arainho/awesome-api-security

70 of 83

Questions?

​

sunzenshen.github.io

71 of 83

72 of 83

73 of 83

Overflow

74 of 83

Example alternative API style: GraphQL

APIs do not necessarily follow the server/client model of architectures like REST

GraphQL instead follows a query-centric model

  • All requests are POST with a query formatted in JSON:

​

75 of 83

crapi: Comparing OTP API versions

(Improper Inventory Management)

76 of 83

API Security Trends

77 of 83

  • “Enterprises are producing a massive number of APIs at a rate that far outpaces the maturity of network and application security practices... ungoverned API usage is on the rise.”
  • “Gartner predicts that by 2022, application programming interface (API) attacks will become the most-frequent attack vector”

78 of 83

https://www.imperva.com/resources/reports/Imperva-Marsh-McLennan-Report-2022.pdf

In order to quantify the cost of API insecurity, Imperva partnered with the Marsh McLennan Global Cyber Risk Analytics Center to analyze API-related incident data. Their research suggests that the lack of secure APIs could have the following impact:

In order to develop the estimated amount of loss attributed to API-related events, researchers combined the Marsh McLennan incident data, the raw API-related incident proportion, and the underreporting factor to develop an estimated API-related frequency range of 4.1-7.5%. Researchers then applied the percentage range of events from API issues to develop the following annual API-related loss estimates:

79 of 83

Example Newsworthy�API Vulnerabilities

80 of 83

Experian Partner API (April 2021)

  • Impact:
    • Allowed looking up credit score and top 4 risk factors
  • No authentication requested
    • API asked for Name, Address, and Date of Birth
    • Date of Birth check allowed filling in all zeros

​

https://krebsonsecurity.com/2021/04/experian-api-exposed-credit-scores-of-most-americans/

81 of 83

Peloton (May 2021)

​

  • Impact:
    • Exposed user IDs, locations, personal info, session data for more than 3 million users
    • Users included the current United States president
  • Vulnerability:
    • User profile privacy configuration option did not work when enabled
    • User IDs were predictable and guessable
    • APIs allowed unauthenticated requests that included a valid User ID (without checking requesting user)

​

82 of 83

USPS Informed Visibility API �(November 2018)

​

  • Impact:�Exposed addresses (home and email), usernames, real time package updates, phone numbers of ~60 million USPS users
  • BOLA:�Any authenticated user could query other user data
    • Lack of access control on origin of query
    • Queries also allowed wildcards like ?email=*@gmail.com
    • A physical address query returned all associated records
  • BFLA:�“the API allowed any user to convert regular usps.com accounts to Informed Visibility business accounts, and vice versa.”

83 of 83

�https://twitter.com/TipsyBacchus/status/1560037721514672129