SECURE REFACTORING
Improving the Security Level of Existing Code
Katsuhisa Maruyama
Department of Computer Science, Ritsumeikan University
1-1-1 Noji-higashi Shiga 525-8577, Japan
Keywords:
Refactoring, software restructuring, software security, program analysis, software design.
Abstract:
Software security is ever-increasingly becoming a serious issue; nevertheless, a large number of software
programs are still defenseless against malicious attacks. This paper proposes a new class of refactoring,
which is called secure refactoring. This refactoring is not intended to improve the maintainability of existing
code. Instead, it helps programmers to increase the protection level of sensitive information stored in the code
without changing its observable behavior. In this paper, four secure refactorings of Java source code and their
respective mechanics based on static analysis are presented. All transformations of the proposed refactorings
can be designed to be automated on our refactoring browser which supports the application of traditional
refactorings.
1 INTRODUCTION
Software security is ever-increasingly becoming a se-
rious issue since software comes to play an essential
role in the real world and our lives much depend on
software (Devanbu and Stubblebine, 2000; Viega and
McGraw, 2001). A lot of code is running on a com-
puter that can access open communications networks
like the Internet, and it is exchanging data (or objects)
or providing application services over the networks.
Additionally, various kinds of mobile code snippets
(e.g., a Java applet or JavaScript) are being down-
loaded over the networks, and they are running on
personal computers that exist all over. In this context,
most software programs are no longer isolated from
malicious adversaries. In fact, software programs in-
cluding security vulnerabilities have been repeatedly
incurring the leaks of confidential information or the
discontinuation of e-commerce services. Neverthe-
less, there are an enormous number of vulnerable soft-
ware programs with unnecessary privileges, known
flaws, or weak access control settings on resources.
They have been designed and implemented without
regard to how an attacker breaks themselves (Viega
and McGraw, 2001; Howard and LeBlanc, 2002;
Hoglund and McGraw, 2004; McGraw, 2006).
To reduce the risk posed by attacks which try to
exploit security vulnerabilities, insecure software pro-
grams including vulnerable code should be eliminated
as much as possible. For this, two approaches can
be considered in general. One is that secure soft-
ware not including vulnerable code will be created
from scratch. No one might be able to create insecure
software programs if formal methods that support the
whole of software development are reasonably avail-
able. However, it is hard to in advance design and im-
plement secure software, and then it takes long time to
replace all existing insecure programs with newly cre-
ated ones. The other approach is that existing insecure
software will be changed into secure one by partially
modifying its design or code. This might not be able
to perfectly remove vulnerabilities from existing soft-
ware. Instead, it can decrease the likelihood of threats
(e.g., information disclosure or tampering with data)
as early as possible. This work employs the latter ap-
proach since the author emphasizes more feasible and
practical solution to a large number of vulnerable soft-
ware programs existing in the real world.
From the point of view of security improvement
by changing the design of existing code, it is worth
both discussing the impact of refactoring on security
and exploring refactorings which make software more
222
Maruyama K. (2007).
SECURE REFACTORING - Improving the Security Level of Existing Code.
In Proceedings of the Second International Conference on Software and Data Technologies - SE, pages 222-229
DOI: 10.5220/0001339102220229
Copyright
c
 SciTePress

secure. Refactoring is the process of altering the inter-
nal structure of existing code without changing its ex-
ternal (observable) behavior (Opdyke, 1992; Fowler,
1999; Mens and Tourw
´
e, 2004). If refactoring at-
tains design changes that lead to security improve-
ment, programmers (developers or maintainers) can
obtain a systematic way to remove several vulnerabil-
ities from an existing software program and to provide
secure one with the same behavior as before.
This paper proposes a new class of security-
concern refactoring, which is specially called se-
cure refactoring. Its goal is to improve the secu-
rity level of existing code irrespective of its main-
tainability. It detects security flaws (inadvertent code
flaws (Landwehr et al., 1994)) existing in software
programs and removes vulnerable code or fragile de-
sign that could be accidentally or intentionally ex-
ploited to damage assets. This process is performed
by repeatedly applying a series of small refactoring
transformations each of which preserves the behavior
of existing code. In this paper, four secure refactor-
ings of Java source code and their mechanics are pre-
sented. The proposed refactorings might be able to all
increase the protection level (confidentiality and in-
tegrity) of sensitive information. The main contribu-
tion of this paper is to collect several transformations
of refactorings which attain security improvement and
which will be codified into automated tools.
The remainder of the paper is organized as fol-
lows. Section 2 describes the general concept of
software security and security concerns in traditional
refactorings. Section 3 defines secure refactoring and
presents four transformations of the refactoring. Sec-
tion 4 describes conventional studies related to secure
programs. Finally, Section 5 concludes with a brief
summary and future work.
2 SECURITY CONCERNS
Software security has been a hot topic for some time,
and thus various kinds of studies about it have been
carried out (McGraw, 2006). However, few studies
have tried to discuss the impact of modification (or
evolution) of software on its security quality. This
section first describes security aspects the paper deals
with and Java’s security mechanism. Then it presents
several traditional refactorings which affect the secu-
rity level of existing software.
2.1 Software Security
According to the book (Gollmann, 2006), security is
about the protection of assets and protection mea-
sures are distinguished between prevention, detec-
tion, and reaction. This paper focuses attention on
the prevention, and assumes that secure code neither
discloses sensitive data (information) to unauthorized
users (i.e., confidentiality) nor allows them to change
the data (i.e., integrity). Other aspects (e.g., availabil-
ity) are considered out of scope although they are also
related to software security.
In this paper, the security level of software is mea-
sured based on the potential existence of vulnerable
code which might violate confidentiality or integrity
of sensitive data. Software including vulnerable code
is called insecure one. Code fragments with seri-
ous security vulnerabilities provide more opportuni-
ties for success of unauthorized access to sensitive
data. Conversely, it is more difficult for unauthorized
users to break code with less vulnerability even if vul-
nerable fragments slightly remain in the code. If a
code change removes vulnerable code fragments from
a software program and never inserts new vulnerable
ones into the program, such change makes the pro-
gram more secure, that is, the security level of the
software is improved (increased).
Every refactoring that will be proposed in this
paper deals with source code written in Java pro-
gramming language. Java’s security model revolves
around the idea of a sandbox, which is responsible
for protecting a number of resources (e.g., a file and
memory) according to a user-defined security pol-
icy (Oaks, 2001). This mechanism is less vulnerable
to external attacks if executing code does not contain
security vulnerabilities. However, awkward code in-
cluding improper accessibility settings or needlessly
flexible structure might violate the protection given
by the sandbox with no check. Therefore, it is impor-
tant to write or obtain secure code in addition to the
use of the secure platform.
As a security component built in programming
language itself, Java provides four possible access
levels for constructs such as fields, methods, classes,
and interfaces (Gosling et al., 1996; Oaks, 2001). If
a construct is declared
private , it is accessible from
only inside the class defining the construct. If no ac-
cess modifier is attached to a construct, it is deemed
to have a default (package) level. In this access level,
the construct is accessible from any class in the same
package as the class defining the construct. If a con-
struct is declared
protected , it is accessible from the
class defining the construct, classes within the same
package as the defining class, or subclasses of the
defining class. A
public construct can be accessed
from any class. For top-level (non-nested) classes,
only public and default can be specified. Moreover,
Java provides the keyword
final so that any program
SECURE REFACTORING - Improving the Security Level of Existing Code
223

code cannot accidentally or intentionally change the
properties of a construct. A final variable can be set
only once. A final field can be also set only once by
a constructor of the class defining it. A final method
can be neither overridden nor hidden. No subclass can
be derived from a final class.
2.2 Security Concerns in Refactorings
Refactoring is useful for improving the quality char-
acteristics of existing software. According to the def-
inition widely used in the software engineering com-
munity, its main goal is to improve the maintainability
of software. Unfortunately, the traditional definition
is not so much concerned with security characteris-
tics of software (Smith and Thober, 2006). Thus, pro-
grammers can find few refactorings that make exist-
ing code more secure without changing its observable
behavior.
It is worth investigating the effects on the security
level of software programs, resulting from the appli-
cation of traditional refactorings. Some refactorings
in Fowler’s catalog (Fowler, 1999) can increase the
security level of existing code. For example, the
En-
capsulate Field
refactoring converts the accessibility
setting of a field from public into private, and adds ac-
cessors (setting and getting methods) for the field. If
a field is declared public, any client (attacker in most
cases) easily obtains and modifies the value of the
field. This refactoring makes it harder for any client
to access the value of the encapsulated field; there-
fore the security level of the refactored code will be
increased. If such field is set at creation time and will
be never altered, the
Remove Setting Method refac-
toring can be further applied, which removes a setting
method for the field and declares the field final. A pri-
vate final field not having its setting method prevents
a client from changing the value of the field.
The
Encapsulate Collection refactoring replaces a
setting method for a collection (e.g., an array, list,
or set) with adding/removing methods for the collec-
tion, and rewrites a getting method of the collection
so that it returns either its unmodifiable view or its
copy. The code after this transformation does not al-
low any client to freely change the contents of the en-
capsulated collection. In addition, the
Encapsulate
Classes with Factory
refactoring in Kerievsky’s cata-
log (Kerievsky, 2004) reduces the possibility of mali-
cious access from any client by hiding classes which
do not need to be publicly visible. No attacker can ac-
cess sensitive data stored in the encapsulated classes
since any attacker has no way to know a name of such
class and a reference to its instance.
insecure
code
more
secure
code
Secure refactoring
behavior-preservation
transformations
Remove vulnerablilities from
existing code by transformations
security (-) security (+)
understandability (?)
modifiability (?)
Figure 1: Overview of secure refactoring.
3 SECURE REFACTORING
Secure refactoring is a collection of safe transforma-
tions each of which certainly increases the security
level of the refactored code. All the safe transforma-
tions ensure no change of observable behavior of the
refactored code. This means that the resulting set of
output values for the same set of legal (not malicious)
input values is the same before and after refactorings.
Figure 1 shows an overview of this refactoring. For
the definition of traditional refactoring, secure refac-
toring is defined as follows:
A change made to the internal structure of software
to make it more secure without changing its observ-
able behavior.
Both the secure and traditional refactorings have
the same property of preserving the external behav-
ior in a series of their transformations. A signifi-
cant difference between them is that the secure refac-
toring is intended for security improvement of exist-
ing code while the traditional refactoring emphasizes
the maintainability of the code. Of course, under-
standable or modifiable code is also useful for se-
curity improvement since security vulnerabilities of
such code will be easily detected and fixed. However,
many programmers with knowledge of software se-
curity often encounter situations in which they should
quickly eliminate security bugs and flaws from exe-
cuting code without regard to its maintainability. The
secure refactoring is designed to be used in this case.
By employing this refactoring on software develop-
ment or maintenance, the programmers will be able
to easily obtain software that is more secure than be-
fore without tedious checks and bug injection.
This section will explain four secure refactorings
and their mechanics in detail. Each refactoring has
a name, motivation, mechanics, and examples. The
motivation describes why the refactoring should be
applied and the result of its application. The mechan-
ics show a situation in which the refactoring should be
applied (called security smell), and they present con-
cise procedures of how to carry it out. The examples
ICSOFT 2007 - International Conference on Software and Data Technologies
224

// before refactoring (original)
public class Member {
private String name;
public Member() { }
public void setName(String n) {
name = n;
}
public String getName() {
return name;
}
}
// after refactoring (more secure)
public class Member {
private final
String name;
public Member(String n
) {
name = n;
}
public String getName() {
return name;
}
}
Figure 2: Introduce Immutable Field.
show code snippets before and after the application of
the refactoring.
3.1 Introduce Immutable Field
One of the important tenets of software design is
information hiding or encapsulation (Parnas, 1972).
This is useful for building secure software since it
hides inside its sensitive data and minimizes accessi-
bility of the data. In other words, secure code should
make a field private and provide accessors with the
lowest possible access level consistent with the code
that has to access the field (Bloch, 2001).
This concept is satisfied by using the
Encapsu-
late Field
refactoring that was already proposed. It
prevents other objects from directly accessing the en-
capsulated field. However, its value might be still
modified through its public (or non-private) getting
method although its setting method would be deleted
(or strongly restricted). To protect any field from ma-
licious modification, it should become immutable un-
less there is a reasonable reason that other objects
must modify it. In summary, a field must be declared
final if its value is set only once. This improvement is
named an
Introduce Immutable Field refactoring.
Figure 2 shows two code snippets in this refac-
toring. The underlines attached to the code indicate
differences between the two versions. As compared
with the original code, in the refactored code the key-
word
final was added to the field name and the value
of
name is always set in the constructor of the class
Member that defines name . The setting method for
name appearing in the original code was deleted.
The mechanics are shown as follows:
Security smell: In a target classC, there is a mutable
field f the value of which is set only once.
1. If f is declared public, use
Encapsulate Field
(206)
1
.
2. Find all calls to a setting method of f.
3. Check to see if the calls can be both moved all
together to the succedent position of a constructor
call creating an instance of C that defines f and
executed immediately after the constructor call.
⇒ If any call cannot be coupled with its corre-
sponding constructor call, cancel this refac-
toring.
4. For all constructors ofC, add a parameter that can
pass on the value of f, by using
Add Parameter
(275)
. Create an assignment for putting the re-
ceived value into f in each of the constructors.
5. Remove the setting method of f and all the calls
to the method.
6. Add the keyword
final to f in its declaration. If
all fields within C can be immutable, it should be
considered that the class becomes immutable.
3.2 Replace Reference with Copy
The value of a final field can be never changed once
it is set. However, data stored in this field can be
changed if its declarative type is both reference (not
primitive) and mutable. Consider a code snippet
shown on the top side of Figure 3. The value of the
field
name cannot be basically changed since it is de-
clared final and has no setting method of
name . How-
ever, any class makes it a success to modify the value
of the field
lastname if the class can access an in-
stance of the class
Member . Consequently, internal
data stored in
name can be altered by exploiting the
following simple code:
member.getName().setLastname("X");
where member is an instance of Member .
A major flaw is that
Member carelessly reveals
a reference holding an instance of the class
Name .
An attacker can obtain this reference by calling the
method
getName() , and then change internal data by
exploiting the obtained reference. To fix this security
flaw, the code of Member should not return the ref-
erence to an original instance that contains sensitive
data. Instead, it should provide an instance that con-
tains (partial) copies of the sensitive data. This im-
provement is named a
Replace Reference With Copy
refactoring, which is one of variations of Fowler’s En-
capsulate Collection
(208).
1
A parenthetic number indicates the page number of
Fowler’s catalog (Fowler, 1999).
SECURE REFACTORING - Improving the Security Level of Existing Code
225

// before refactoring (original)
public class Member {
private final Name name;
public Member(String fn, String ln) {
name = new Name(fn, ln);
}
public Name getName() {
return name
;
}
}
public class Name {
private String firstname;
private String lastname;
public Name(String fn, String ln) {
firstname = fn;
lastname = ln;
}
public void setLastname(String ln) {
lastname = ln;
}
}
// after refactoring (more secure)
public class Member {
private final Name name;
public Member(String fn, String ln) {
name = new Name(fn, ln);
}
public Name getName() {
return new Name(
name.firstname, name.lastname);
}
void setLastname(String ln) {
name.setLastname(ln);
}
}
Figure 3: Replace Reference With Copy.
A code snippet after the application of this refac-
toring is shown in the bottom side of Figure 3, in
which the code of
Name is the same as before. In the
refactored code, any attacker cannot modify the orig-
inal value of lastname without tampering the code
of
Name . Thus, the original value never damages al-
though its copy can be modified.
The mechanics are shown as follows:
Security smell: In a target class C, there is a public
final field f that holds either a reference to an in-
stance i storing sensitive data or a public getting
method m
f
that returns the reference to i.
1. If f is declared public, use
Encapsulate Field
(206)
. The getting method newly created is also
called m
f
.
2. Find all code fragments using the reference ob-
tained through m
f
, and check to see if each of the
fragments alters the value of i.
⇒ If any code fragment alters the value, con-
sider moving the fragment to either C or a
class existing in the same package as C by
using Extract Method (110) and Move Method
(142)
.
// before refactoring (original)
public class Member {
public String getInfo(Password pw) {
if (pw.check()) {
return "Confidential info";
} else {
return "No info";
}
}
}
public class Password {
private final String passwd = "SECRET";
private final boolean result;
public Password(String pw) {
result = passwd.equals(pw);
}
public boolean check() {
return result;
}
}
// after refactoring (more secure)
public final class Password {
private final String passwd = "SECRET";
private final boolean result;
public Password(String pw) {
result = passwd.equals(pw);
}
public final
boolean check() {
return result;
}
}
Figure 4: Prohibit Overriding.
3. Check to see if all the altering fragments are en-
closed in the package containing C.
⇒ If some of the fragments remain outside the
package, cancel this refactoring.
4. Modify m
f
so that it returns a copy of i.
5. Add a new method with the default accessibility
setting intoC, which is used to alter the value of i.
Guidelines similar to this refactoring were pro-
posed (Wheeler, 1999; Bloch, 2001), which suggest
that secure code should never return a mutable in-
stance to potentially malicious code. However, these
guidelines do not present concrete mechanics.
3.3 Prohibit Overriding
Polymorphism in object-oriented programming is a
powerful mechanism in which an instance can send
a message without knowing a class of the receiving
instance. Therefore, it makes code more flexible to
future extension. However, the excessive use of poly-
morphic calls with inheritance and method overriding
is dangerous since such calls allow an attacker to have
a chance to execute malicious code.
Consider a code snippet shown in the top side of
Figure 4. This well-mannered code fragment using
the two classes
Member and Password creates an in-
stance of
Password by giving a letter string indicat-
ICSOFT 2007 - International Conference on Software and Data Technologies
226

public class Fake extends Password {
public Fake(String pw) {
super(pw);
}
public boolean check() {
return true;
}
}
Figure 5: Malicious class using overriding.
ing a password, and then calls the method
getInfo()
with the created instance. The code fragment can ob-
tain sensitive information only if the given letter string
is equal to a right password
2
. At a glance, this pass-
word authentication seems to be secure. However,
a clever adversary can easily see confidential infor-
mation without knowing the right password by using
both the malicious class shown in Figure 5 and the
following code:
Password fake = new Fake("X");
System.out.println(member.getInfo(fake));
where member is an instance of Member . The class
Fake is derived from Password and its method
check() always returns true. The instance member
might be obtained from a class which is deservedly
contained in a framework containing
Member .
To avoid this attack, secure code should not allow
an arbitrary (possibly malicious) class ( Fake in this
case) to redefine a method existing in the code. Sim-
ply stated, the keyword final will be attached to the
method which has to block its overriding, as shown
in the bottom side of Figure 4. This improvement is
named a
Prohibit Overriding refactoring.
The mechanics are shown as follows:
Security smell: In a target class C, there is a call
to a method m of a class C
i
for an instance which
is given by external code, and any class can be
derived from C
i
.
1. Find all subclasses of C
i
and check to see if re-
spective methods of the subclasses override m.
⇒ If overriding methods exist, consider apply-
ing the Replace Inheritance with Delegation
(352)
to replace them with delegation meth-
ods. If some of them remain, cancel this refac-
toring.
2. Add the keyword
final to m in its declaration. If
there is no subclass of C
i
, make C
i
final.
2
Actually, a right password and sensitive information
must be stored in protected files instead of being hard-
coded.
3.4 Clear Sensitive Value Explicitly
According to Java’s garbage collection mechanism, it
is inadvisable for a running program to preserve sen-
sitive information in its memory area if it will be never
used in the future (SunMicrosystems, 2000). To pro-
tect such information from a stealer, it should be ex-
plicitly cleared at the earliest possible time.
A
Clear Sensitive Value Explicitly refactoring finds
statements which finally use (refer) the value of a
variable storing sensitive data, and identifies locations
where the needless value should be deleted. This
process is performed by analyzing data dependen-
cies (Ferrante et al., 1987) for a target code. A final-
use statement corresponds to a final-use node shown
as follows:
For a variable v in the target code, s
v
denotes a
statement either writing or reading the value of v,
and b
v
denotes a conditional statement (e.g.,
if or
while ) a branch of which includes s
v
(b
v
dangles
s
v
). A node n
v
corresponds to s
v
or b
v
on the control
flow graph (CFG) of the code, and P(n
v
) is a reach-
able path from a node which is one of nodes exe-
cuted immediately after n
v
. If there is at least one
P(n
v
) which does not include any nodes which cor-
respond to statements writing or reading the value
of v, n
v
is defined as a final-use node for v.
Figure 6 depicts several patterns of final-use nodes
(gray ones) for a variable v of interest. The nodes
labeled with
def and use mean statements writing and
reading the value of v, respectively. New statements
clearing the value of v should be inserted immediately
after all final-use nodes for v. In Figure 6, the triangles
indicate the respective insertion points.
Figure 7 shows code snippets in this refactoring.
In this case, the statement “
score = -1 ” was in-
serted (corresponding to Figure 6(d)). An attacker
cannot inspect the value of the variable score after
executing the inserted statement.
The mechanics are shown as follows:
Security smell: In a target classC, there is a method
m which keeps the sensitive value of a local vari-
able (a parameter) v until the execution of m is
terminated.
1. Check to see if the value of v is stored in an im-
mutable instance.
⇒ If an immutable instance is used, replace it
with the use of a mutable instance.
2. Find final-use statements for v.
3. Insert new statements that update the values of v
with dummy ones.
SECURE REFACTORING - Improving the Security Level of Existing Code
227

def def def
def
(a)
(b)
def def
(c) (d)
(f) (g)
(e)
use
use
use
def
use
use
use
use
use
insert
Figure 6: Final-use nodes (gray) and locations (triangles) where new statements should be inserted.
// before refactoring (original)
public class Member {
public void printMessage(int score) {
if (score < 60) {
print(score);
printMessage();
}
}
}
// after refactoring (more secure)
public class Member {
public void printMessage(int score) {
if (score < 60) {
print(score);
score = -1;
printMessage();
} else {
score = -1;
}
}
}
Figure 7: Clear Sensitive Value Explicitly.
Here supplemental remarks for the step 1 will
be mentioned. For example, if confidential in-
formation such as a password is stored in an in-
stance of the immutable class
String (more pre-
cisely,
java.lang.String ), String must be con-
verted into an array of
char since the value stored
in a
String -typed variable cannot be explicitly
deleted. In this case, several utility methods of the
java.util.Arrays class can be used for comparing
the contents of two arrays and deleting these contents.
Moreover, we note that this refactoring might
be adversely affected by compiler optimization since
several compilers will remove the inserted statements.
4 RELATED WORK
There are two main approaches that are available for
increasing the security level of existing software. One
approach is to use a checker which automatically (or
semi-automatically) examines source (or object) code
of a target software program before it runs. For ex-
ample, Jslint (Viega et al., 2000) is capable of detect-
ing security vulnerabilities by using 12 rules for writ-
ing source code. However, it does not provide a way
of how to remove the detected vulnerabilities. For
most programmers, some secure programming guide-
lines (McGraw and Felten, 1998; Wheeler, 1999;
Viega and Messier, 2003; Whittaker and Thompson,
2001; Graff and van Wyk, 2003) are well-known
rather than code checking. These guidelines are se-
cure and insecure code patterns (or idioms), which are
not formally created but pragmatically collected in re-
alistic programming. If vulnerable patterns appear in
software, the programmers should remove them ac-
cording to the guidelines by hand. In other words,
there is still no systematic mechanism and automated
tool for supporting secure programming. The pro-
posed secure refactoring has the potential to formalize
secure programming since it provides mechanics (ex-
plicit conditions and procedures) of detection and/or
correction which are all expected to be implemented
in an automated tool. Moreover, it seems to be a par-
ticular kind of secure programming which preserves
the behavior of existing code.
The other approach does not directly increase the
security level of existing software. Instead, it pro-
vides a secure environment in which untrusted soft-
ware programs safely run. The Java sandbox (Oaks,
2001) is one of the famous mechanisms that imple-
ment such environment. This approach can reduce the
burdens imposed upon programmers since it needs no
troublesome or error-prone modification of existing
software. The weak point of the approach is that it
requires the installation of an execution environment
and such environment is too general or typical to cap-
ture various kinds of vulnerabilities or sophisticated
attacks. Moreover, it must pay the overhead cost for
dynamically gathering and analyzing much informa-
tion about an executing program.
Unfortunately, there are few studies about refac-
toring concerning security. One of the studies pro-
ICSOFT 2007 - International Conference on Software and Data Technologies
228

vides a method that refactors an existing program into
distinct modules with high and low security (Smith
and Thober, 2006). The proposed refactoring identi-
fies code which depends on high security inputs by
using program slicing based on information flow of
C programs, and extracts a new module including the
code. Although the detailed mechanics and target pro-
gramming languages are different between this work
and mine, these aims are almost the same.
5 CONCLUSION
Although many programmers want to easily remove
vulnerabilities from existing software programs, there
are still few systematic mechanisms which are in-
tended to be codified into automated tools. This paper
has proposed secure refactoring which improves the
security level of existing code without changing its
observable behavior. Two main issues will be tackled
in future work.
• For the proposed secure refactorings to be prac-
tically applied to realistic software development,
tool support is considered crucial. Moreover, a
running implementation is essential for demon-
strating the feasibility of automation of the se-
cure refactorings. The author is currently working
on integration of the proposed refactorings into
our developed tool, Jrbx (Java refactoring browser
with XML) (Maruyama and Yamamoto, 2005)
3
.
Moreover, the implementation of the refactorings
might require elaboration of the presented me-
chanics.
• It is not guaranteed that each transformation of the
proposed secure refactorings neither changes the
behavior of an existing code nor inserts new vul-
nerabilities into the code. In addition to a theoret-
ical proof, the author will make a large number of
experiments with various programs to check the
ability of the refactoring transformations.
REFERENCES
Bloch, J. (2001). Effective Java: Programming Language
Guide. Addison-Wesley.
Devanbu, P. T. and Stubblebine, S. (2000). Software engi-
neering for security: A roadmap. In ICSE ’00: The
Future of Softw. Eng., pages 227–239.
Ferrante, J., Ottenstein, K. J., and Warren, J. D. (1987). The
program dependence graph and its use in optimiza-
tion. ACM TOPLAS, 9(3):319–349.
3
Jrbx can be downloaded from http://www.jtool.org/.
Fowler, M. (1999). Refactoring: Improving the Design of
Existing Code. Addison-Wesley.
Gollmann, D. (2006). Computer Security, 2nd ed. John
Wiley & Sons.
Gosling, J., Joy, B., and Steele, G. (1996). The Java Lan-
guage Specification. Addison-Wesley.
Graff, M. G. and van Wyk, K. R. (2003). Secure Coding:
Principles and Practices. O’Reilly & Associates Inc.
Hoglund, G. and McGraw, G. (2004). Exploiting Software:
How to Break Code. Addison-Wesley.
Howard, M. and LeBlanc, D. (2002). Writing Secure Code,
Second Edition. Microsoft Press.
Kerievsky, J. (2004). Refactoring to Patterns. Addison-
Wesley.
Landwehr, C. E., Bull, A. R., McDermott, J. P., and Choi,
W. S. (1994). A taxonomy of computer program secu-
rity flaws, with examples. ACM Computing Surveys,
26(3):211–254.
Maruyama, K. and Yamamoto, S. (2005). Design and im-
plementation of an extensible and modifiable refactor-
ing tool. In Proc. IWPC’05, pages 195–204.
McGraw, G. (2006). Software Security: Building Security
in. Addison-Wesley.
McGraw, G. and Felten, E. (1998). Twelve rules
for developing more secure java code. Java-
world. http://www.javaworld.com/javaworld/jw-12-
1998/jw-12-securityrules.html.
Mens, T. and Tourw
´
e, T. (2004). A survey of software refac-
toring. IEEE Trans. Sofw. Eng., 30(2):126–139.
Oaks, S. (2001). Java Security, 2nd ed. Addison-Wesley.
Opdyke, W. F. (1992). Refactoring object-oriented frame-
works. Technical report, Ph.D. thesis, University of
Illinois, Urbana-Champaign.
Parnas, D. L. (1972). On the criteria to be used in de-
composing systems into modules. Comm. ACM,
15(12):1053–1058.
Smith, S. F. and Thober, M. (2006). Refactoring programs
to secure information flows. In Proc. PLAS’06, pages
75–84.
SunMicrosystems (2000). Security code guidelines.
http://java.sun.com/security/seccodeguide.html.
Viega, J. and McGraw, G. (2001). Building Secure Soft-
ware: How to Avoid Security Problems the Right Way.
Addison-Wesley.
Viega, J., McGraw, G., Mutdosch, T., and Felten, E. W.
(2000). Statically scanning java code: Finding secu-
rity vulnerabilities. IEEE Software, 17(5):68–74.
Viega, J. and Messier, M. (2003). Secure Programming
Cookbook for C and C++. O’Reilly & Associates Inc.
Wheeler, D. A. (1999). Secure Programming for Linux
and Unix HOWTO. http://www.dwheeler.com/secure-
programs/.
Whittaker, J. A. and Thompson, H. H. (2001). How to Break
Software Security. Addison Wesley.
SECURE REFACTORING - Improving the Security Level of Existing Code
229