Authors:
(1) Amit Seal Ami, Computer Science Department, William & Mary Williamsburg, Virginia, USA, and this author contributed equally to this paper ([email protected]);
(2) Syed Yusuf Ahmed, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper ([email protected]);
(3) Radowan Mahmud Redoy, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper ([email protected]);
(4) Nathan Cooper, Computer Science Department, William & Mary Williamsburg, Virginia, USA ([email protected]);
(5) Kaushal Kafle, Computer Science Department, William & Mary Williamsburg, Virginia, USA ([email protected]);
(6) Kevin Moran, Department of Computer Science, University of Central Florida Orlando, Florida, USA ([email protected]);
(7) Denys Poshyvanyk, Computer Science Department, William & Mary Williamsburg, Virginia, USA ([email protected]);
(8) Adwait Nadkarni, Computer Science Department, William & Mary Williamsburg, Virginia, USA ([email protected]).
Table of Links
6 Future Work and Conclusion, Acknowledgments, and References
4.1 Mutation Operators
We designed generalizable mutation operators by examining the Java Cryptographic Architecture (JCA) documentation. We identified two common patterns of crypto-API invocation as follows: (𝑖) restrictive, where a developer is expected to only instantiate certain crypto-API objects by providing values from a pre-defined set, e.g., Cipher, and (𝑖𝑖) flexible, where the developers implement the behavior, e.g.,HostnameVerifier. While defining mutation operators of these two distinct patterns, we assumed a threat model consisting of the following types of adversaries:
Benign developer, accidental misuse (T1): A benign developer who accidentally misuses crypto-API, but attempts to address such vulnerabilities using a crypto-detector.
Benign developer, harmful fix (T2): A benign developer who is trying to address a vulnerability identified by a crypto-detector in good faith, but ends up introducing a new vulnerability instead.
Evasive developer, harmful fix (T3): A developer who aims to finish a task as quickly or with low effort (e.g., a contractor), and is hence attempting to purposefully evade a crypto-detector.
The restrictive operators mutate the restrictive values that abstracts away the crypto-API misuse. For example, the abstraction can be based on method chaining, changing letter case (JCA is case insensitive), and introducing alias variables, as shown in Listing 1. We implemented 6 mutation operators for restrictive crypto-APIs. Similarly, for the flexible APIs, we implemented mutation operators based on object-oriented programming concepts:
• Method overriding is used to create mutations that contain ineffective security exception statements, irrelevant loops, and/or ineffective security sensitive return value,
• Class extension is used for implementing or inheriting parent crypto-API interface or abstract classes respectively, and
• Object Instantiation is for creating anonymous inner class object from the implemented or inherited classes of crypto-APIs.
We created 6 more conceptual mutation operators based on flexible crypto-APIs. An example of flexible mutant is shown in Listing 3.
This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license.