> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <1

Secure Software Development with Coding
Conventions and Frameworks
Takao Okubo, Hidehiko Tanaka

Abstract—It is difficult to apply existing software development
methods to security concerns. Especially security testing is hard.
We have been concerned with the fact that the restriction of
implementation affects the easiness of testing. In this paper we
propose a decision process of the coding conventions for security,
regardful for testing security. Then, we apply our method topreventing injection attacks on Web application programs, andproduce coding convention set against injection attacks. However,these conventions are not enough to prevent all kinds of attacks.
So we also discuss the security frameworks which complement theconventions.
Index Terms—security, programming, coding conventions,frameworks

I. INTRODUCTIONEXISTING software development methods, such as
waterfall model [1], UML [2] and various testing methods,
have succeeded at maintaining the quality of software products,
except security. Almost everyday SecurityFocus [3] reports
vulnerability of some software products/systems. Incidents like
information disclosure often make headline news because ofsoftware vulnerability. Now, we know what vulnerability iswell. It is a buffer overflow, SQL injection or cross-site
scripting (XSS). But we don’t know how to make software withno vulnerability. The reason of these failures is that theuniqueness of security inhibits the direct application of existingdevelopment methods. With regard to the design phase, most of
the security specifications are not functional, so it is not easy todescribe them with usual design model like UML 1 . Sameapplies to the testing. Test planners have to care about theside-effect of the vulnerability, unlike usual software bugs [5],[6].
The most effective security testing method is the black box
testing [7], [8]. Equivalence partitioning and boundary value
analysis [9], [10] are usual software black box testing methods
for enough coverage of testing data. But they are not useful for
most of security testing because it is difficult to prepare testing
Manuscript received December 17, 2006.
Takao Okubo is with Fujitsu Laboratories ltd., Kawasaki, Japan(corresponding author to provide phone: +81-44-754-2683; fax:
+81-44-754-2666; e-mail: okubo@jp.fujitsu.com). He is also with Institute ofInformation Security, Yokohama, Japan.
Hidehiko Tanaka is with Institute of Information Security, Yokohama, Japan(e-mail: tanaka@iisec.ac.jp).
1
UMLsec tries to describe security with UML [4].

data with enough coverage.
Some programming tips for avoiding vulnerability are known[11]. Sanitizing is one of the tips for preventing injection
attacks such as XSS. Almost of these tips are ad hoc and ad hoc
implementation often makes some omission. Additionally, they
do not provide the way of testing. We need exhaustive andeasily testable implementation.
ISO/IEC 15408, also known as Common Criteria (CC) [12] isa standard for building secure software. It provides theevaluation process of implementation and testing of software
products, as the process of specification. However, CC does notgive practical implementation and testing methods for eachsoftware product.
Existing security technologies and researches are not enoughto control software security through the development lifecycle.
Our goal is let the security requirement be achieved andverified like other software requirements, at the each phase ofsoftware development. We adopt secure software engineering
approach for our goal. We start this approach by trying to apply
using current software engineering methods to security
concerns. Current methods might turn out to be insufficient.
Then we would consider something new methods tocomplement them.
Focus of this paper is on the implementation phase ofdevelopment lifecycle. We propose a coding convention
decision process for security, considering testability. Next weapply our process to decide the proper coding conventions toprevent three types of injection attacks –SQL injection, OS
command injection and XSS–, known as famous security
threats at Web applications. Actually, even with the coding
conventions and existing frameworks are not enough to avoid
threats completely. We discuss what these frameworks shouldbe, and propose some new security frameworks.

II. DECIDING CODING CONVENTIONS FOR SECURITY
A. Effect of Coding Conventions on Security
Coding conventions are some rules for writing programsource codes [13]. They have been used at the programming
phase for years. Most of currently used conventions are about
coding style (indentation, naming, etc.) and mainly aim at
readability and maintainability. With regard to security, coding
conventions have hardly been adopted in the softwaredevelopment fields. We would like to insist that coding
conventions are also useful for security, but they should play

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <different role from existing conventions.
We have pointed out the importance of restriction of
implementation, because it affects the easiness of testing
security requirements. We have proposed the early security
cost estimate method using limited implementation options andtesting methods related with the implementation [14]. Fig. 1.
shows the architecture of the proposed method. Our research
illustrates that coding conventions are useful for building
secure software. Coding conventions for security havefollowing two characteristics:--They aim at security quality directly, rather thanmaintainability or readability.
--Therefore, they require strong restriction, which might
limit not only flexible coding but also some functional
availability.
The latter are supposed to conflict the feasibility of othersoftware requirements. So we need care to decide conventions
for security. Next we propose the decision process of coding
conventions for each security requirement.

2

defined. This part is important for making
conventions with no omission, so the persons incharge of this must be carefully. It still requires
some security and programming knowledge.
c)Extraction of Implementation Patterns:

Implementations of security specification, which
are the candidates of conventions, are extracted.
As various as possible implementation patterns
are preferable. At first the direct implementationof the specification should be extracted. Next,
indirect implementations, which do not aim at
the original specifications directly, but achieve
the specification consequentially, should bechosen.
d)

Selection/ Making order of Precedence: Convention

options are finally fixed here. Extracted
implementation patterns should be selected, andordered with the following valuation basis.
--Feasibility of testing observance of theconvention--Accuracy of testing--less conflict with other software functions
2) System-dependent decision: To select convention(s)from 1) options for each development project/ system. This
process should be available to persons with poor security
literacy. The persons should examine each convention
option with the following viewpoints:--less conflict with other functions of the target system--lower cost for testing

III. CODING CONVENTIONS FOR INJECTION ATTACKS
Fig. 1. Architecture of the proposed method.

B. Coding Convention Decision Process
Since we regard the verification of security as important, weprioritize the coding conventions which can be tested moreeasily. The decision process of conventions for every security
requirement consists of two parts: system-independent decisionand system-dependent one.
1) System-independent decision: This part is to decide
general set of convention options so as to enable at least oneof them adopted in various application systems. This
process is supposed to be executed once, by persons with
sufficient security literacy. The following is its detailed
procedure.
a)Definition of the Target Security Requirement: Thetarget Security requirement is defined here. For
example, “The program must prevent SQL
injection.”.
b)

Definition of the Security Specification: Security

specification which fulfills the requirement is

We applied the proposed decision process to some actual
security requirements, and tried to decide the generalized
coding convention options. This paper presents the application
to the prevention of Injection attacks such as SQL injection, OS
command injection and XSS.
A. Definition of the Requirement
An Injection attack is executed with injecting unanticipateddata as input of the target program by an attacker. The target
program sends a command to another module, as a databasemanagement system, OS or a Web browser. The commandincludes user input data usually as its parameters. If thecommand is changed by the input data to the unanticipated andharmful which do bad thing like information disclosure or
tampering, the program has vulnerability against injection
attacks. Therefore the security requirement can be defined as:“The program is required not to generate the unanticipatedcommand even with any user input data.”
B. Definition of the Specification
Injection attacks can be classified into two types.
Type A): Attacks using the input data which change thecommand syntax. They aim at security quality directly, rather

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <than maintainability or readability. Fig. 2. shows the typicalexample of this type. SQL syntax can be changed by the input“’ OR A=A”, so the attacker can avoid user authentication
without obtaining the password

3

PreparedStatement, we only have to take care that the strings
except parameters.
Table I shows the Java coding convention candidates(implementation patterns) to achieve the specification.
TABLE ICONVENTION CANDIDATES AGAINST INJECTION ATTACKS

No.
(a)

(b)
(c)

(d)
(e)
Fig. 2. The Example of Type A) injection. This is a typical SQL injection
pattern. The input value(password) changes the syntactical structure of theB): Attacks using the input only act as illegal
SQLTypecommand.

parameters, and do not change the command syntax. Input of
unanticipated database table name is an example of this type.
In this paper, we mainly discuss the injection of Type A).
Because most of the known injection attacks belong to Type A),
and Type B) problem can be treated as the current software
specification.
Then, the specification can be defined as the following:“The syntactical structure of the command should not bechanged by the user input.”
C. Extraction of Implementation Patterns
We have examined the specification, and devised thefollowing patterns of restriction policy:
1) Distinguish dynamic elements of the command such asparameters, variables, from static elements like reserved
words. When constructing the command string, be surethat the static elements do not involve data originally fromuser input. And before the command is constructed,
dynamic elements of the command must be sanitized, inother words, even if they include a reserved word, thestring should be escaped or eliminated so that it does notwork as the reserved word.
2) Be sure that the command string must be composed of only
the fixed values like constants.
3) Prohibit the functions/methods which invoke other module
by forwarding the command without sanitizing.
Concrete Implementation patterns based on above policies
vary depending on the programming language. Let us consider
the coding conventions with Java. JDBC provides two types ofclass
invoking
SQL
databases.
One
isjava.sql.PrepaedStatement(andits
subclass,
CallableStatement), and the other is java.sql.Statement.
PreparedStatement class [15] distinguishes parameters fromothers, and sanitizes the parameter string. So with regard to

Convention Candidates
Prohibit using the value originally from user
input for parameters of the methods setting
SQL statements (*).
Be sure to sanitize the parameters of (*)
methods, if the methods do not sanitize them.
Be sure that the parameters of (*) methods use
the value originally from constants or literal
strings only.
Be sure that the parameters of (*) methods use
the constants or literal strings only.
Prohibit the use of (*) methods(*) Methods setting SQL statements are:java.sql.Statement#executeXXX(): first argument,
java.sql.Statement#addBatch(): first argument,
java.sql.Connection#prepareStatement(): first argument,
java.sql.Connection#prepareCall(): first argument.

D. Selection/ Making order of Precedence:
The extracted candidates are examined by the feasibility/
accuracy of testing and less conflict with other functions.
Policy 1), 2) and Java convention (a), (b), (c) requires
dataflow analysis for testing. Policy 3) and (d), (e) requires
syntax analysis. Generally dataflow analysis is feasible, but its
accuracy is lower than syntax analysis. The order by theprobability of conflict is 3) > 2) > 1) and (e) > (d) > (c) > (b) >(a). Therefore we recommend the Java convention in the orderof (d) > (e) > (a) > (c). Recommendation order of (b) cannot be
determined because its accuracy depends on the validity of thesanitizing code.

IV. EVALUATION AND DISCUSSION
In this section we evaluate the coding convention options
decided in section III. First, we verify the conventions arefeasible for practical application programs. We clarify a limit ofconventions, and consider another approach with frameworks.
A. SQL Injection:1) Evaluation of Conventions
We have verified the feasibility of the proposed
conventions with the open source program codes found by
Bugle [16]. Bugle can find the source files with thesuspicion of various bugs, including SQL injection. We
have examined 185 files. In About 84% of the files,
Invocation of the SQL can be written with the fixed String,or with the parameterized PreparedStatement. So they canadopt the Java convention (d) (Table I.). 8% files are theprograms like SQL client. These programs permit arbitrary
SQL invocation, which cannot exclude the SQL injectionimport java.sql.*
import java.util.*;> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <by nature. In the rest of the files, the SQL commandchanges dynamically by the number of loop iteration orconditional branch. Fig. 3. shows the example.
This kind of coding is appeared in the programs which haveto build complicated search conditions. In this case,
PreparedStatement with fixed String cannot be used. So ProjectManagers of such system have to adopt convention (b) or (c).
2) Discussion of Frameworks.Net, Perl and some programming languages provide theprepared statement mechanism like PreparedStatement. A
distinct advantage of this mechanism is that programmers do
not have to take care of sanitizing: what are the dangerous
Statement stmnt;
Srting query = "SELECT *FROM table=xxtbl
WHERE id="
+ request.getParameter("ID");for int (i=1; i< keys.length; i++) {query+= " AND "keys[i] + "=" + values[i];}stmnt.executeQuery(query);}Fig. 3. The code example in which the SQL commandchanges dynamically.

characters and how to process them. However some application
programs cannot use the prepared statement if the SQL
command strings have to be changed dynamically. The
programmers have to code sanitizing routines by themselves,
and testers have to use more complicated and inaccurate
testing.
We consider that the secure framework should provide all thesanitizing methods for all invocation, so that the sanitizing
algorithm is hidden from the programmers. So we propose theclasses shown in Fig. 4. for the parts of the secure framework.
Although the classes are written with Java 5, they can be
migrated to other languages.
PreparedStatement is usually a fixed string, but
SecureStatement (Fig. 4. (a)) constructs the SQL query stringof PreparedStatement at each query execution. Programmers
add the string using the add() method, but the method
distinguishes parameters from the fixed values internally. Even
if the attackers input the data like “‘ OR A=A”, the string is notdefined as the fixed value, so it is treated as a parameter, andthen sanitized inside PreparedStatement class. ReservedSQL
class (Fig. 4. (b)) is used to identify the reserved words.
Programmers may define the fixed parameter such as tablename as enum, like ReservedSQL. It is also useful for
preventing Type B) injection.
If these classes are included into the framework, the coding
conventions will become simpler. The coding convention (d)will be enough for all programs.
B. OS Command Injection
1) Evaluation of Conventions
A method for execution of external OS command,
Runtime#exec() [17] does not invoke shell. So the injection

4

public class SecureStatement {static final PLACE_HOLDER "?";
private StringBuffer stmnt;
private ArrayList params;
private Connector conn;
SecureStatement(Connector conn) {stmnt = new StringBuffer();params = new ArrayList;}
public void add(Object arg) {if(arg instanceof enum) {stmnt.append(arg.toString());} else if(arg instanceof String) {params.add(arg);
stmnt.append(PLACE_HOLDER);} else {throw new IllegalTypeException();}}public void execute() {PreparedStatement pstmnt =conn.prepareStatement(stmnt);
for (int i = 0; i < params.size(); i++) {setObject(params.get(i));}
pstmnt.executeQuery();}};

Fig. 4. (a) SecureStatement class. It constructs the
temporal prepared statement internally.

attacks adding the shell scripts to the command do not work. 2
Furthermore, java provides Runtime#exec() which uses thestring array as its argument. So attackers cannot change thenumber of syntax element. The mechanism makes the program
considerably safe, but not completely. Attackers may input theattack command which consists of the same number of
elements. Runtime#exec() with string array cannot prevent thiskind of attack.
2) Discussion of Frameworks
In order to make the program secure against OS command
injection, a mechanism which distinguish parameters fromstatic elements is necessary. The ideal framework is supposed
to analyze the syntax of input data, and identify parameters like
SecureStatement. However, analyzing all the syntax of OS anduser command is not realistic. If the program can limit the kindsof commands, the reserved words which are allowed to use, canbe defined as constants like ReservedSQL.

2
If you invoke “/bin/sh”, “-exec” you can execute the shell script including
pipe and redirection.

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <5

TABLE IIHTML OUTPUT METHODS WITH JAVA (PART)

MethodoutputText()
outputURL

function
output text
output url attribute

outputAttribute()

output attribute

outputEvent()

output event attribute

outputScript()

output javascript

Argument
String text
String tagname
String url
String tagname
String attribute
String tagname
String attribute
String script/
parameter

Above approach is also useful for other languages which
invoke OS shell directly.
C. XSS
1) Evaluation of Conventions
XSS have the same characteristics with other injection attacks.
All you need to do is consider the HTML structure of the
response, in spite of SQL command/ OS command.
Basic idea of the proposed conventions is also useful for XSS,
but we have to be careful for sanitizing, since the sanitizing
manners must vary depending on the context. If the target data
are output in the text area like body text, you should escapethree characters. <, >, &. If they are output as the tag attributevalue of HTML, you should escape <, >, &, “, ‘. If URL
attribute, the data must be URL-formed, and so on.
The right output method/ function must be used according to
the context.
public enum ReservedSQL {SELECT("SELECT"),
INSERT("INSERT"),
UPDATE("UPDATE"),
DELETE("DELETE"),CREATE("CREARE"),DROP("DROP"),
WHERE("WHERE"),
AND("AND"),
OR("OR"),BLANK(" ");QUOTE("\'");.....
private String name;private ReservedSQL (String name) {this.name = name;}public String toString() {return name;}}Fig. 4. (b) ReservedSQL class. It is used to identify thereserved words.

Sanitizing ruleescape < > &tagname should be a fixed value
url should be a fixed value
tagname should be a fixed value
attribute should be a fixed value
tagname should be a fixed value
attribute should be a fixed value
script should be a fixed value
parameter should be a fixed value2) Discussion of Frameworks
If there is no framework, the solution is rather simpler,
because programmers can manipulate all the construction of
response HTML. Secure Framework is desired to prepare amethod / function for each output context. Table. II. shows theexample of the Java output methods.
Some frameworks make the situation a little more
complicated. Frameworks like Struts [18] prepares the response
JavaServer Pages (JSP) [19] file, so the programmer cannot
know directly on which part of the JSP file they are trying to
output data. Syntax Analysis of JSP is necessary to know thecontext of the writing data.
JSP has some other problems:--Expression Language directly outputs the value. You’dbetter prohibit the use of EL.
--You’d better prohibit the use of the scriptlet , because of
the same reason as EL.
--May be you should not allow the use of custom tags until
its safety is guaranteed.

V. CONCLUSION
The importance of coding conventions for security has
hardly insisted ever. In this paper we showed it is useful for
secure software development, and proposed the convention
decision process considering the testability and functional
conflict. Then, we developed general coding convention
options for injection attacks based on the proposed decision
process. Next, we evaluated the feasibility of the coding
conventions. Because of their common characteristics, theproposed convention options are basically useful, but they mustbe customized a little. We also proposed the desired security
function of framework which complements the flaw of theconventions. Please notice that our secure framework proposal
is not only the programming tips like others. Framework has
close connection with the coding conventions. They
complement each other. So when you have to get the program
secure you have to consider both of them. Furthermore,
framework and conventions are useful not only for
implementing the security, but also for easy testing.
We have noticed that the existing frameworks with security
function do not always contribute to the security quality. The

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <reason is the framework design lacks the concept of testability.
We hope the designers of the secure framework take thisconcept into consideration.
As the future work, we are going to develop anotherconventions set for other software requirements. And we arealso planning to do the empirical evaluation of the proposed
coding conventions and frameworks.
REFERENCES[1]

W. Royce, “Managing the Development of Large Software Systems”,
Proceedings of the IEEE WESCON, IEEE Press & Proceedings of theNinth International Conference on Software Engineering, IEEE Press,
1970.
[2] Unified Modeling Language, Object Management Group,
http://www.uml.org/.
[3] SecurityFocus, http://securityfocus.org/.
[4] J. Jürjens, Secure Systems Development with UML, Springer, 2004.
[5] B. Potter and G. McGraw, "Software security testing", Security & Privacy
Magazine, IEEE Volume: 2 Issue: 5 Sept.-Oct, 2004, pp. 81- 85.
[6] H. H. Thompson, "Why security testing is hard", Security & Privacy
Magazine, IEEE Volume: 1 Issue: 4 July-Aug. 2003, pp. 83- 86.
[7] G. McGraw, "Testing for security during development: Why we should
scrap penetrate-and-patch", IEEE Aerospace and Electronic Systems,
1998.
[8] C. Weissman, "Penetration Testing, Information security: an integrated
collection of essays, IEEE Computer Society Press, Silver Springs, MD,
1995.
[9] C. Karner, J. Falk and H. Q. Nguyen, Testing Computer Software Second
Edition, International Thomson Computer Press, 1993.
[10] B. Beizer, Software Testing Techniques, 2nd Edition, Van Nostrand
Reinhold, 1990.
[11] Secure Programming.com, http://secureprogramming.com/[12] Common Criteria for Information Technology Security Evaluation v2.3,
http://www.commoncriteriaportal.org/public/developer/index.php?menu=2, 2005.
[13] Code Conventions for the Java Programming Language, Sun
Microsystems, http://java.sun.com/docs/codeconv/.
[14] T. Okubo, N. Nakayama, Y. Wataguchi and H. Tanaka, "A Study on
Software Development Method which Fulfills Specified Security
Requirements" Computer Security Symposium 2006, pp.387-392.
[15] java.sql.PreparedStatement,Sun
Microsystems,
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/PreparedStatement.html.
[16] Bugle , http://www.cipher.org.uk/index.php?p=projects/bugle.project.
[17] java.lang.Runtime,Sun
Microsystems,
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Runtime.html.
[18] Struts, the Apache Software Foundation, http://jakarta.jp/struts/.
[19] JavaServer Pages, Sun Microsystems, http://java.sun.com/products/jsp/.

6