XSS / HTML Injection
Authorization and Authentication
Sensitive information disclosure
CORS Misconfiguration
API's over HTTP
CSRF
HTTP Verb tampering
Fuzzing / Boundary Checks
API Rate limiting
API Key Compromise
Measures of Dispersion and Variability: Range, QD, AD and SD
API Security - Null meet
1. API Security
n|u - The Open security community
Chennai Meet
Presenter : Vinoth Kumar
Date : 20/05/2017
2. # About Me
Application security engineer.
Blogger @ http://www.tutorgeeks.net
Email @ vinothpkumar333@gmail.com
https://null.co.in/profile/294-vinothpkumar
3. What is an API
An API is a list of commands that one program can send to another. It is used, so that individual programs can communicate with one
another directly and use each other's functions.
API allows two different application ( built on two different technologies ) communicate with each other.
Eg : A rails application accessing content from Java application and vice versa.
Need for an API
Let’s see the use cases of accessing contents of “website B” ( Using an API vs without an API )
If “website A” wants to access the content in “website B” , it will be difficult, if it fetches the content by parsing the HTML tags, since
website B may have code changes after few months. However, if website B provide API’s well documented, website A can access the
information without much difficulty by looking into the API documentation.
4. Using an API
Using username and password combination
Curl -v -u username:password -H “Content-type:application/json” -d ‘{JSON Input}’ -X HTTPMethod ‘API
Endpoint’
Using API Key
Curl -v -u API Key:test -H “Content-type:application/json” -d ‘{JSON Input}’ -X HTTPMethod ‘API Endpoint’
5. Security issues / Best practices in API
1. XSS / HTML Injection
2. Authorization and Authentication
3. Sensitive information disclosure
4. CORS Misconfiguration
5. API over HTTP
6. CSRF
7. HTTP Verb tampering
6. XSS and HTML Injection attacks
Vulnerable API Endpoint : api.vimeo.com/channels https://developer.vimeo.com/api/endpoints/channels
Vulnerable parameter : “Name” and “description”
curl -v -u username:password -H “Content-type:application.json”,
-X POST {'name': '<script>alert(document.cookie)</script>',
'description': '<marquee>HTML Injection</marquee>,
'privacy': 'anybody'}}
Reference : https://hackerone.com/reports/42702
7. Authorization and Authentication
Case study 1 :
Vulnerable API Endpoint : /api/user/
Login into the application using your valid credentials.
POST /login
{ credentials }
The below API call fetches your profile details
Actual request : GET /api/user/me
Intercept the request and modify the API call.
Modified request : GET /api/user/victim
Fetches the victim details .
Case study 2 :
Update the normal user to admin user. Now, normal user will have admin level privileges.
Now again downgrade back to normal user.
Vulnerability : Normal user still has admin level privileges.
8. Sensitive information disclosure - H1 Reports API
An attacker can disclose any user's private email by creating a sandbox program then adding that user to a report as a participant. Now
if the attacker issued a request to fetch the report through the API , the response will contain the invited user private email at the
activities object.
Steps to reproduce:
Go to any report submitted to your program.
Add the victim username as a participant to your report.
Generate an API token.
Fetch the report through the API
curl "https://api.hackerone.com/v1/reports/[report_id]" -u "api_idetifier:token"
The response will contain the invited user email at the activities object:
"activities":{"data":[{"type":"activity-external-user-invited","id":"1406712","attributes":{"message":null,"created_at":"2017-01-
08T01:57:27.614Z","updated_at":"2017-01-08T01:57:27.614Z","internal":true,"email":"<victim's_email@example.com>"}
Reference : https://hackerone.com/reports/196655
9. CORS Misconfiguration
Image, in example.com, we have the following header in the configuration
Access-Control-Allow-Origin: hello.com
www.evil.com wants to access the content in example.com
Request Blocked: The Same Origin Policy disallows reading the remote resource at http://www.example.com/. This can be fixed by
moving the resource to the same domain or enabling CORS.
Vulnerable CORS setting.
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
If the victim is logged into the application, the attacker can send an XMLHttpRequest to fetch the details.
Reference : http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html
10. API’s over HTTP
Vulnerable Request : curl -v -u username:password -H "Content-Type: application/json" -X GET
'http://example.com/api/vinoth/creditcard'
Imaging, the above API request is returning the credit card details of vinoth in response.
{“credit card” : 1111 1111 1111 1111, “expiry date”: “09/37”, “CVV”: 343 }
However, if you notice the above API call, it is accepting HTTP endpoint. Hence, it is vulnerable to sniffing attacks.
Remediation : All API requests should hit the secured endpoint i.e. only HTTPS
curl -v -u username:password -H "Content-Type: application/json" -X GET 'https://example.com/api/vinoth/creditcard'
11. CSRF - Twitter Cards API
POST
https://twitter.com/i/cards/api/v1.json?tweet_id=657629231309041664&card_name=poll2choice_text_only&forward=false&capi_uri=capi%3A%2F
%2Fpassthrough%2F1 HTTP/1.1
Host: twitter.com
Cookie: foo=bar
{"twitter:string:card_uri":"card://657629230759415808","twitter:long:original_tweet_id":"657629231309041664","twitter:string:selected_choice":"2
"}
POST
https://twitter.com/i/cards/api/v1?tweet_id=657629231309041664&card_name=poll2choice_text_only&forward=false&capi_uri=capi%3A%2F%2F
passthrough%2F1 HTTP/1.1
Host: twitter.com
Cookie: foo=bar
{"twitter:string:card_uri":"card://657629230759415808","twitter:long:original_tweet_id":"657629231309041664","twitter:string:selected_choice":"2
"}
Reference : https://hackerone.com/reports/95555
12. HTTP Verb tampering
HTTP Verb tampering : Trying random HTTP Methods.
API’s often use GET (read), POST (create), PUT (replace/update) and DELETE (to delete a record). Not all of these are valid choices
for every single resource collection, user, or action.
Make sure the incoming HTTP method is valid for the session token/API key and associated resource collection, action, and record.
For example, if you have an RESTful API for a library, it's not okay to allow anonymous users to DELETE book catalog entries, but it's
fine for them to GET a book catalog entry. On the other hand, for the librarian, both of these are valid uses.
13. Fuzzing - Array worth $500
Generates totally random input for the specified request parameters, hoping to provoke some kind of unexpected results.
Eg : If the API expects a string parameter , input an integer and vice-versa and check how the system responds.
Fuzzing IRCloud API’s
A security researcher discovered an API payload that would send invalid data to their own user process, which would repeatedly fail to
be handled correctly. This error handling loop prevented further access to their user account.
Actual request : {“_reqid”:1234, “cid”:5678, “to”: “#treehouse”, “msg”:”test”, “method”:”say”}
Modified request : {“_reqid”:1234, “cid”:5678, “to”:[“#treehouse”, “#darkscience”] , “msg”:”test”, “method”:”say”}
Reference : https://www.intelisecure.com/fuzzing-for-fun-and-profit/
14. API Rate limiting
X-RateLimit-Limit – The limit that you cannot surpass in a given amount of time
X-RateLimit-Remaining – The number of calls you have available until a given reset time stamp, or calculated given some sort of
sliding time window.
X-RateLimit-Reset – The timestamp in UTC formatted to HTTP spec per RFC 1123 for when the limits will be reset.
If you exceed the provided rate limit for a given API endpoint, you will receive the 429 Too Many Requests response with the
following message:
{
"message": "Too many requests. Check the X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset headers."
}
15. API Key - Compromise
It’s always better to mask your API key.
If the account is compromised , the attacker can note down your API key. This is dangerous, because even if the victim
changes his password realising the account compromise, the attacker can still have access to the account using his API
key.
Incase of account compromise, don’t just change the password, reset your API key as well.
17. Tips for API Security assessment
API Documentation of the target is the main source for your assessment.
OWASP API Security cheat sheets can be handy
https://www.owasp.org/index.php/OWASP_API_Security_Project
https://www.owasp.org/index.php/REST_Assessment_Cheat_Sheet
https://www.owasp.org/index.php/OWASP_SaaS_Rest_API_Secure_Guide