Web services and APIs are used in many web applications and mobile apps for the purpose of accessing and retrieving user data from the application server. Securing the web services and API endpoints are one of the major challenges besides application security testing practices. This blog will guide pentesters and developers to follow API security best practices on how to test API endpoints.
Contents:
- 1.Introduction to Web Services
- 2.What is an Application Program Interface (API)?
- 3.API Vs Web Services
- 4.Common Vulnerabilities of API and Web services
- 5.API Assessment Approach and Best Practices
- 6.API Security Testing tools
- 7.Conclusion
What is Web Services?
Web Service is a software service used to create a communication between 2 devices connected over a network through internet. In terms of applications, web services help a technology like PHP to communicate with another technology like JAVA or .NET in order to accomplish some user action like retrieving data from the server.
Web Services have some major components. They are:
- SOAP
- WSDL
- UDDI
- REST
- SOAP (Simple Object Access Protocol) is a messaging protocol for exchanging structured information in the web services implementation. SOAP generally uses XML to exchange data.
- WSDL (Web Services Description Language) is an XML based interface description language used to define the actual functionality of Web services like SOAP protocol.
- UDDI (Universal Description, Discovery and Integration) is a web service description for distributed registry of web services. It uses WSDL to describe the interfaces to be used in web services. It communicates using SOAP protocol.
- REST (Representational State Transfer) means that every unique URL is a representation of some object which supports common HTTP methods like GET, PUT, POST etc. REST services use JSON (Java Script Object Notation) to exchange data.
What is Application Program Interface (API)?
API allows both web and mobile applications to communicate with one another by using the widely used web service protocols like REST or SOAP.
API’s are used in many ways like exchanging data, fetching information from third party websites to display in our application and so on. For example, let’s consider virustotal.com - a popular online virus scanner application which uses around 60 to 70 different anti-virus programs to scan a file. Virus total uses API in the backend to communicate with all the anti-virus services to scan the uploaded file and display the results back in the screen.
In addition to that, virustotal also provides its own API services for end users to scan files directly using Linux CURL or python utility.
The above image of virustotal API shows the API URL endpoints are used to scan, report and rescan a file along with CURL, PHP and Python commands to run those endpoints from a local computer.
API vs Web Services:
API and web services both serve as a means of communication. The major difference between an API and web service is that, a web service allows interaction between two machines over a network to obtain platform in dependency whereas an API serves as an interface between two different applications so that they both communicate with each other.
Common Vulnerabilities of API and Web Services:
API and Web Services are vulnerable to various application attacks like SQL injection, XML injection and Command injection etc. Apart from the typical web/mobile application vulnerabilities, API itself has some specific vulnerabilities. They are:
- JSON or XML based vulnerabilities
- Vulnerabilities in API key or tokens
- Business logic issues
To demonstrate the vulnerabilities, a test API application called DVWS (Damn Vulnerable Web Services) is used.
SQL Injection on API Endpoint URL:
In DVWS, there is an API endpoint which displays the user information based on the user ID value. Hence, it’s possible for a Pen-Tester to test for SQL injection or Insecure Direct Object Reference (IDOR) issues in the endpoint.
In the above URL endpoint with user ID 2, I’ve tried adding a single quote to test for SQL injection possibility and found it to be vulnerable.
Then, I’ve extracted the database name and version using typical SQL injection methods.
XML External Entity Injection (XXE) in API services:
In DVWS, the application uses XML parser in the backend server to send and receive data to the server using API request and response. By capturing the request in Burp Proxy, we can see that the user input is passed on to the XML input. Therefore, a Pen-Tester can try out the XML injection or XML external entity attacks on the API endpoint.
By inserting an XML external entity, pentester can retrieve the internal configuration files of DVWS server, if the XML parser is vulnerable.
In similar ways, it is possible to test for any input validation flaws in API end points, API tokens and also in business logic vulnerabilities.
Exposure of internal API Endpoints via Frontend User Interface:
Sometimes, Application UI may expose sensitive files and internal API endpoints or API endpoints without proper authorization in client side code. Also the use of more number of third party APIs in Application’s front end may also bre exposed to public with some sensitive data.
Uncontrolled Third Party API’s in User Interface:
The risks related to uncontrolled third-party APIs demonstrate that the use of APIs is not limited to incoming calls from enterprise users and partners, but also outgoing calls from business applications to external services. These outgoing calls can be abused to exfiltrate data, such as exposed storage server APIs. Alternatively, public API calls may use compromised credentials to access enterprise services to exfiltrate data.
API Assessment Approach and Best Practices:
Some of the best practices that should be followed in a corporate environment while developing an application with API/Web services are included. They are:
Authentication:
API application should not use Basic Auth mechanism. Instead use standard authentication methods like JWT or Oauth. Application should use Max Retry features to limit the login bruteforce attempts.
Access Control:
Like any other application or network, Access control is one of the key security mechanisms that should be deployed properly in all the API endpoint URL, as well in the backend server.
API endpoints can be available for public and also for internal network usage. Hence depending on the business logic and usage level access control, mechanisms should be set properly.
For example, user authentication to the application should be centralized. Further, account take over attacks like Insecure Direct Object Reference (IDOR) should be restricted by using random Json Web Tokens (JWT).
JWT (JSON Web Token):
JWT’s are JSON Data structures. They contain session information as well as the information related to access control in APIs. JWT usually has the cryptographic signature (random value) to protect the integrity of the application.
In general, JWT has three parts of data in base64 encoded format. The first part is the security algorithm, the second is the actual session data, and the third is the cryptographic signature for access control purposes.
The “alg” value in the JWT token should never be the value of “none” which means the JWT is insecure. JWT tokens should not contain any sensitive information like user id and user password.
Use a random complicated key (JWT Secret) to make bruteforcing the token very hard. Application should not extract the algorithm from the header, instead application should force the algorithm in backend (HS256 or RS256).
JWT token should not store any sensitive data in the paylaod as it can be decoded easily.
API Keys:
API keys are helpful in preventing attacks like Denial of Service (DoS), thereby increasing the rate limiting functions of the applications. API keys should be properly encrypted and stored in the server, in order to stop key leakage through some data breach. Regarding to that:
- Require API key for every request to protect the endpoint.
- Return “429 Too Many requests” in response code, if requests are coming in large number.
- Limit request throttling to avoid DDOS or bruteforce attacks
Oauth:
API should validate redirect_uri server-side to allow only whitelisted URLs when Oauth is used for authentication. API should use state parameter with random hash to prevent CSRF on Oauth authentication process.
HTTP Methods and HTTPS:
API endpoints should use Transport Layer Encryption (TLS). By doing so, network layer attacks like Sniffing or Man in the Middle attacks (MITM) can be avoided. In addition to HTTPS, application should implement Strict Transport Security (HSTS) to prevent TLS or SSL downgrade attacks.
Further, API endpoints should allow only the whitelisted HTTP methods like GET, POST and PUT. Methods which aren’t whitelisted must be rejected with “405 method not allowed.”
Input Validation:
API/Web Service applications should follow strict input validation mechanisms to keep the application users and data secure. Input validation attacks are more critical and can cause reputational/financial loss to the organizations. In-order to thwart them, some practices must be followed. They are cited below:
- Do not blindly trust the incoming input parameter without validation.
- Validate the length and format of the user inputs.
- Use regular expressions properly to sanitize the inputs.
- Regular expressions shouldn’t consume a lot of CPU and time. Else, it may lead to Regular Expression DOS attacks (Re-DOS).
- In case of some wrong inputs from the user, application shouldn’t throw any backend errors to the user’s browser like SQL errors, XML errors, etc.
- Follow secure coding standards to develop API endpoint functions.
- Use of sanitation or input validation libraries or frameworks specific to API language should be mandatory.
- If application is parsing xml files, make sure external entity is not parsed to avoid XML eternal entity attack.
- API should validate content-type of the posted data from user input.
- Use an API gateway service to enable caching and deploy API resources dynamically.
Above are some of the approaches which can be used by Pentesters and API/Web Service developers to keep the Application secure from API related threats.
User Interface Data Leakage:
Application’s user interface should not leak any internal or third party API endpoints as it can be abused to exfiltrate API credentials or data.
You can read about the above vulnerabilities in web app penetration testing book in our github page.
API Security Testing tools:
Astra – Astra is a API Vulnerability scanner can be used by security engineers or developers as an integral part of their process, so they can detect and patch vulnerabilities early during development cycle. Astra can automatically detect and test login & logout (Authentication API), so it's easy for anyone to integrate this into CICD pipeline
Postman – Postman is a platform for development and testing of API services. It can be used for security testing of external API’s of an application.
Syntribos – Syntribos is an opensource automated API Vulnerability Scanner. Syntribos aims to automatically detect common security defects such as SQL injection, LDAP injection, buffer overflow, etc. In addition, syntribos can be used to help identify new security defects by automated fuzzing.
Conclusion:
Web Services and APIs have become a vital part of every application developed today because of their fast and secure communication features. Even though API has built-in security, it is still vulnerable to lot of threats which hackers can use to break application’s security.
Every company which develops API based applications like web, mobile or desktop (Thick-client), should carry out a proper API penetration testing assessment on their applications on regular basis.
How Briskinfosec can help you?
Briskinfosec has a capable team of security folks who possess vast experience in the field of API security assessment. Apropos of that, intense research is underway in both BINT (Brisk Intelligence Laboratory) lab as well in NCDRC (National Cyber Defence Research Centre) lab about how to secure API applications in a more efficient manner, thereby safeguarding the API applications from all possible threat actors.
References: