#03
Common API Vulnerabilities
Understanding Common Vulnerabilities will help you when you identify weaknesses when you’re testing APIs
We’ll cover most of the vulnerabilities included in the OWASP API Security Top 10 and other useful weakness : information disclosure and business logic flaws, and techniques to exploit
Table of Content
Information Disclosure
APIs are used to facilitate communication and data exchange between different software systems, and they play a crucial role in modern application development and Sometimes developer mistakenly disclose sensitive information here.
Information disclosure can be disclosed in various ways, depending on the specific vulnerability or weakness in the system. Here are some common areas where information disclosure can occur →
Error messages: Inadequate error handling can result in detailed error messages being returned to users or attackers. These messages may contain sensitive information such as database names, table names, or internal system paths.
API responses: APIs may unintentionally include sensitive data in their responses. This can happen if the API does not properly filter or redact sensitive information before sending the response.
Log files: Improper logging practices can lead to sensitive information being stored in log files. If log files are not properly secured or monitored, they may become a target for attackers looking to extract valuable information.
Configuration files: If configuration files are not adequately protected, they may contain sensitive information such as database credentials, API keys, or encryption keys.
Source code comments: Developers sometimes leave comments in the source code that unintentionally reveal sensitive information. These comments may be overlooked during code reviews and can be accessible to anyone with access to the source code.
Directory listings: If directory listings are enabled on web servers, attackers may be able to browse directories and access sensitive files or directories that should not be publicly accessible.
HTTP headers: Improperly configured HTTP headers can reveal sensitive information about the server or application, such as server versions or internal IP addresses.
Metadata and file properties: Documents, images, or other files may contain metadata or properties that reveal sensitive information, such as author names, locations, or revision history.
Backup files and archives: Sometimes, backup files or archived versions of websites or applications are not properly secured and may contain sensitive information that was not intended to be exposed.
Basically Sensitive data can include any information that helps attacker to gain advantage.
Ex → a site using wordpress API unknowingly sharing information with anyone who navigates to API Path /wp-json/wp/v2/users, Which returns all the WordPress usernames, or ‘slugs’.
GET https://www.sitename.org/wp-json/wp/v2/users
It Might Return like ;
[{”id”:1,”name”:”Administrator”,”slugs”:”admin”}],
[{”id”:2,”name”:”Krishna”, “slugs”:””}]
These slugs can used to attempt to login as the disclosed users with brute-force, credential-stuffing, or password-stuffing, or password-spraying attack ( will discuss in further series )
Error Messages
or Verbose messages helps API consumers to implement their application in right way. However, it can also reveal sensitive information about resources, users, and the API’s architecture like version of web server or databases)
Ex → you attempt to authenticate to an API and receive an error message such as “the provided user ID doesn’t exist.” then, you changed the User ID and error changes to “Incorrect Password”.
It let you know that User ID that you entered is correct so if there is no rate limit then you can try to brute forcing the Password of that user or try to bypass the rate limit and then try to brute force
You can gather the most information by interacting with an API endpoint and analyzing the response. API Responses can reveal information within headers, parameters, and verbose errors.
Other Good Source of information disclosure are API Documentation and resources gathered during reconnaissance
Broken Object Level Authentication
Occurs when API provider allows an API consumer access to resources they are not authorized to access.
Why it Happened ? → if an API endpoint doesn’t have object-level access controls, it won’t perform checks to make sure users can only access their own resources.
Object Level Authentication ? → APIs use some sort of values, such as names or numbers, to identify various objects
What we should do as hunter here ? → When we discovered these object IDs, We should test to see if we can interact with the resources of other users when unauthenticated or authenticated as different user
EXAMPLE :→
This poses no problem since we are authenticated to access Radhe Krishna’s Data. However,
if we are able to access another user’s information, there is BOLA vulnerability
What to do ?
In this situation, we might check for these problems by using another identifications number which is close to Radhe Krishna’s ID which is 852.
Congrats 🎉 : You Found BOLA
Note : For the application to be vulnerable, it must fail to verify that a given user is only able to access their own resources
How do we know that ? → this is object and this is not ?
By detecting patterns within API paths and parameters, you should be able to predict other potential resources.
following colored elements should catch your attention :
You can replace these colorized objects by examining the right pattern. “peter” is the username you can try to access other user’s username by simply replacing the peter
You just have to Examine right pattern of objects to FIND BOLA
Broken User Authentication
It refers to any weaknesses within the API Authentication process.
When it Occurs ? →
When API provider either doesn’t implement any Auth. Protection or Implemented wrong way
Why it Happen ? →
As, you Know REST APIs are supposed to be stateless. To maintain this statelessness API often require user to go threw registration process in order to obtain unique token.
User can include the token with each request to demonstrate that they are authorized to make requests.
What NExt ?
To test on token generation process if it is weak, collect samples of token if generated token doesn’t rely on high level of randomness, or entropy then there is high chance that you can generate your own token by properly examining the token
Token Handling method of transmitting tokens across network, the presence of hard coded token and so on.
if fails to Token Handling leads to detect hard coded tokens in Javascript source files or capture them by analyze web application
After Capturing Token ? → once authenticated using token
We can access to previous forbidden files, previously hidden endpoints or to bypass detections
Other Authentication : registration system
One another authentication mechanism which is registration process
password reset and multi-factor authentication features
EX:→ Imagine a password feature requires email address and six-digit code for verification
you can simple guess the six-digit code by brute forcing 1 million times
Until no rate-limit set
We can perform numerous attacks against API Authentication , such as auth bypass, brute forcing attacks, credential stuffing, and a variety of attack against tokens.
Excessive Data Exposure
Excessive data exposure when an API endpoint responds with more information than is needed to fulfil a request.
How it occurs → occurs when the provider expect the API consumers to filter the requests
→ Requesting information for their user account and receives information about other users accounts as well : API Exposing Excessive DATA
You Sent → GET /api/v3/accounts?name=krishna
Got following JSON in response
Requested For user ******krishna but provider responded with information about the person who created this account
How to Detect ? →
test target API endpoints
review the information sent in response
Lack of Resources and Rate Limiting
API Providers monitize their API by limiting requests and allowing paid customer to requests more information
Why Rate limiting ? →
Rate limit plays very important role in the API monetisation by service provider.
too many requests without rate-limiting will lead to provider's system crashing and become unavailable → denial of service (DOS) state
Attacker Perspective ? →
Can Bypass rate limits can cause additional costs for the API Provider
What after if Rate Limit is Applied ?
Once you are restricted from making additional requests
Try bypass it by:
adding or removing parameters
play with request headers
using different client
altering your IP address
Broken Function Level Authorization
When it Occurs ? →
User of one role or group is able to access the API functionality of another role or group
Different Different Role ? →
Local user, Public user, merchant user, partner user, admin user and so on.
BFLA is present if you are able to user the functions of a more privileged group
Different Btw BFLA & BOLA ? →
BOLA except instead of an authorisation problem involving accessing resources. BFLA is authorisation problem for performing actions.
EX→ a vulnerable Banking Website API.
if BOLA present : you might be able to access the information of other accounts, such as payment histories, usernames, email addresses and account numbers.
IF BFLA present : You might be able to transfer money and actually update the account information
BOLA is about authorisation access whereas BFLA is about authorisation actions.
Different Privilege functionality :
Application Could have → different endpoints to perform different priviledge actions
it may use /{user}/accounts/balance endpoint for accessing their account balance
it may use /admin/account/{user} endpoints for an administrator wishing to access any user account informations
If Access control doesn't implemented correctly → user will able to perform administrative actions, like seeing user's full account details by simple making administrative request.
It doesn't need to be always use endpoints for administrative functionality :
Functionality could based on HTTP Methods such as GET, POST, PUT, DELETE
Provider need to restrict on What HTTP Methods a consumer can use
💡 If Provider doesn't restrict the HTTP Methods for consumers then attacker's can simply make unauthorised request using different HTTP methods leads to BFLA Vulnerability
When hunting For BFLA →
look for functionality you could use to your advantage, including altering user accounts, accessing user resources, and gaining access to restricted endpoints.
📓 Note :
Easiest way to discover BFLA is to find API Documentation and send requests as an unprivileged user to test admin functions and capabilities
As an unprivileged user, make request included in the admin sections, such as attempting to create users, update user accounts, and so on. Successful request will discovered BFLA otherwise 401 or 403
If API Documentation isn't available → you need to discover or reverse engineer the endpoints used to perform privilege actions. Found Administrative endpoints ?, Then you can begin making requests
Mass Assignments
When it Occurs ? →
occurs when an API consumer includes more parameter in their requests than application intended and the application adds these parameters to code variable or internal objects.
consumer may be able to edit object properties or escalate privilege
Ex : →
API is called to create an account with parameters for “User” : “Password”
Suppose you discovered parameter “isAdmin”:true from API Documentation, Intercepting API Requests and responses or by fuzzing in API Request
If API doesn’t sanitize the request input, it is vulnerable to Mass Assignment too
Where to Find Paramenters ?
→ As I said you could find from API Documentation, Intercepting API Requests and responses or by fuzzing in API Request
Security Misconfiguration
→ Mistakes done by developers said Security Misconfig.
lead to sensitive information being exposed or a complete takeover
Lack of Input Sanitization: all command injection, XSS, Malicious Uploads and etc
Misconfigured headers result in information disclosure, downgrade attacks, Xss
API header uses additional services to enhance their API services and it’s common for those additional services to add headers
X-Powered-By: reveals backend technology. helps to know the exact backend supporting services
X-XSS-Protection: use to prevent XSS attack.
X-Response-TIme: Provides the response time
X-response-Time →consistent response time for non-existent record but it could be used to check if event is triggered or some process happened in backend and it is obvious in incrementation of response time
IMP :
💡 callUser3 might exist because of his unexpected response time
With this small sample of users’ response time, it is hard to conclude that User3 exists but if you have 100rs or 1000nds of requests
Un-necessary HTTP Methods
if API provider allows unnecessary HTTP Methods, there is an high risk in info. disclosure, might lead to delete data.
always try defaul credentials
Injections
injection flaws occurs when input isn’t filtered and allows unwanted characters, as result in injection flaws
Backend → basically application might treat data from the request as code and runs it and you’ll be able to conducts injection attacks such as SQLi, NoSQLi, command injections.
Any clue ? → Verbose error messages, HTTP response code and unexpected API behavior
Any error directly from database indicates clearly that there is an injection vulnerability
EX → Error: You have an error in your SQL syntax….
💡 Note :
Injection vulnerability often complemented by other vulnerabilities such as poor input sanitization.
and might results in command injection
EX → To Take advantage of this make a get req. but manipulating the parameter
[https://example.com/v1/resources/books?show=/etc/passwd](https://example.com/v1/resources/books?show=/etc/passwd) →
By manipulating the Field show=/etc/passwd results in command injection attack
How to Find ? →
Finding injection flaws involves thorough testing of API endpoints, careful monitoring of the API's responses, and crafting requests that aimed at manipulating the backend systems.
Improper Assets Managements
occurs when organisation exposes their APIs that either retired or still in development
Causes ? → lead to other vulnerability such as excessive data exposure, information disclosure, information disclosure, mass assignment, improper rate limiting and API injection
Discovering this should be your first step toward further exploitaion of an API
How to discover Improper assets managements ? →
paying close attention to outdated API documentation, changelogs, and version history on repositories
Organizations often include version info. in endpoints like /api/v3/users/token and etc
you might try to change the version from v3 to v1 or v2 and test those if not trashed/exist
How to discover it ? →
You can discover IAM by guessing, fuzzing or brute-forcing requests. Watch for pattern in APi doc or path-naming scheme and then make request on your assumptions
Business Logic Vulnerabilities (BLV)
intended features of Application that could me maliciously used.
Ex→ API uploaded feature that doesn’t validated encoded payloads, used could upload any file as long as it encoded, allows end user to upload and execute arbitrary code, include malicious payloads
One of the leading causes of This vulnerability is Experian trusted the partner not to expose the API cause in leakage of API keys, tokens and passwords
You can Seach API Doc for telltalke signs
like Only use feature X to perform function Y
Do not do X with endpoint Y
Only admins should perform req X
This indicates that API provider is trusting you won’t do any of the discouraged actions
Developer assume consumer will exclusively use a browser and won’t capture API req. lead to info. disclosure, API key leakage or use parameter the could be use negatively
by manipulating MFA=true to MFA=false could lead to bypass multifactor authentication
Conclusion :
Testing Bysiness logics could challenging because each business are unique, Automated scanner might not be able to detect any
You need to understand how business and API operates and then consider how you could use these features to your advantage by try breaking assumptions of developers
Last updated