I hope you are doing well and good.
You might have read a lot about OWASP Top 10 Web Application Security risks but have you read about OWASP API Security Top 10?
No? Well, you are at the right place. 😉
These days, APIs have become critical element of modern applications and security landscape has changed significantly since the rise of APIs. Hence, OWASP released a list of top 10 API Security vulnerabilities for the first time in 2019.
This blog post is a walkthrough of exploiting top 10 API vulnerabilities on vAPI which is Vulnerable Adversely Programmed Interface, a self-hostable PHP Interface that mimics OWASP API Top 10 scenarios in the means of exercises. It can be downloaded from : https://github.com/roottusk/vapi
It can be easily configured according to the instructions provided in README.md .
- XAMPP Server (Apache and MySQL)
Without wasting more time, lets get started with OWASP Top 10 API vulnerabilities.
1. Broken object level authorization
APIs tend to access user data by using an identifier in the parameter (such as id=5). This identifier can be predicted and replaced by an attacker (user with malicious intent) to the identifier of other users (e.g. id=6). If API does not perform proper authorization checks, it will let attacker access the data of other users. This attack is also called IDOR (Insecure Direct Object References).
Ideal Behavior of vAPI - API1
- Create a user with POST request (Fig 1.1)
- Get user details with GET request (Fig 1.2)
Exploiting vAPI - API1
It says that we can register as a user here. Is there something more ? 😯
- Created a user by providing details. (Fig 1.4)
- Got user details by making a get request. (Fig 1.5)
- Intercepted the request and enumerated the id from 4 to 1.
- API returned details of admin user while making request with id=1. (Fig 1.6)
What happened here?
Well, API did not perform permission checks while returning data based on the identifier and hence we got the flag.
2. Broken authentication
APIs do not usually implement user authentication properly. Broken authentication is anything which can lead an attacker to assume other user’s identity based on weak passwords, default passwords, brute-force/dictionary attacks or exposure of credentials/tokens to unauthorized actors.
Ideal Behavior of vAPI — API2
- Login by providing email-id and password to get Auth-Key. (Fig 2.1)
- Get user details by sending Auth-Key received in the previous response. (Fig 2.2)
Exploiting vAPI — API2
Ehh..We just logged in using credentials!! Are there any other credentials as well ?😕 Lets check Resources folder.
Yes, There is a csv file having too many credentials. Seems like they got leaked somehow. Lets use someone else’s credentials and get his details. 😋
Oops, there are too many of them; which one is correct? We can’t try all of them to get something juicy.
Intruder to the rescue.
- Sent the request using default credentials provided in the postman collection and intercepted the request. (Fig 2.5)
- Forwarded the request to Burpsuite’s Intruder to try credential stuffing.
- Added email and password as positions to undergo pitchfork attack. (Fig 2.6)
- Pasted the data from csv file for both payload positions and configured payload processing to segregate emails and passwords from the list. (Fig 2.7 and Fig 2.8)
- Launched the attack and got two more working credentials [200 OK], and copied the token of one of the users. (Fig 2.9)
- Used the token to get details of other user. (Fig 2.10)
Didn’t understand what happened here?
Well, API did not implement rate-limiting on authentication functionality and attacker gained access to the other user’s account with credential stuffing attack by feeding leaked credentials.
3. Excessive data exposure
APIs may return lot of unnecessary data in response and filter it on client-side to display only required data. An attacker can easily bypass client-side filtering by using proxy tool such as Burpsuite and access the excessive data returned in the response.
Ideal Behavior of vAPI — API3
- Setup server URL in base URL (Fig 3.1)
- Provide credentials and login (Fig 3.2)
- Post a comment (Fig 3.3)
Exploiting vAPI — API3
Android app from the Resources folder works fine, it logs in user after providing credentials. Can’t find what’s wrong here? 😕
Lets intercept the traffic and check.
- Setup mobile app through Burpsuite proxy to intercept traffic.
- Set base URL as server’s address.
- Provided credentials for login and intercepted the request. (Fig 3.4)
- Observed carefully the subsequent request for getComments.php and found that it is disclosing lot of information in the response and got the flag. (Fig 3.5)
Pretty easy huh?
API is returning excessive information in response to the login request, however not reflecting everything on the interface hence a proxy tool such as Burpsuite can help in finding unnecessarily exposed data.
4. Lack of resources and rate limiting
Most of the times APIs are not configured to protect itself from excessive amount of request made from client-side. An attacker can use this flaw to overwhelm the server with too many requests in order to perform denial-of-service (DoS) or to bypass authentication mechanism.
Ideal Behavior of vAPI — API4
- Provide mobile number in POST request to receive one time password (OTP). (Fig 4.1)
- Provide received OTP in POST request to get Auth-key. (Fig 4.2)
- Provide Auth-key in GET request to get user details. (Fig 4.3)
Exploiting vAPI — API4
It says OTPs are great way of authentication if and only if implemented securely. Hmmm… something to do with the OTP. But, do we have the OTP for provided mobile number provided in the postman collection?
No, we don’t.
Should we guess the OTP ? 🤔
But there are too many possibilities, we can’t try all of them manually.
Intruder is the way.
- Sent the POST request with mobile number, it said OTP sent. (Fig 4.5)
- Provided random OTP in POST request, intercepted it and sent it to Intruder. (Fig 4.6)
- Set OTP value as position and set 4-digit 1000 numbers in payload. (Fig 4.7 and Fig 4.8)
- Launched the attack and found that OTP was 1872. (Fig 4.9)
- Copied Auth-key from the response received from request with OTP as 1872.
- Pasted the Auth-key in GET request to login and received user details in response and hence got the flag. (Fig 4.10)
Wait… what we did just now?
Since rate-limiting was not implemented on second-factor authentication mechanism (OTP), we bypassed it by launching brute-force attack on OTP value and got the right OTP and hence user details.
5. Broken function level authorization
Some administrative functions are accessible without any authorization however are not exposed directly to the normal users, so these functions are secure according to the developers. In actual, these are only secure until and unless not discovered by an attacker, which can be easily done by trying educated guesses or brute-force attack.
Ideal Behavior of vAPI — API5
- Create user using POST request and providing username, password, name, address and mobile number. (Fig 5.1)
- Get the same user details through GET request. (Fig 5.2)
Exploiting vAPI — API5
Yes, We registered as a user but what else could be done? Is it something to do with admin rights? Lets check.
- Created a user by providing username, password, name, address and mobile number. (Fig 5.4)
- Got user details and intercepted the request, it was making request to getUser.php page. (Fig 5.5)
- What if we want to get details of all users? tried getAllUser.php but didn’t work.
- Again tried the same request with getAllUsers.php page and got details of admin user and hence got the flag. (Fig 5.6)
It was quite simple, right ?
We fetched details of other users by making an educated guess to a page which was not exposed directly to the normal users but it didn’t have any authorization check to verify the privileges of the user.
6. Mass assignment
Many a times, APIs trust user input received from the client-side and write it in the database without filtering. Attacker can find additional objects from API documentation, educated guesses or http responses, and add it in the request to gain unauthorized access to restricted functionalities. e.g. while registering a user, an attacker can append &admin=true parameter and could gain admin privileges.
Ideal Behavior of vAPI — API6
- Create user using POST request and providing username and password. (Fig 6.1)
- Get the same user details through GET request. (Fig 6.2)
Exploiting vAPI — API6
They said we will give you credits if you behave nicely but we didn’t get any. 😢
Should we be more nice? 😏
- Created user by providing username and password. (Fig 6.4)
- Got user details through GET request but credits field was blank. (Fig 6.5)
- Intercepted ‘create user’ request and appended another parameter as &credit=100 (tried to steal some credits). (Fig 6.6)
- 100 credits got assigned to the user and hence got the flag while getting user details. (Fig 6.7)
How did we receive credits ?
From the response of getUser.php we identified that there is another parameter named credits however as per the design there were no credits assigned while creating user. We tried to forcefully assign credit by creating another parameter in createUser.php request, as a result, we got the credits assigned and hence the flag.
7. Security misconfiguration
Security misconfiguration is anything which is a result of default or incomplete configurations, misconfigured HTTP headers, unnecessary HTTP methods, Cross-Origin resource sharing (CORS) misconfigurations, and verbose error messages containing sensitive data. An attacker may exploit these poor configurations to gain unauthorized access or break security mechanisms.
Ideal Behavior of vAPI — API7
- Create user using POST request by providing username and password. (Fig 7.1)
- Login using GET request and the same credentials. (Fig 7.2)
- Receive Auth-Key of the user and by sending the session ID of logged-in user. (Fig 7.3)
- Log out of the user account.
Exploiting vAPI — API7
It says, as an API it is expecting a cross-origin request, and they hope it works fine but we hope it does not. 😄
-> As a victim:
- Created a user with username and password. (Fig 7.5)
- Logged into user account using same credentials. (Fig 7.6)
- Received Auth-Key by providing session ID of logged in user. (Fig 7.7)
-> As an attacker:
a. Wrote a CORS exploit for getting Auth-Key from getKey.php page. (Fig 7.8)
Wanted to get Auth-Key of the victim but it needs session ID of the victim’s user accounts.
Can’t steal the session ID from victim? no problem, let the victim get it for us. 😉
b. Hosted the CORS exploit on attacker.exploit.com (fake domain) and sent the link to victim.
-> As a victim again:
5. Received a link from someone, got curious to check what’s in it for me.
6. Clicked on the link which is hosting CORS exploit, at the same time user account is logged-in in the browser.
7. When CORS exploit got executed, it made request to getKey.php while sending Session ID along in the request. (Fig 7.9)
8. The server, which is misconfigured to trust arbitrary host in the Origin header (attacker.exploit.com) sent back the Auth-Key and the flag.
-> As an attacker again:
c. Because attacker.exploit.com is attacker controlled server, we got hold of the Auth-Key of the victim and hence the account is compromised.
So, the victim clicked on the CORS exploit link received from the attacker and the server was misconfigured to trust any domain coming in the Origin header of the request and it sent back the credentials to attacker.exploit.com.
Injection attacks are not only prevalent in web applications but also have secured a place in OWASP top 10 API security list. API calls may include SQL query, NoSQL query, LDAP, OS, or other commands in the request. Injection attack happens when a server blindly executes the input received as a part of query from the user without filtering it.
Ideal Behavior of vAPI — API8
- Login using POST request by providing username and password. (Fig 8.1)
- Get Auth-key by providing session ID in the request. (Fig 8.2)
Exploiting vAPI — API8
It says that we aren’t getting credentials for this, what to do ? How to login? 😐
Lets try injecting something.
- Tried random username and password, intercepted the request and sent it to Intruder. (Fig 8.4)
- Added username and password as positions and SQL injection strings in payload. (Fig 8.5 and Fig 8.6)
- Launched attack and found some of SQLi payloads working and bypassing authentication. (Fig 8.7)
- Copied session ID of logged in user and used it to get Auth-Key of admin user. (Fig 8.8 and Fig 8.9)
Since, the authentication functionality was not filtering user input and server was using SQL language to query from database, we performed SQL injection attack and got access to admin credentials.
9. Improper assets management
APIs tend to expose more endpoints than it seems, especially the one from older versions. Developers may leave older version of APIs running for backward compatibility which might not have enough security mechanism implemented. A normal user may not have direct access to older version however an attacker can enumerate and discover them to misuse.
Ideal Behavior of vAPI — API9
- Login into admin account using username and password.
Exploiting vAPI — API9
Good news is that they just launched v2 of their API, but is there any bad news as well ? Lets find out.
- Didn’t have any password to login into admin account.
- Tried some random passwords but no luck. (Fig 9.3) Can’t even try brute-force attack, there is rate-limiting set in v2 API. Wait.. Was there rate-limiting set in v1 API and is it still accessible?
- Changed v2 to v1 in URI and got the response.
- Launched brute-force attack using SQL injection payloads and got some payloads working.
- Use the payload to login at api1 and got the flag. (Fig 9.4)
Was this really a good news?
v2 of API was launched with improved security mechanisms but v1 was still left open to invite attackers for a feast.
10. Insufficient logging and monitoring
Most of the times, APIs are not configured for monitoring, logging and raising alerts which make an attacker (who has compromised the system, or trying to) go un-noticed, further leading an attacker to maintain his persistence in the system, perform lateral movements and compromise critical systems.
This can easily be prevented if system is configured to identify and prevent the attempts of attack with the help of logging and monitoring.
“There is no walkthrough for Insufficient logging and monitoring since it a design flaw and an attacker has no role to play in exploiting this issue”
vAPI is Vulnerable Adversely Programmed Interface which is Self-Hostable PHP Interface that mimics OWASP API Top 10…
OWASP API Security - Top 10 | OWASP
A foundational element of innovation in today's app-driven world is the API. From banks, retail and transportation to…
OWASP API Security Top 10
The Open Web Application Security Project (OWASP) is a non-profit, collaborative online community behind the OWASP Top…
This was the first ever public blog written by me, please let me know how do you like it?
Follow for reading upcoming blogs on cyber security. Thank you.