Authors:
(1) Amit Seal Ami, Computer Science Department, William & Mary Williamsburg, Virginia, USA, and this author contributed equally to this paper (aami@wm.edu);
(2) Syed Yusuf Ahmed, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper (bsse1013@iit.du.ac.bd);
(3) Radowan Mahmud Redoy, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper (bsse1002@iit.du.ac.bd);
(4) Nathan Cooper, Computer Science Department, William & Mary Williamsburg, Virginia, USA (nacooper01@wm.edu);
(5) Kaushal Kafle, Computer Science Department, William & Mary Williamsburg, Virginia, USA (kkafle@wm.edu);
(6) Kevin Moran, Department of Computer Science, University of Central Florida Orlando, Florida, USA (kpmoran@ucf.edu);
(7) Denys Poshyvanyk, Computer Science Department, William & Mary Williamsburg, Virginia, USA (denys@cs.wm.edu);
(8) Adwait Nadkarni, Computer Science Department, William & Mary Williamsburg, Virginia, USA (apnadkarni@wm.edu). Table of Links Abstract and 1 Introduction 2 Overview of MASC 3 Design Goals 4 Implementation of MASC 4.1 Mutation Operators 4.2 Mutation Scopes 5 Using MASC 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. Authors: (1) Amit Seal Ami, Computer Science Department, William & Mary Williamsburg, Virginia, USA, and this author contributed equally to this paper (aami@wm.edu); (2) Syed Yusuf Ahmed, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper (bsse1013@iit.du.ac.bd); (3) Radowan Mahmud Redoy, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper (bsse1002@iit.du.ac.bd); (4) Nathan Cooper, Computer Science Department, William & Mary Williamsburg, Virginia, USA (nacooper01@wm.edu); (5) Kaushal Kafle, Computer Science Department, William & Mary Williamsburg, Virginia, USA (kkafle@wm.edu); (6) Kevin Moran, Department of Computer Science, University of Central Florida Orlando, Florida, USA (kpmoran@ucf.edu); (7) Denys Poshyvanyk, Computer Science Department, William & Mary Williamsburg, Virginia, USA (denys@cs.wm.edu); (8) Adwait Nadkarni, Computer Science Department, William & Mary Williamsburg, Virginia, USA (apnadkarni@wm.edu). Authors: Authors: (1) Amit Seal Ami, Computer Science Department, William & Mary Williamsburg, Virginia, USA, and this author contributed equally to this paper (aami@wm.edu); (2) Syed Yusuf Ahmed, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper (bsse1013@iit.du.ac.bd); (3) Radowan Mahmud Redoy, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper (bsse1002@iit.du.ac.bd); (4) Nathan Cooper, Computer Science Department, William & Mary Williamsburg, Virginia, USA (nacooper01@wm.edu); (5) Kaushal Kafle, Computer Science Department, William & Mary Williamsburg, Virginia, USA (kkafle@wm.edu); (6) Kevin Moran, Department of Computer Science, University of Central Florida Orlando, Florida, USA (kpmoran@ucf.edu); (7) Denys Poshyvanyk, Computer Science Department, William & Mary Williamsburg, Virginia, USA (denys@cs.wm.edu); (8) Adwait Nadkarni, Computer Science Department, William & Mary Williamsburg, Virginia, USA (apnadkarni@wm.edu). Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2 Overview of MASC 2 Overview of MASC 3 Design Goals 3 Design Goals 4 Implementation of MASC 4 Implementation of MASC 4.1 Mutation Operators 4.1 Mutation Operators 4.2 Mutation Scopes 4.2 Mutation Scopes 5 Using MASC 5 Using MASC 6 Future Work and Conclusion, Acknowledgments, and References 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, accidental misuse (T1) 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. Benign developer, harmful fix (T2): 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. Evasive developer, harmful fix (T3): 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, • Method overriding • Class extension is used for implementing or inheriting parent crypto-API interface or abstract classes respectively, and • Class extension • Object Instantiation is for creating anonymous inner class object from the implemented or inherited classes of crypto-APIs. • Object Instantiation 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. This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

How MASC Mutation Operators Bridge Security Gaps in Crypto-API Usage

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Comprehensive Comparison of Tools for Fitting Mutational Signatures

Crypto APIs' Role within Blockchain as a Service (BaaS)

How to Import Crypto APIs into Excel

The 5 Best Cryptocurrency Data APIs in 2022

Top 5 Crypto APIs for Developers

The #crypto-api Writing Contest by CoinGecko and HackerNoon

A Comprehensive Comparison of Tools for Fitting Mutational Signatures

Crypto APIs' Role within Blockchain as a Service (BaaS)

How to Import Crypto APIs into Excel

The 5 Best Cryptocurrency Data APIs in 2022

Top 5 Crypto APIs for Developers

The #crypto-api Writing Contest by CoinGecko and HackerNoon

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps