1. API Security
learning from a Pentesters POV
API Strategy Workshop March 2015
Dr. Ir. Stefaan Seys, ZIONSECURITY
2. Who am I
2
๏ฝ Stefaan Seys
๏ฝ Security Expert at ZIONSECURITY
๏ฝ Postdoc researcher at KU Leuven / COSIC
COSIC
3. Outline
3
๏ฝ (no exponential graphs on nr of attacks, etc.)
๏ฝ High level security architecture and objectives
๏ฝ API security threats and prevention
๏ฝ Authentication and SSL/TLS
๏ฝ History revisited
๏ฝ Messages to take home
5. End-to-End
Security Components
5
API ServiceConsumer
Threat Protection
Authentication /
Authorization
Logging /
Auditing
Security
Analytics
Confidentiality
Development
Access
Identity Service
Authentication /
Authorization
Confidentiality
Identity Service
API Consumption Security API Exposure Security
Threat Protection
6. Who is the Consumer?
6
API Service
Browser or Browser plug-in
Mobile App
Back-end Service
Not possible to hide
long-term secrets.
Very tempting to hide
long-term secrets.
OK to use long-term
secrets.
8. Discovery
8
Public APIs are designed to be used by โexternalโ
parties
๏ฝ Documentation
๏ฝ API descriptors in standard formats
๏ฝ URI-style: Swagger, RAML, API-Blueprint, I/O Docs, etc.
๏ฝ SOAP: WSDL/XML-Schema
๏ฝ Hypermedia: JSON-LD, Siren, Hydra, etc.
๏ฝ This obviously helps in the discovery phase ๏
9. Swagger example
9
"paths": {
"/pet/{petId}": {
"delete": {
"tags": ["pet"],
"summary": "Deletes a pet",
"description": "",
"operationId": "deletePet",
"produces": ["application/json", "application/xml"],
"security": [{
"petstore_auth": ["write:pets", "read:pets"]
}]
"parameters": [{
"name": "petId",
"in": "path",
"description": "Pet id to delete",
"required": true,
"type": "integer",
"format": "int64"
}],
. . .
Attack point
HTTP method, how does it handle
unspecified methods?
OAUTH 2: which implementation?,
known vulnerabilities? How does it
validate tokens?
Scopes?
Is access validated? Link between user
and petId? Are IDs random? Injection?
XSS?
What if we do not set the โpetIdโ? What
if we do not give an int? Or > int64 max
size?
10. โClassic Discoveryโ in case the API is secret
10
What about just keeping your API secret?
๏ฝ Local Proxy or network sniffer
๏ฝ Guess / brute-force APIs
๏ฝ http://api.*.com/api/v?/*.json
11. Public API with a secret API keyโฆ
11
March 2014
Issue was already reported to them in 2010...
12. Story
12
๏ฝ Install the official Android App
๏ฝ Extract the APK file and install on an emulator
๏ฝ Use TCPDUMP to listen to traffic from App
๏ฝ Start App, enter garbage at login page
๏ฝ GET
/handler.php?CritickerKey=xxxxx&Function=UserSignin&UserName=asdf
asdf&Password=6d2dedb5b9e02d466a8d98b4c4398b1d
๏ฝ The Criticker API has a call to get the list of users!
๏ฝ GET handler.php?CritickerKey=xxxxx&Function=AccountUsers
๏ฝ And a call to request the current password! In
plaintext!!
๏ฝ GET
handler.php?CritickerKey=xxxxx&Function=LookupPassword&UserId=xxx
xx
13. What did they do wrong?
13
๏ฝ They created an API with โuselessโ, dangerous and
documented features
๏ฝ Call to get list of all users?
๏ฝ Call to get password of a any user?
๏ฝ Passwords are stored in plain text on the server
๏ฝ They use plain HTTP (no SSL)
๏ฝ The โkeyโ is sent over the network with every call
14. Secret API with docs in error message
14
๏ฝ Basic authentication (over SSL, no cert pinning)
๏ฝ With static fixed username/password for all users
(embedded in App)
๏ฝ Only โauthenticationโ is the userID
๏ฝ This userID is sequential (not random)
๏ฝ Returns a help file if you send a wrong API request
16. Fuzzing and invalid input
16
http://api.openweathermap.org/data/2.5/weather?id=2172797
๏ฝ Attack vector:
๏ฝ Replace the id parameter with โrandomlyโ generated
value
๏ฝ Purpose:
๏ฝ Get information through error message
๏ฝ Prevention
๏ฝ Ensure generic, consistent and correct error
messages that do not reveal any additional
information
17. Malicious Input
17
๏ฝ Attack vector
๏ฝ Craft malicious input that targets specific message parser,
implementation weakness, etc.
๏ฝ Vulnerable parser will recursively replace &lol9;
๏ฝ Resulting in a billion โlolโs; taking up 3GByte of RAM
<?xml version="1.0"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ELEMENT lolz (#PCDATA)>
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>
18. Malicious Input
18
๏ฝ Purpose
๏ฝ Attempt to put server in insecure state (if lucky)
๏ฝ Crash server
๏ฝ Prevention
๏ฝ Only use proven parsers
๏ฝ Patch your system
๏ฝ Input validation and sanitation
20. (SQL) Injection
20
๏ฝ Purpose
๏ฝ If used for authentication: get access without credentials
๏ฝ Dump database
๏ฝ Clear database
๏ฝ Prevention
๏ฝ Never use String operations to create โsemi-structuredโ
data objects such as SQL queries, JSON, XML, Xpath,
etc.
๏ฝ Use a parameterized API to construct the object instead
๏ฝ If not available: carefully ensure escaping all special
characters depending on the syntax of the interpreter
21. Cross Site Scripting (XSS)
21
Persistent XSS
API Server
1. Inject malicious
script
๏ฝ Prevention
๏ฝ Use context-aware
auto-escaping
๏ฝ When?
22. Cross Site Request Forgery (CSRF)
22
MyFace.com
Authenticated Session
Victim lured to visit attackerโs site
<a href=โhttps://www.myface.com/
update.php?relationship=Single%2
0and%20Desperate>Free beer</a>
POST
23. Cross Site Request Forgery (CSRF)
23
๏ฝ Purpose
๏ฝ Force end-user to execute a state-changing request (as
attacker never sees response).
๏ฝ Change userโs email address, reset password, transfer
funds, โฆ
๏ฝ Prevention
๏ฝ Include a per request random authentication code that is
verified on the server (once!)
24. CSRF does not apply to APIsโฆ
24
๏ฝ Normally SOAP and REST API authentication is not
done through a session (cookie)
๏ฝ Instead, every API call contains authentication
information
๏ฝ In a URL parameter
๏ฝ In the HTTP header (Oauth)
๏ฝ Part of the XML body (SOAP)
๏ฝ If you stick to these principles and use proper
authentication/authorization model, CSRF does not
apply.
26. Authentication
26
๏ฝ Basic/Digest authentication
๏ฝ Uses HTTP headers to identify users
๏ฝ WS-Security SAML and Username Tokens
๏ฝ SOAP/XML based authentication, passes credentials and assertions in
SOAP message headers, optionally signed and encrypted
๏ฝ API Key based authentication
๏ฝ each request to an API contains a key uniquely identifying the client
๏ฝ OAuth 1.x/2
๏ฝ HTTP-based interactions and flows that authorize usage of HTTP
resources (API, Web, etc). OAuth indirectly includes a step for
authentication but makes no claims on how that authentication should be
done.
๏ฝ JSON web tokens
27. Username / password ?
27
Apple Celebrity photo hack
๏ฝ Hidden API to find your phone
๏ฝ https://fmipmobile.icloud.com/fmipservice/device/
<apple_id>/initClient
๏ฝ Basic Authentication through SSL tunnel
<apple_id> : <password>
๏ฝ So far so goodโฆ
๏ฝ Server does not limit the number of attemptsโฆ
๏ฝ Same password for all you i-things on Apple (iCloud)
28. SSLโs Role
28
SSL โ The Good
๏ฝ Secures the actual client authentication; as majority of
web authentication is based on passwords/tokens
๏ฝ Compatible with vast amount of clients and servers
๏ฝ โEasyโ to set up (hard to do right)
๏ฝ Removes crypto burden from application developers
29. SSLโs Role
29
SSL โ The Bad
๏ฝ Compatibility -> Complexity -> Vulnerabilities
๏ฝ For APIs it is also mostly the only crypto layer
๏ฝ If broken -> huge impact
๏ฝ โBut we are using SSLโฆโ: it does not magically make
your site secureโฆ
๏ฝ If used with server side certs only, client side authentication is
not in scope
๏ฝ Transport layer security -> does not prevent many application
layer problems (injection, XSS, etc.)
33. Messages to take home
33
๏ฝ Security is very difficult to get right
๏ฝ Do not reinvent or worse, โimproveโ the wheel yourself
๏ฝ Web APIโs suffer more or less from the same general
โissuesโ as web applications
๏ฝ However, API โstructureโ allows for dedicated security
enforcement point
๏ฝ Messaging (Request/Response)
๏ฝ Authentication
๏ฝ Authorization
๏ฝ Tailor (authentication mechanism) to your consumer
๏ฝ Take your SSL setup seriously
