API Security Fundamentals

Introduction to API Security

Why API Security?

  • API (Application Programming Interface) - website communicating to API to make and fetch information through a request.

Big deal with API Security

  • APIs:

    • Direct access to sensitive data

    • Ofter "over-permissioned"

    • Vulnerable to logic flaws

Central chokepoint
Process of an attack

  • Regulatory Compliance

    • Banking - FFIEC, OCC, Open Banking, FDX

    • Paymend Card Industry - PCI

    • Healthcare - HIPAA/HITRUST/Interopability

    • Privacy - GDPR, CCPA, PIPEDA

    • Federal - FedRAMP

    • Standard Frameworks - NIST 800-53, ISO 27001, SOC 2

  • Competing Challenges

    • Security

      • Secure operation of web interfeaces

      • Regular vulnerability testing

      • Rapid review and remediation of findings

    • Privacy

      • Protection of PII, user data

      • Breach notification requirements

      • Massive penalties for violations

    • Accessibility

      • Global push to make data accessible

      • Interopability, OpenBanking

      • "Information Blocking" penalties

Anatomy of Real-World API Breaches

Real-World Breach: Coinbase

  • User scraped API calls from web UI

  • Identified 4 key parameters for any coinbase transaction

  • Manipulated the parameters via API calls

  • Sold crypto they did not own

OWASP API #1: Broken Object Level Authorization

Coinbase request payload

  • Root Cause - missing logic validation check in retail brokerage endpoint, which allowed users to trade an order using mismatched source account

Real-World Breach: US Postal Service

  • USPS relied in traditional code and web scanners

  • Found missing API authentication

  • USPS added authentication

  • Left out authorization

  • User A able to access User B details (any of 60M accounts)

OWASP API #1: Broken Object Level Authorization

Real-World Breach: Peloton

  • Open API allowed request for user details with no authentication

  • 4M user account details exposed (including Joe Biden)

  • Including accounts marked private

  • Researcher reported to Peloton

  • No response after 90 days

  • "Fixed" vulnerability by adding authentication

  • But hackers could still access all records, just need to authenticate

OWASP API #1: Broken Object Level Authorization

OWASP API #2: Broken Authentication

Real-World Breach: Venmo

  • Venmo homepage presented live feed of transactions

  • Hacker sniffed traffic and identified API calls

  • Wrote 20-line script, using 2 IPs

  • Pulled 115k transactions/day - even with rate limiting

  • API returned all transaction details

  • 270M transactions harvested

OWASP API #2: Broken Authentication

OWASP API #3: Broken Object Property Level Authorization

OWASP API #4: Unrestricted Resource Consumption

Real-World Breach: Instagram

  • Account reset required 6-digit code

  • Researcher found API to submit reset code guesses

  • Guesses limited to 200 per IP

  • Researcher demonstrated could rotate through 5,000 IPs in seconds

  • Enables takeover of any accounts

OWASP API #1: Broken Object Level Authorization

OWASP API #2: Broken Authentication

Real-World Breach: Bumble

  • API permitted access to 95M user account details w/o authentication

  • Incremental IDs allowed easy scraping of entire database

  • Enabled calculation of users' exact location via triangulation

  • API allowed paid features to be enabled without proper privileges

OWASP API #1: Broken Object Level Authorization

OWASP API #2: Broken Authentication

OWASP API #5: Broken Function Level Authorization

Real-World Breach: T-Mobile

  • Hackes obtained data from this API approximately 37M current postpaid and prepaid customer accounts without authorization

Real-World Breach: Optus

  • API endpoint required authentication to access

  • Attacker harvested 9.8M user details and threatened $1M ransom

  • Data included driver's license, Medicare IDs, name, phone and email

OWASP API #1: Broken Object Level Authorization

OWASP API #3: Broken Object Property Level Authorization

OWASP API #4: Unrestricted Resource Consumption

Real-World Breach: Experian

  • Experian partner site offered loan eligibility feature

  • Feature used Experian API for lenders to automate credit score lookup

  • Attacker sniffed API calls

  • API accessible with no authentication

  • Results delivered with name, address and *any* value for date of birth

OWASP API #1: Broken Object Level Authorization

OWASP API #3: Broken Object Property Level Authorization

OWASP API #9: Improper Inventory Management

OWASP API Security Top 10

OWASP Top 10 Background

  • OWASP (Open Web Application Security Project) - all about aplication security threats, known for OWASP 10 that focuses in web and mobile application threats.

2023 OWASP API Security Top 10

API1:2023 Broken Object Level Authorization (BOLA)

  • Description

    • Most common and damaging API vulnerability

    • Manipulation of APIs to access data/objects belonging to other users

  • Risk Exposure

    • Can lead to data loss, disclosure and data manipulation

  • Examples

    • Attacker authenticates as User A and the retrieves data on User B

  • Prevention

    • Define data access policies and implement associated controls

    • Enforce data access controls at application logic layer

    • Implement automated testing to find BOLA flaws

API2:2023 Broken Authentication

  • Description

    • Weak or poor authentication creates vulnerability:

      • Missing security controls

      • Poorly implemented controls

  • Risk Exposure

    • Account takeover

    • Data theft, unauthorized transactions

  • Examples

    • Weak password

    • Credential stuffing: brute force ID/PW

    • No captcha/rate limiting/lockout

    • Auth info in URLs (tokens, passwords)

    • Non validation of token expiration

    • Insecure password storage

  • Prevention

    • Define authentication policies and standards; follow best practices

    • Implement continuous testing

API3:2023 Broken Object Property Level Authorization

  • Description

    • Exploit endpoints by reading and/or modifying values of objects

    • Ability to update object elements ("mass assignments")

    • Revealing unnecessary sensitive data ("excessive data exposure")

  • Risk Exposure

    • Revealing protected user data

  • Examples

    • User is able to set "account-type=premium"

    • User search endpoint returns excessive, uneccessary details (name, email, address, ID, ...)

  • Prevention

    • Ensure user can only access legitimate, permitted fields

    • Return only minimum amount of data required for the use case

API4:2023 Unrestricted Resource Consumption

  • Description

    • Abuse APIs due to high volumes of API calls, large requests, etc.

    • Formerly "Lack of Resources and Rate Limiting"

  • Risk Exposure

    • DOS

    • Performance impact

    • Mass data harvesting

  • Examples

    • Missing/inadequate rate controls

    • Execution timeouts

    • Max allocable memory

    • Max number of files, upload size

    • Excessive operations in single request

    • Excessive records returned in single request

  • Prevention

    • Implement traffic controls

    • Test effectiveness of controls

API5:2023 Broken Function Level Authorization

  • Description

    • Abuse of API functionality to improperly modify objects (create, update, delete)

    • Often involves replacing passive methods (GET) with active (PUT, DELETE)

  • Risk Exposure

    • May be used to escalate privilege

    • Can be exploited to modify account details

  • Examples

    • Modify parameters - "role = admin"

    • Delete an invoice

    • Set account balance = $0

  • Prevention

    • Identify functions that expose high sensitivity capability and develop controls to limit access

    • Implement continuous release testing to ensure proper behaviour

API6:2023 Unrestricted Access to Sensitive Business Flows

  • Description

    • Abuse of legitimate business workflow through excessive, automated use

    • Rate limiting, captchas not always effective against fraudulent traffic

    • Rapid IP rotation makes detection difficult

    • Typically a result of application logic flaw

  • Risk Exposure

    • Loss of critical business activity

  • Examples

    • Mass, automated ticket purchasing

    • High volume referral bonuses

  • Prevention

    • Identify critical business workflows

    • Implement fraudulent traffic detection and control

    • Setup and automate testing of control mechanisms

API7:2023 Server Side Request Forgery

  • Description

    • Exploiting URL inputs to make a request to a malicious, 3rd party server

  • Risk Exposure

    • SSRF creates a channel for malicious requests, data access or other fraudulent activity

    • Potential for data leaks

  • Examples

    • Local File Injection (LFI)

    • User submits: http://localhost/api/user-data

    • Malware downloaded from malicious

  • Prevention

    • Validate sanitize ALL user-supplied information, including URL parameters

    • Ensure communication only permitted with trusted resources

    • Test URL validation effectiveness

API8:2023 Security Misconfiguration

  • Description

    • Broad category encompasses lack of hardening to unnecessary services

    • Use of bots to scan, detect and exploit misconfigurations

  • Risk Exposure

    • Misconfigurations can expose sensitive user data

    • Potential for full server compromise

  • Examples

    • Lack of security hardening

    • Improperly configured permissions

    • Missing security patches

    • Unnecessary features enabled

    • Missing TLS

    • CORS policy missing/improperly set

  • Prevention

    • Implement hardening procedures

    • Routinely review configurations

    • Implement automated, continuous security testing

API9:2023 Improper Inventory Management

  • Description

    • Unauthorized API access via old, unused API versions, or through trusted 3rd parties

  • Risk Exposure

    • Data/account theft via unretired APIs

    • Exposure of sensitive data via improperly secured 3rd party APIs

  • Examples

    • Old versions of APIs

    • Unpatched endpoints

    • Endpoints with weaker security

    • Outdated documentation

    • Unnecessarily exposed endpoints

    • API access via 3rd party

  • Prevention

    • Deploy/manage all APIs in gateway

    • Define rules for versioning and retirement

    • Periodically audit 3rd party access

API10:2023 Unsafe Consumption of APIs

  • Description

    • Exposures can occur via use of 3rd party APIs, which are generally trusted. However, 3rd parties can be exploited, which can be used to attack APIs that rely on them

  • Risk Exposure

    • Data theft, breach, account takeover

  • Examples

    • Attacker inserts malicious address data to validation site used by client. Client fails to validate data and gets exploited

    • Attacker compromises 3rd party API causing it to respond with redirect to malicious site. Client blindly follows redirects without validation

  • Prevention

    • Validate data returned by 3rd party APIs

    • Evaluate security controls of 3rd party API

    • Encrypt all API communication

    • Maintain approved list of known locations integrated APIs may be redirected

The 3 Pillars of API Security

The 3 Pillars

  • Governance - about defining and enforcing thre processes of developing and testing of APIs to production

  • Testing - ensuring that APIs perform as expected and free from flaws

  • Monitoring - runtime monitoring of APIs to make sure that they are behaving as expected

The 3 Pillars of API Security

Governance

  • Benefits

    • Consistency

      • Setting expectations

    • Establishing standard processes

    • Enforcing security

Know your APIs

  • Get full inventory APIs

    • Purpose, owner documentation

  • Standardize and enforce API deployment process

    • Existence of "shadow/rogue" APIs sign of weak governance

    • APIs only deployed in approved ways, with proper validation

    • Enforce governance at gateway, Marketplace

  • Mandate API documentation

    • Make sure APIs are consistent and reusable

    • Define documentation requirements

  • Create API Development standards

    • Style guides, authentication requirements, versioning, PII tracking

Know your Risks - Threat Modelling

  • Identify - APIs, business flows, data and access paths

  • Assess - vulnerabilities, logic flaws, access controls, 3rd party risk

  • Probability - examine the likelihood of an attack

  • Impact - understand the damage, loss, consequence of an attack

  • Mitigation - develop a plan to address the risk

Documentation

Design Guides: Promote Governance, Consistency

  • Authentication - type (basic, token, certificate), how to implement

  • Authorization - who has access to what, where enforced

  • Naming Conventions - URIs as nouns, Methods as verbs, pluralization, hierarchy, case, language, no jargon/abbreviations

  • Error codes - status codes, reference ID, human readable messages

  • Versioning - when to increment, when not, types of versions

  • Units, Formats, Standards - date/time formats, timezones

Testing

  • Where do you want to find API vulnerabilities?

    • Pre-production

    • Production

  • Standard "playbook" test categories offer limited value

    • XSS, injection, buffer overflow

    • Important to run these tests to avoid bot-based attacks

    • API breaches rarely exploit these

    • Major breaches typically business logic flaws

API-First Testing
Testing Categories

Monitoring

  • Runtime Protection

    • Policy enforcement

    • Authentication

    • Traffic filtering

  • Threat Detection

    • Fraudulent traffic

    • Distributed attacks

    • Incident response

  • Control Validation

    • Verify API controls

    • Uncover anomalies

  • Monitoring Approaches

    • Proactive: Blocking

      • API Gateway

      • Web App Firewall

    • Reactive: Alerting

      • Logging, SIEM

      • Runtime API Threat Management

API Discovery

  • Monitoring can aid API inventory efforts

    • Identify API endpoints use

    • Discover undocumented/unknown APIs

  • Comprehensive discovery requires more sources

    • API Gateway, Web Application Firewall

    • Code repository

    • Application testing, crawling

  • Reliance on traffic based-discovery misses:

    • Internal API traffic not seen by traffic analysis tool

    • Pre-production APIs

    • Unexercised endpoints

Limitations of Monitoring

  • Difficult to get full visibility

    • Requires sensor on every network segment

  • High false positives on threat detection

    • Live traffic contains limited context

    • Difficult to identify data access violations in real-time

    • API monitoring tools typically used in alert only

  • SaaS-based monitoring requires sharing traffic with 3rd parties

    • Privacy concerns

    • Bandwidth requirements

  • Traffic blocking solutions can add latency

API Security Technology Landscape

Cybersecurity Landscape

  • Application

    • SAST, DAST

    • SCA, Container Security

    • WAF

    • API Security

Workflow

Conclusion and Best Practices

Conclusion and Best Practices

  • Enforce API governance and establish API control

    • Gateway, marketplace platform

    • No API goes live without passing gates (docs, testing, security)

  • Create comprehensive testing program

    • Test every endpoint all OWASP attacks and more

    • Evaluate every data object, user type and function for logic flaws

    • Leverage automation for comprehensive test coverage

  • Implement automated, continuous testing

    • Although APIs rarely change, code and infrastructure does

    • Every release needs functional and security testing

    • Integrate testing into CI/CD pipeline

  • Develop API security metrics and assess progress

    • Total APIs managed - new, existing, retired

    • Vulnerabilities identified, outstanding, fixed

Do's and Dont's
PreviousIntroduction to NetworkingNextOWASP API Security Top 10 and Beyond!

Last updated