Encapsulate Field Restructuring Arrays

Information and Communication Technology Seminar, Vol. 1 No. 1, August 2005 ISSN 1858-1633 2005 ICTS 96

3. DESIGN OF SECURITY CONCERN REFACTORINGS

We present several refactorings, which are considered applicable to be implemented in Java, in order to increase the security level of its source code.

3.1. Encapsulate Field

One important requirement of secure code is data hiding. In the other word we can say that we have to avoid for making our data public [1]. The easiest way, although perhaps not secure enough, is by creating our data become private. This type of refactoring is included in 72 types of refactorings in [1]. Figure 1 shows codes before and after applying Encapsulate Field refactoring. An accessibility setting of a variable something was changed from public to private so that the value of the variable can not be directly read and written. Figure 1. Encapsulate Field refactoring

3.2. Restructuring Arrays

In [4], Viega and Messier wrote that one way of anti-tampering effort is by restructuring arrays. Since arrays can describe the information in their structure, it will help the attacker for understanding our code. Restructuring arrays in order to protect our data structure from tampering can be done by changing the structures of our arrays. Indeed, arrays is a weak data structure if we compare with a collection in Java but still arrays are used by large number of Java programmers. Consequently, we would like to provide refactoring for restructuring arrays in Java as one feature to increase the security level of the code. Referring to [4], we could restructure our arrays in four ways: a. Splitting a one-dimensional array into multiple one-dimension arrays see Figure 2. b. Folding a one-dimensional array into multi- dimensional array see Figure 3. c. Merging two one-dimensional arrays into a single one-dimensional array see Figure 4. d. Flattening a multi-dimensional array into a one- dimensional array see Figure 5. Definitely, restructuring arrays should be done not only in the declaration of the arrays such as double[ ] data = new double [20] but also in the accessing methods of the arrays. Figure 2. Array Representation of Splitting Arrays refatoring Figure 3. Array Representation of Folding Arrays refatoring Figure 4. Array Representation of Merging Arrays refatoring before refactoring public String something; after refactoring private String something; public String getSomething { return something; } public void setSomethingString argument { something = argument; } before refactoring A1 A2 A3 A4 A5 A6 after refactoring A1 A3 A5 A2 A4 A6 before refactoring A1 A2 A3 A4 A5 A6 A7 A8 after refactoring A1 A4 A7 A2 A5 A8 A3 A6 before refactoring A1 A2 A3 A4 A5 A6 A7 B1 B2 B3 after refactoring A1 A2 B1 A3 A4 B2 A5 A6 B3 A7 A1 A2 Security Concern Refactoring – Putu Ashintya Widhiartha Katsuhisa Maruyama ISSN 1858-1633 2005 ICTS 97 Figure 5. Array Representation of Flattening Arrays refatoring.

3.3. Generating Secure Random Number