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:

  • 01   Business needs drive corporations today to connect their enterprise to the Internet and third parties, thereby increasing risk
  • 02  With the advent of the extended enterprise, the concept of the perimeter is changing and diminishing
  • 03  When unauthorized access can be obtained remotely, private information about employees, customers, business partners, patients, passengers, etc. can be stolen or abused

Our 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:

  • 01   Transport Confidentiality
  • 02  Server Authentication
  • 03  User Authentication
  • 04  Transport Encoding
  • 05  Message Integrity
  • 06  Message Confidentiality
  • 07  Authorization
  • 08  Schema Validation
  • 09  Content Validation
  • 10  Output Encoding

Get a qoute