Web Services and API Security Testing
All the industries involving technology is in the middle of an evolution that is fueled for the most part by the API economy. The rise of the API and web services economy has opened flood-gates creating a wide range of business opportunities. They have revolutionized the market by enabling new and traditional products / services via different channels which have generated massive economic value.
Organizations around the world have long known about the concept of APIs and their potential benefits. However, it has not been until recently that many of these organizations have realized the benefits of Internal API infrastructures and web services, to stay competitive in their respective industries.
Companies still operating with their legacy systems often suffer from internal operational inefficiencies such as poor organization, dysfunctional communication, limited reusability and complex integrations. With such an environment, embracing an API infrastructure and exposing all assets as a service, organizations did rid themselves of these inefficiencies undergoing a comprehensive transformation but on the other hand, it did unlocked multitude of security concerns affecting businesses and its corresponding systems.
Security Testing
Security testing involves testing primarily if corresponding API rules or functions do what they are supposed to do without having any impact on the application or user from a security and privacy viewpoint. It is not a high-level testing where you want to test the security of a whole application on what it is supposed to do or how those can be exploited, but to be more specific, it is a piece-wise testing to identify key threats corresponding to Access Token misuses, insecure implementation or transmission and to validate that each individual function of the API works as expected, without being concerned about the “broader picture”.
From a web services perspective, in today’s date the ability to seamlessly exchange information between internal and external business units is crucial for success; yet most organizations employ a variety of disparate applications that store and exchange data in dissimilar ways and therefore cannot communicate with one another productively. Web services have evolved as a practical, cost-effective solution for uniting information distributed between critical applications over the operating system, platform, and language barriers that were previously impassable.
The security testing would uncover all issues and handle them, rather than not catch them. It will encompass bad or out of range input/output, or otherwise ensure that it doesn’t cause damage. As an API tester, we would check whether the API sends the appropriate error message to the calling program, allowing the program to handle the problem correctly. Error messages should not disclose any sensitive information via which attackers can footprint the environment.
With the perimeter now being dynamic:
- Business needs drive corporations today to connect their enterprise to the Internet and third parties, thereby increasing risk
- With the advent of the extended enterprise, the concept of the perimeter is changing and diminishing
- When unauthorized access can be obtained remotely, private information about employees, customers, business partners, patients, passengers, etc. can be stolen or abused
Comprehensive Approach for Security Testing
We focus on each and every layer of the suite and based on the architecture we emphasize to drill down as per WeSecureApp’s security testing procedures.
For Web Service we primarily focus on the interactions between corresponding roles of the service provider, service registry and the service requestor. Based upon the interactions and operations involved such as publish, find and bind operations we review how it acts upon the Web Services artifacts i.e. the web service software module. Considering a typical scenario, a service provider hosts a network accessible software module (an implementation of a Web service) and we emphasize to dissect the services which will be published or provisioned to service registry or service requestor and look forward to asses at minimum the following key attack areas:
- Transport Confidentiality
- Server Authentication
- User Authentication
- Transport Encoding
- Message Integrity
- Message Confidentiality
- Authorization
- Schema Validation
- Content Validation
- Output Encoding
We focus to evaluate each of the following areas within the suite for a comprehensive security assessment:
Custom Application Code: This generally is the code which is primarily the first layer of the suite which will help create a parametric based XML file that will take in values for the method calls to be done through the web-service. This will be application and web-service specific custom code.
XML / JSON / property files: These type of files generally send requests to web-services, based on the values that will be entered by the team/users. It will be based on the specific needs of the application and parameters needed by the web service. It will be generated by the custom code layer.
SOAP / REST Layer: This will be the protocol layer which will handle the request – response by the web service. A medium which supports and helps implement web service.
Database Layer: This layer is generally used to store all application data. It also stores the logs and the time consumed by each service, i.e. the instrumentation data.
Reporting Layer: This layer in general helps in generating user readable data. Multiple security issues are found in this layer.
Intelligence Gathering: In this phase we emphasize to:
- Identify the architecture of the code
- Analyse the design construct
- Identify the security controls
- Analyse the attack surfaces
- Potential technical impacts correlation
- Identify potential vulnerable parameters
Vulnerability Analysis: This phase focuses on
- Automated scanning and verification using licensed, and open source tools
- Identification of vulnerabilities
- Manual security review for (but not limited to following):
- Business Logic Issues
- Insecure Fields
- HTTP Verb Tamper
- Insecure Class Modifiers
- Unused External Reference etc.
Vulnerability Exploitation and Infiltration: In this phase, we primarily validate the accuracy of identify exposures and see the extent of damage. It includes:
- Identification of false positives and creating Proof-of-concept (PoC) for reporting.
- Analysis and extraction of conclusions
- Build draft report based on determined report format
- Quality assurance exercise