QA Fest 2019. Катерина Овеченко. Тестирование безопасности API

Тема доклада
KYIV 2019
Kateryna Ovechenko
API SECURITY
QA CONFERENCE #1 IN UKRAINE

WITH PASSION TO QUALITY QA CONFERENCE #1 IN UKRAINE KYIV 2019
Head of QA Department at
Co-founder of professional IT conferences
9+ years in testing Focus on test management of large programs and teams and security testing.
4+ years in security testing: from building competence in the company to coordinating projects
for external Customers
Speaker at local and international conferences (QA Fest, SQA Days, Simplicity Day, Czech Test
and several in Norway), lecturer at National Aviation University
ABOUT ME

REAL EXAMPLES

NISSAN
Full article: https://www.computerworld.com/article/3036964/hackers-can-access-the-nissan-leaf-
via-insecure-apis.html
Remote control over API on other user’s
car:
• Climate control
• Battery charge management
• Car driving range
• Historic driving data (when, how far,
how efficiently)

SAMSUNG
Full article: https://www.consumerreports.org/tvs/samsung-fixes-smart-tv-security-issue/
Unsecured API allowed access to:
• change TV channels
• turn up the volume
• play unwanted YouTube videos
• kick the TV off a WiFi connection
It will NOT allow:
• spying on a TV viewer
• stealing private information
• monitoring what was being watched

CANDY CRUSH
Full article: https://www.stavros.io/posts/winning-candy-crush/
By modifying legitimate APIs from
the game, the hacker was able to:
• Play without lives limitation
• Ease the levels of the game by
changing number of colors for
each level
• Finish each level automatically
with random score by calling
proper method in the API

APIS IN OUR LIFE
Average number of APIs the
company runs is 420
83% of traffic in content-
delivery network belongs to APIs
Full report: https://www.akamai.com/us/en/multimedia/documents/state-of-the-internet/state-of-the-internet-security-
retail-attacks-and-api-traffic-report-2019.pdf

OWASP API SECURITY
Top 10 API Security Risks current draft:
6. Mass Assignment
7. Security Misconfiguration
8. Injection
9. Improper Assets Management
10.Insufficient Logging & Monitoring
1. Broken Object Level Access Control
2. Broken Authentication
3. Improper Data Filtering
4. Lack of Resources & Rate Limiting
5. Missing Function/Resource Level
Access Control
API Security Cheat Sheet from OWASP
https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html

A1: BROKEN OBJECT LEVEL ACCESS CONTROL
POST api/v1/documents/download_document
{
document_id: 102
}
102
101
103
104
ok
fail
fail
fail

Violation of horizontal access control
Query parameters
URL parameters
Body parameters
/api/users/717
/download_file?id=111
user-id:717

Traffic analyzers
API testing tool

A2: BROKEN AUTHENTICATION
● Weak authentication (passwords management, brute force attacks, etc.)
Ø Can be tested both manual and with automatic scanners
● Checking sessions for APIs
GET /api/1.0/Channels/1270 HTTP/1.1
Host: test-site.azurewebsites.net
Accept: application/json
Accept-Encoding: gzip, deflate
Cookie: auth=60f5f03b-57b8-40b4-aa79-a73e8b6f0814;
ARRAffinity=667b68ef9998ba2095eb4fef50e58d958908a44894f5425ed9
2f2db982a28474
Connection: keep-alive

● API to API communication with master token or service account
Ø Cannot be found automatically, only during architecture and code
reviews
● Basic authentication vs claim-based authentication
and Single Sign On (SSO)

CLAIM-BASED AUTHENTICATION

Automatic scanners
API testing tool

A3: IMPROPER DATA FILTERING
● Client-side data filtering
APIs tend to return more data than
required. This data is usually not shown to
the user, but can be easily found in API
response
● Filters manipulation
The front-end usually maintains the user’s
state. The client sends more filters to the
back-end in order to reflect the user’s state
Name: Kate
Role: superuser
Hobby:
travelling, sports
200 OK
{
“users”: [{
picture: ”profile_kate.jpg”,
userid: 220,
name: “Kate”,
last_name: “Ovechenko”,
role: “superuser”,
hobbies: {”travelling”, ”sports”}
address: “Kyiv, Test str., 35”
}
}

A3: IMPROPER DATA FILTERING
Traffic analyzers
API testing tool

Full article: https://devclass.com/2018/10/02/gitlab-api-flaw-security-updates/

A4: LACK OF RESOURCES & RATE LIMITING
Scenario 1
Too many requests are being to or from certain API at the same time
● Status code: 429 Too Many Requests
● Proprietary headers: X-RateLimit-*
Scenario 2
Too heavy requests are being made to an API
● /dashboard/users?page=1&size=100 à size=200000

Scenario 3
What data can be used for fuzzing:
● Wrong data format
● Long arrays of data
● Special characters
● Other methods or protocols than
those expected by server
● Special Functions

BURP SUITE: HTTP METHOD FUZZING

Traffic analyzers
Fuzzing tool
JBROFUZZFuzzapi

A5: MISSING FUNCTION LEVEL ACCESS CONTROL
Violation of vertical access control:
● Understand the relations between resources
● Complex user policies and roles
● Easier to predict the entry points
(GET → DELETE)(/api/v1/users → api/v1/admins)
● 20x OK vs 401/403 Unauthorized/Forbidden

A5: MISSING FUNCTION LEVEL ACCESS CONTROL
AUTHENTICATED USER
MANAGER
MANAGER
MANAGER
REGULAR USER
MANAGER
MANAGER
ADMIN
REGULAR USER
ADMIN
ADMIN

Full article: https://www.zdnet.com/article/steam-bug-could-have-given-you-access-to-all-the-cd-keys-of-any-game/

A6: MASS ASSIGNMENT
● Modern frameworks encourage developers to use mass assignment techniques
(use data-transfer object with all properties)
● Easier to exploit in APIs
○ We can usually can find a GET request that returns all the properties of an
object
def signup @user = User.create(params[:user])
# => User<email: "john@doe.com", password: "qwerty", is_administrator: false>
end

A6: MASS ASSIGNMENT

<input type="hidden" name="is_administrator" value="true">
def signup @user = User.create(params[:user])
# => User<email: "john@doe.com", password: "qwerty", is_administrator:
true>
end
def signup # Explicit assignment:
@user = User.create( email: params[:user][:email], password:
params[:user][:password] )
# or whitelisting:
@user = User.create( params.require(:user).permit(:email, :password) ) end

A7: SECURITY MISCONFIGURATION
• Unnecessary HTTP methods
• Improper Cross-Origin Resource Sharing
○ Access-Control-Allow-Origin
○ Access-Control-Allow-Credentials
○ Using XSS to make requests to cross origin sites
• Detailed Errors
○ Respond with generic error messages - avoid revealing details of the failure unnecessarily.
○ Do not pass technical details (e.g. call stacks or other internal hints) to the client
• Access to internal files/pages
• Security Headers
○ Content-Security-Policy
○ Content-Type
○ X-Frame-Options

READY API: SENSITIVE FILES EXPOSURE

A8: INJECTIONS
hacker server
users
XSS injection
XML injection
JSON injection
SQL injection

A8: INJECTIONS: HOW TO TEST
● Secure module
● Commercial tool
● Automatic scanners for:
○ SQL
○ XSS
○ JSON
○ XML
● Professional security tool
● Commercial tool, free
limited version
● Automatic scanners most of
common injections
● Data-driven testing (with
Collection Runner)
● Free to some extend J
● Loading dictionaries for
SQL, XSS or any other
injections
● Manual analysis of results
OPTION 1 OPTION 3OPTION 2

READY API: SQL INJECTION SCANNING

BURP SUITE: XSS INJECTION SCANNING

POSTMAN: XSS INJECTION SCANNING

A9: IMPROPER ASSET MANAGEMENT
• Secure your CI/CD pipeline configuration
○ safely store secrets that you use in your pipelines
○ isolate sensitive files like code signing keys from repository
○ add monitoring to CI/CD pipeline
○ pull requests that come from forks of your repository
• Code and Git history analysis
○ passwords and accounts are not committed to repositories
• Sensitive information in HTTP requests
○ https://example.com/controller/123/action?apiKey=a53f43564a5 becaus
e API Key is into the URL.
Helpful article: https://circleci.com/blog/security-best-practices-for-ci-cd/

Full article: https://www.scmagazineuk.com/samsung-private-gitlab-tokens-exposed-including-source-code-credentials-secret-
keys/article/1584224/

A10: INSUFFICIENT LOGGING & MONITORING
● Write audit logs before and after security related events
● Consider logging token validation errors in order to detect attacks
● Take care of log injection attacks by sanitizing log data beforehand
● Auditable events, such as logins, failed logins, and high-value transactions are
logged
● Any scanning tools (like Burp) trigger alerts
● Appropriate alerting thresholds and response escalation processes are in place
Same as A10 in OWASP Top 10

DEVSECOPS APPROACH TO DEVELOPMENT
/ /
PIPELINE
Dev/Test Env Stage Env
Pre-approved
deployment
Prod
CONTINUOUS INTEGRATION (CI) CONTINUOUS DELIVERY (CD)
CONTINUOUS SECURITY (CS)
Master branch
Code is merged
Developer’
s machine
Feature is
implemented
SAST+SCA
checks
Secure
Coding
Practices
SAST+DAST
checks
Automated
Security
Testing (auto+
manual)
Security Requirements
IaC scripts for
Dev/Test env
Review
infrastructure
security
Pen testing by
3rd party
Threat modeling

There are bunch of other tools available. Use these criteria to pick the tool for you:
● Project goals(monitor level of security vs try out some new stuff vs be prepared for external pen testing)
● Regularity (one-time runs vs ongoing)
● Integrate it into all processes and CI/CD pipeline or not
● Complex multi-step authentication process
● Security testing coverage (scanning for application only vs infrastructure and configuration issues etc.)
● Environments to be used (cloud or not etc.)
● Users of the tools (test engineers, developers, devops, security guys)
● Standards to follow and comply (security standards, domain-specific standards)
HOW TO PICK THE RIGHT TOOL?

● Understand the data flow and relations between resources
○ Get to know the system and the API you’re testing by asking the questions
● Always sniff the traffic. Real traffic is better than documentation.
● Wean yourself of the UI
○ Don’t be afraid to generate API requests from the scratch
● Is there more than one version of the API?
● Use different clients: mobile/web/web-mobile?
● Use the old versions to generate more traffic
● Always look for more niche features
● Different protocols == different implementations
API PENTESTING: NEW MINDSET

To get deeper in the topic:
● Pixi as part of DevSlop project (https://www.owasp.org/index.php/OWASP_DevSlop_Project ) + video
tutorial (https://www.youtube.com/watch?v=td-2rN4PgRw)
● Juice shop - https://www.owasp.org/index.php/OWASP_Juice_Shop_Project
● Ads manager application - https://github.com/kovechenko/VulnerableAdvertisementAPI
● REST OWASP Cheat Sheet
https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html
● News about API security - https://apisecurity.io
To start from:
● OWASP Testing Guide - https://www.owasp.org/images/1/19/OTGv4.pdf
● Hack Yourself First by Troy Hunt - https://www.pluralsight.com/courses/hack-yourself-first
● Hack your API First by Troy Hunt - https://www.pluralsight.com/courses/hack-your-api-first
WHAT’S NEXT?

Contact me
Email: kate@fest.group
FB: Kateryna Ovechenko

QA Fest 2019. Катерина Овеченко. Тестирование безопасности API

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to QA Fest 2019. Катерина Овеченко. Тестирование безопасности API

Similar to QA Fest 2019. Катерина Овеченко. Тестирование безопасности API (20)

More from QAFest

More from QAFest (20)

Recently uploaded

Recently uploaded (20)

QA Fest 2019. Катерина Овеченко. Тестирование безопасности API