API SECURITY:
ATTACK AND
DEFENCE
TUBAGUS RIZKY DHARMAWAN
tubagus.dharmawan@gmail.com
Everybody Can Hack #Batch2
Margo Hotel, 26 Feb 2019

DISCLAIMER
FOR EDUCATIONAL PURPOSE ONLY

OUTLINE
• 1. INTRODUCTION TO API
• 2. API FINGERPRINTING AND DISCOVERY
• 3. API DEBUGGING
• 4. API AUTHENTICATION
• 5. ATTACKING DEV/STAGING/OLD API

1. INTRODUCTION TO API

WHY API IS SO IMPORTANT?
“Without APIs, most software couldn’t exist”
https://appdevelopermagazine.com/what-is-an-api-and-why-are-they-important-to-developers/
https://offers.cloud-elements.com/hubfs/cld-2018-soai-final-2018.pdf

What is API?
https://dzone.com/articles/an-api-first-development-approach-1
“API (Application Programming
Interface) is a set of clearly defined
methods of communication between
various software components”

Popular API Examples
Google Maps API
YouTube APIs
Flickr API
Twitter API
Uber API
Github API

Why API Security is More Important
Than Ever
https://nordicapis.com/why-api-security-is-more-important-than-ever/
API security is complicated
Fixing a bug in an API vs. a comparable bug
on a standard website can cost anywhere
from 1.5 to 2x as much
Securing web APIs is slow, manual,
and reliant upon tester skill

API Standard: REST
Representational State
Transfer (REST)
the example of REST request
REST Procedure
• REST uses HTTP requests to exchange data
between client and server
• This is the sample CRUD operation. CRUD stands
for CREATE, READ, UPDATE and DELETE
HTTP METHOD
• POST => CREATE RESOURCE
• GET/HEAD => READ RESOURCE
• PUT/PATCH => UPDATE RESOURCE
• DELETE => DELETE RESOURCE
HTTP RESPONSE (STATUS CODE)
200 Ok 401 Unauthorized 500 Internal Server Error
201 Created 403 Forbidden
301 Moved Permanently 404 Not Found
400 Bad Request 405 Method Not Allowed

API Versioning
Where is the version defined?
1. Explicitly in the URL
• http://api.example.com/v1
2. Accept header.
• Accept: application/name-space.version+json
3. Custom header
• api-version:1

2. API FINGERPRINTING AND
DISCOVERY

” if you know the enemy and know yourself you need
not fear the result of hundred battles”
(Sun Tzu, the author of The Art of War)

What do you want to know?
• Where is the API endpoint(s) ?
• How developer handle versioning?
• What is the programming language(s)
used?
• What is backend data storage used?
• How client authenticate to use API?
Most of API vulnerabilities are in the authentication flow itself.

Where is the API endpoint(s) ?
• Public information
e.g. https://developer.twitter.com/
• Subdomain Brute force
e.g. https://github.com/guelfoweb/knock

How developer handle versioning?
• Public information

How developer handle versioning?
• Debug (e.g. curl)

What is the programming language(s)
used?
• Public information (Company Jobs/LinkedIn)
https://slack.com/careers/273588/s
enior-software-engineer-backend

What is the programming language(s)
used?
• Server Headers(Server/X-Powered-By)

3. API DEBUGGING

Debug API: Using Proxy
• How we can intercept traffic and
change the data?
• What will happen if we change
something or send something we’re
not supposed to the API backend
server?
• What backend server will respond?

Debug API: Using Proxy

Debug API: API Testing Tool
• Postman

4. API
AUTHENTICATION

Authentication Methods
Basic Auth /
Digest Auth
JWT (JSON
Web Token)
OAuth 1 /
1.0a / 2.0

Basic Auth
• HTTP Based
Authentication
• Can be
implemented in
web server or code
• Very easy to be
implemented and
run
• Credentials
Base64 of
username:pass

Digest Auth
• HTTP Based
Authentication
• Hashes the
username and
password
• Less common
than basic Auth
• Adds a layer of
encryption to
basic auth
• Uses MD5 &
Nonce to encrypt
User & Pass along
with Method and
URI

Attacks Mitigation
• Use SSL
• Limit retries per username
• Don’t protect single method for the url, protect
the all methods

JWT (JSON Web Token)
“JSON Web Tokens are an open, industry
standard RFC 7519 method for representing
claims securely between two parties.”
Public / Private
Key = RS 256
HMAC = HS256
Token Structure
Base64: xxxx.yyyy.zzzz
Header Body (Claim) Signature

JSON Web Token Structure
JWT Token Structure
Header
Body (Claim)
Signature

JWT Attack
Things you need to know
• JWT is not ENCRYPTION
• If Secret compromise JWT become worthless
• JWT signature is based on the JWT algorithm
JWT is not ENCRYPTION
Base64 -> xxxx.yyyy.zzzz
Header
Body (Claim) Signature

Decode

Bypassing the algorithm
H256
R256
None
API SERVERCLIENT
INTRUDER
1. The backend API server generates the token
using the algorithm and the secret and sends it to
the client
2. We intercept the connection and change
the algorithm in token header to none
3. Send it back to the server. The server verifies
the signature of the JWT token, opens the
header, neglects the verification process and
says the JWT is a valid token
3
2
1

Bypassing the algorithm

Brute Force
https://github.com/Sjord/jwtcrack

Mitigation
• Use random complicated key (JWT Secret)
• Force algorithm in the backend
• Make token expiration short as possible
• Use HTTP everywhere to avoid
MiTM/Replay Attack

OAuth
Can I access your
account info ?
I want to give “X”
access to my info
Here is the key to
access your info
Here is the key to
access my info
I want to access user “Z”
account with this key
“Y” Service
“X” 3rd party
WHY
OAUTH?
SIMPLE POWERFUL FLEXIBLE

OAuth Version
• OAuth 1.0 (Deprecated)
• OAuth 2.0
OAuth 1.0 OAuth 2.0https://hub.packtpub.com/what-is-the-difference-between-oauth-1-0-and-2-0/
The refresh token The short-lived access tokenThe complexity involved in signing each request Simplicity

Case Study: OAuth Attack
XSS & CSRF @ UBER
Jack Whitton
https://whitton.io/

XSS in a nutshell
https://dejanstojanovic.net/aspnet/2018/march/handling-cross-site-scripting-xss-in-aspnet-mvc/
Upload malicious script code to
the website which will be later on
served to the users and executed
in their browser
Attacker execute
malicious scripts into a
web application

CSRF in a nutshell
https://www.sohamkamani.com/blog/2017/01/14/web-security-cross-site-request-forgery /
Cross site : coming from a site
other than the one for which it
is intended.
Request forgery : Sending a
request which appears to be
legitimate but is actually
malicious.

1. Self XSS @ partners.uber.com
changing the value of one of the profile fields to
<script>alert(document.domain);</script>
causes the code to be executed, and an
alert box popped.

2. OAuth login flow (CSRF)
• User visits an Uber site which
requires login, e.g
• partners.uber.com
• User is redirected to the
authorisation server
• login.uber.com
• User enters their credentials
• User is redirected back to
• partners.uber.com
with a code, which can then be
exchanged for an access token
• the OAuth callback doesn’t use the recommended
state parameter
• /oauth/callback?code=...
• This introduces a CSRF vulnerability in the login
function

3. Logout CSRF
Browsing to /logout destroys the user’s
partners.uber.com session, and
performs a redirect to the same logout
function on login.uber.com

4. The Exploit
“Since the payload is only available inside the
attacker account, we want to log the user into
attacker account, which in turn will execute the
payload. However, logging them into attacker
account destroys their session (it’s no longer
possible to perform actions on their account).”
The Idea: Chain these three minor issues (self-XSS
and two CSRF’s) together

Make HTML page contains
a) Request the logout on partners only
(stop redirect by using CSP)
b) Initiate login @ partners (login to
hacker account using OAuth Code)
c) Redirect to profile page to execute the
self XSS payload, so that their details
can be accessed

Mitigation
• Always use SSL
• Always use state parameter to protect
against CSRF
• Check your code for XSS
vulnerabilities, one XSS can ruin
everything
• Be up to date with the standard

5. ATTACKING DEV/
STAGING/OLD API

Why?
• Still in development stage (Full of bugs)
• Forgettable
• Deprecated but still works
• Internal security team rarely test old/dev API
endpoints
• Production measure disabled (Rate limit,
Registration, etc.)
• Debug in most cases is turned ON

How to find old API ?
• API Versioning
• Explicit url
• Accept headers
• Custom Headers
• You can find it also in old documentation

How to find Dev / Staging API?
• Subdomain Brute Forcing
• beta.example, dev.example, qa.example, ..etc
• Public record & Search engines
• Social Engineering

Attack flow
• Find whether the Old/Dev API is connecting to
the same DB / Server as the production
• Find weakness at the Old/Dev API
• Use this weakness to affect the production API

Facebook Account takeover
vulnerability
http://www.anandpraka.sh/2016/03/how-i-could-have-hacked-your-facebook.html

Mitigation
• Delete old API once became deprecated
• Protect your Dev/Staging API with (password,
IP restriction, etc.)
• Add dev/staging API to your security scope

References

References
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication
• https://en.wikipedia.org/wiki/Basic_access_authentication
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication
• https://en.wikipedia.org/wiki/Digest_access_authentication
• https://stackoverflow.com/questions/2384230/what-is-digest-authentication
• http://resources.infosecinstitute.com/authentication-hacking-pt1
• http://www.dailysecurity.net/2013/03/22/http-basic-authentication-dictionary-and-brute-force-attacks-with-burp-suite/
• http://www.openwall.com/john/
• https://linuxconfig.org/password-cracking-with-john-the-ripper-on-linux
• http://resources.infosecinstitute.com/authentication-hacking-pt1
• https://developer.atlassian.com/static/connect/docs/latest/concepts/understanding-jwt.html#decoding-token
• https://jwt.io/
• https://www.sjoerdlangkemper.nl/2016/09/28/attacking-jwt-authentication/
• http://demo.sjoerdlangkemper.nl/jwtdemo/hs256.php
• https://gist.github.com/netcode/fc06250fdb81677d9acf008cda285a4b
• https://github.com/Sjord/jwtcrack
• https://www.npmjs.com/package/jwt-cracker

References
• http://oauthbible.com
• https://developer.twitter.com/en/docs/b
asics/authentication/overview/3-legged-
oauth
• https://dev.twitter.com/web/sign-
in/implementing
• https://oauth.net/2/
• https://stormpath.com/blog/what-the-
heck-is-oauth
• https://aaronparecki.com/oauth-2-
simplified/
• http://homakov.blogspot.com.eg/2012/0
7/saferweb-most-common-oauth2.html
• https://dhavalkapil.com/blogs/Attacking
-the-OAuth-Protocol/
• https://www.owasp.org/index.php/Denial_of_Service
• https://www.owasp.org/index.php/Brute_force_attack
• https://www.owasp.org/index.php/Testing_for_Brute_F
orce_(OWASP-AT-004)
• http://www.anandpraka.sh/2016/03/how-i-could-have-
hacked-your-facebook.html
• https://www.owasp.org/index.php/Cross-
site_Scripting_(XSS)
• https://www.owasp.org/index.php/Testing_for_Insecure
_Direct_Object_References_(OTG-AUTHZ-004)
• https://www.owasp.org/index.php/SQL_Injection
• https://en.wikipedia.org/wiki/Arbitrary_code_execution
• https://www.owasp.org/index.php/Code_Injection
• https://www.owasp.org/index.php/Command_Injection