Intro to the OWASP

API Security Top 10 (2023)

Alan Shen

Senior Security Software Engineer at Alteryx

whoami

Senior Security Software Engineer at Alteryx

• Security critical coding projects
• Code/design reviews
• Threat modeling / vulnerability remediation

Amateur speaker at Denhac/DC303����

�

dc303.org

meetup.com/denhac-hackerspace/ meetup.com/dc303denver/

Agenda

Target audience: �You want to learn more about what’s new in the 2023 update of the OWASP API Top 10

• Introducing APIs
• Differences between 2019 and 2023 Top 10 lists
• An overview tour of the 2023 Top 10 API vulnerabilities
• Newsworthy examples of the API vulnerabilities

�By the end of this talk, the audience should be able to recognize categories �of the OWASP API Top 10. �They will also be aware of where to find additional learning resources �for specific implementation needs.

Introducing APIs

Remember this from Def Con 30?

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

APIs are contracts for communication between systems

• Concepts like REST, SOAP, GraphQL, RPC �define the contract for how to communicate with an encapsulated system.
• REST as a server/client communication
• GraphQL as a relational-query model
• RPC as the execution of commands on a remote resource�
• APIs allow independently evolving systems to collaborate
• API clients do not need to care about the implementation details �beyond the API interface.
• This separation of responsibilities is critical in architectures like “microservices” and “Service Oriented Architecture” (SOA)

​

Why look at APIs

• API development effort is not commonly shared
• Unlike open-source frameworks/libraries�
• APIs are often the most custom-made of developed code
• API vulnerabilities are usually unique to an application�
• APIs have privileged access to �internal/sensitive resources
• Many internal APIs even assume they are safely isolated from the public�
• Security tools historically not focused on API testing
• e.g. Vulnerability scanners less API aware

crAPI

​

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

What’s new in the OWASP�API Top 10

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/

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/

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/

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/

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/

Common threads from the 2023 top 10

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 User Authentication
• Server Side Request Forgery
• Unsafe Consumption of APIs�
4. Lack of Visibility/Awareness
• Improper Inventory Management
• Security Misconfiguration

Allowing Unreasonable

Client Access

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

​

​

Unrestricted Resource Consumption

• APIs cost money to maintain and serve
• Bandwidth, hardware, electricity…
• External services paid per request�
• Consequences:
• Denial Of Service or service degradation
• Increased costs
• Monetization opportunity losses�
• Example Mitigations:
• Rate-limiting
• Timeout/expire requests that take too long
• Spending limits for 3rd party services
• Limit the allocated resources available
• e.g. file handles, bandwidth, processors

Unrestricted Access to Sensitive Business Flows

• Legitimate business flows may be negatively impacted by automation and increased scale�
• Does not need any traditional security vulnerability
• Individual requests are legitimate
• Superhuman usage patterns�
• Example malicious business flows:
• Identity/IP/Geolocation spoofing to bypass �individual consumer access/purchase limits
• Automating new user registration to exploit �referral programs
• Advertisement views fraud

​

Attacker approaches to bypass individual access limits

​

• Tweaking request parameters
• e.g. URL Paths, Query Strings, Origin Headers�
• Rotating user accounts
• Test single payload while iterating through users �(e.g. password spraying)�
• Rotating IP Addresses
• e.g. Using residential VPNs, �to spoof unique customer identities�
• Scraping the user site instead of using the API

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

Controlling unreasonable client access

• Logging and monitoring to detect suspicious access patterns�
• Discourage automated guessing with high entropy generation sources for IDs/GUIDs/OTPs �
• Consider blocking known proxies and anonymization services (e.g. Tor exit nodes)�
• Device fingerprinting
• Also consider blocking suspicious device types, �like headless browsers�
• Human access detection
• CAPTCHA human verification
• Behavioral analysis (e.g. typing and user input patterns)

Forgetting to validate Authorization

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

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

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

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

​

• Daily answer visible in Chrome Dev Tools (Excessive Exposure)
• Note: Thomason did not actually test the POST request (BFLA or Mass Assignment)
• Potential risk of changing future answers (risk of defacement with explicit language)
• But also potential legal risk of submitting a successful change

​

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

Redactle solution exposure

https://redactle-unlimited.com/

Mass Assignment (API 2019)

• When indiscriminate parameter binding overrides unauthorized object properties
• e.g. Forcibly setting isAdmin=true on new user signup�
• Common culprit: �Development patterns that simplify object-level assignment
• e.g. Object Relational Mappers, Autobinding, etc.�
• Shortchange analogy
• Failure to validate an unexpected variable added to a transaction, which gets accepted into the registry.
• e.g. Workshop vs. General Admission level conference passes�
• To discover parameter candidates
• Read documentation
• Observe exposed parameters
• Forcibly guess patterns of potential parameter names

Broken Object/Function-level Authorization

• BOPLA: Access to Property in Object (e.g. isAdmin)
• BOLA: Access to Objects (e.g. other user data)
• BFLA: Access to Functions (e.g. admin actions)�
• The test: Create multiple roles/accounts with different privilege levels and try to access others’ resources/actions.
• If User A uses their own authorization token, �can they access sensitive resources from User B?
• If an admin-level function is hidden from a user, can a user still use that function?�
• Problem can be exacerbated by �easily guessable resource IDs or function names

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

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

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

What pops out from this request?

>> changed to BTC

>> changed to BTC

changed to account with SHIB

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

• 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.

​

• Mitigating factors had the flaw been exploited at scale:
• Coinbase Exchange has automatic price protection circuit breakers
• A trade surveillance team continuously monitors the markets�for health and anomalous trading activity

crAPI BOLA Example

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

(forum excessive disclosure)

Response

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�
• 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

Boundaries being bypassed

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

​

​

​

Broken User Authentication

• Usually API authentication is either reasonably secure, �or extremely broken�
• Many APIs start development with no authentication, �which may never get implemented�
• Some API architectures assume no authentication is needed past a boundary/DMZ�
• Weak password policies or token generation�
• Misconfiguration of authentication
• OAuth - e.g. allowed redirect URLs
• JWTs - e.g. algorithms/signing/expiration

1. Accepted JWTs just required a valid Email, �no password required �
2. Corporate Toyota emails use a predictable format: �firstname.lastname@toyota.com�
3. Toyota employees, like most, post �their job details on business networking sites�
4. A Toyota employee was chosen by their �likelihood of using GSPIMS�
5. Generated email address based on their name.�
6. Input email guess into createJWT HTTP request, which returned a valid JWT�
7. 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/

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/

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/

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"

}

Server Side Request Forgery

(1)

(2)

(3)

(4)

(Public)

(Internal)

Potential requests to forge:

• URLs/IP-addresses
• Fixed management console addresses
• file:// URIs
• localhost
• Analytic referrer sources

GET /api/kitchen/make_sandwich {

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

}

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]"

}

Unsafe Consumption �of APIs

• Developers may trust 3rd party APIs more than user input
• Potential supply chain risk when 3rd party APIs vulnerable to attackers

​

With “trusted” APIs, relaxed security could allow:

• Injection
• Unfiltered reprinting of Large Language Model results to end users
• Blind following of redirection URLs
• e.g. SSRF
• Lack of resource consumption controls
• e.g. logging, monitoring, timeouts etc

Boundaries and Defense in Depth

(Kidwelly Castle)

~1275 AD

​

​

​

​

​

​

​

~1500 AD

Lack of Visibility/Awareness

Improper Inventory Management

Security Misconfiguration

​

​

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.

"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)

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

crapi: Improper Inventory Management (forced browsing)

Security Misconfiguration

Lack of security hardening can involve:

• Security-adverse configurations
• e.g. TLS disabled, CORS too permissive
• Excessive verbosity
• e.g. error response, X-Powered-By version
• Inappropriate application/role permissions
• e.g. receptionist account with PowerShell access
• Out of date security patching

​

Vulnerability scanners can help flag �insecure configurations for review

“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/

Falling into the Pit of Despair / Pit of Success

• Falling into the Pit of Despair
• Security misconfigurations often happen because default settings are insecure
• Inventory management that is a manual process risks neglect�
• Falling into the Pit of Success
• Secure as the default
• Or at least having a user explicitly override for insecure settings �(acknowledgement)
• Automating provisioning and tracking of inventory as much as possible
• e.g. Software Composition Analysis, resource provisioning timeouts
• Follow checklists and defined procedures for anything else you can’t automate
• Depends on the standard of discipline of your organization.

Takeaways

• 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 User Authentication
• Server Side Request Forgery
• Unsafe Consumption of APIs�
• 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.

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

Questions?

​

sunzenshen.github.io

Overflow

Welcome to OWASP

The Open Worldwide Application Security Project (OWASP) �is a nonprofit foundation that works to improve the security of software.

• Community-led open source software projects
• training materials, open source tools
• OWASP API Security Project and the API Security Top 10
• Completely Ridiculous API Project (crAPI)
• Over 250+ local chapters worldwide
• e.g. this Denver/Boulder chapter
• Industry-leading educational and training conferences
• e.g. SnowFROC earlier this year

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:

​

crapi: Comparing OTP API versions

(Improper Inventory Management)

API Security Trends

• “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”

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:

“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/

Example Newsworthy�API Vulnerabilities

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/

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)

​

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.”