6. Automated Assistance to the Security Assessment of API for Financial Services

This chapter presents the challenges related to the security assessment and the auto- mated synthesis of mitigation measures of APIs for financial services. The focus is on the APIs supporting the implementation of the new Payment Services Directive. It also gives an overview of an innovative approach to address these challenges by (i) the automated identification and mitigation of security misconfigurations underlying sessions based on Transport Layer Security, which is ubiquitously used to build a foundation layer of security; and (ii) the automated penetration testing and synthesis of mitigations for the functionalities provided by APIs built on top of it, both business (e.g., payments) and security (e.g., authentication or authorization). The main novelty of the proposed approach lies in the tight integration of identification and mitigation phases by means of actionable measures that allow users to significantly strengthen the security posture of the entire API ecosystem

RestTestGen: Automated Black-Box Testing of RESTful APIs

RESTful APIs (or REST APIs for short) represent a mainstream approach to design and develop Web APIs using the REpresentational State Transfer architectural style. When their source code is not (or just partially) available or the analysis across many dynamically allocated distributed components (typical of a micro-services architecture) poses obstacles to white-box testing, black-box testing becomes a viable option. Black-box testing, in fact, only assumes access to the system under test with a specific interface. This paper presents RestTestGen, a novel approach to automatically generate test cases for REST APIs, based on their interface definition (in Swagger). Input values and requests are generated for each operation of the API under test, with the twofold objective of testing nominal execution scenarios and of testing error scenarios. Two distinct oracles are deployed to detect when test cases reveal implementation defects. Our empirical investigation shows that this approach is effective in revealing actual faults on 87 real-world REST APIs

Summary of: A Federated Society of Bots for Smart Contract Testing

The peculiar novelty of smart contracts is a computational model where irreversible transactions are stored in a distributed persistent data storage, namely the blockchain. The technical nature of this new type of software opens to new kinds of faults, which require specific test capabilities to be revealed. In this paper we present SoCRATES, an extensible and modular framework to automatically test smart contracts. The distinctive features of SoCRATES are: (1) a collection of composable behaviours that exercise smart contracts in the blockchain; (2) it deploys a society of bots, with the purpose of detecting defects arising from multi-user interactions, which are impossible to reveal when deploying a single bot. Our empirical investigation demonstrates that SoCRATES is able expose both known and previously unknown faults in smart contracts that are actively run in the official Ethereum blockchain. Moreover, we show that a society of multiple bots is more efficient in fault exposure than a single bot alone

Automated black‐box testing of nominal and error scenarios in RESTful APIs

RESTful APIs (or REST APIs for short) represent a mainstream approach to design and develop Web APIs using the REpresentational State Transfer architectural style. Black-box testing, which assumes only the access to the system under test with a specific interface, is the only viable option when white-box testing is impracticable. This is the case for REST APIs: their source code is usually not (or just partially) available, or a white-box analysis across many dynamically allocated distributed components (typical of a micro-services architecture) is computationally challenging. This paper presents RESTTESTGEN, a novel black-box approach to automatically generate test cases for REST APIs, based on their interface definition (an OpenAPI specification). Input values and requests are generated for each operation of the API under test with the twofold objective of testing nominal execution scenarios and error scenarios. Two distinct oracles are deployed to detect when test cases reveal implementation defects. While this approach is mainly targeting the research community, it is also of interest to developers because, as a black-box approach, it is universally applicable across different programming languages, or in the case external (compiled only) libraries are used in a REST API. The validation of our approach has been performed on more than one hundred of real-world REST APIs, highlighting the effectiveness of the approach in revealing actual faults in already deployed services