JOURNAL OF COMPUTING, VOLUME 4, ISSUE 12, DECEMBER 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.

ORG

Assessment of Potential SQL Injection Threat into the Design Phase

S. Hedayatpour, S. Chuprat
Abstract Different statistical reports show rapid increasing in the number of security incidents caused by malicious software and software bugs. In facing with security threats, static and dynamic analysis tools address the main security features that have been used for the years but unfortunately there is still a big problem in deal with these tools where the cost of fixing all type errors in implemented software is several times more than the cost of fixing errors at the design level. This research provides a new method of security analyze base on known properties and behaviors of SQL injection attack to enhance the security resistance of the developing software against this attack. This security analysis provides valuable information for developers and helps them to improve the resistance of the developing software against SQL injection in early phase of software design. Index Terms security incidents, security threat, security analysis, security resistance, SQL injection, software design, risk assessment

1 INTRODUCTION
Software companies lose thousands and millions of dollars annually because of finding different security breaches and bugs in their software products where such a problem may turn the company into the bigger disaster with losing public confidence and market. The Computer Emergency Response Team (CERT) that tracks security incidents caused by malicious software, reports 2099% increasing in the number of these types of incidents from 1998 to 2002. Because of this rapid increasing in number of security incidents; developing software products that only response the expected functionalities, is not the only concern of today software developers but also there must be sufficient proofs to ensure that developed software protects users and system assets from security threats breaches [1, 2, and 3]. In facing with security threats, static and dynamic analysis tools address the main security features that have been used for the years but unfortunately there is still a big problem in deal with these tools where the COCOMO developers confirm that the cost of fixing all type errors in failed software is about 20 times more than the cost of fixing errors at the design level. It means, even if the secu

S. Hedayatpour is with the Advanced Informations School, University Technology Malaysia, International Campus, Jalan Semarak, Kuala Lumpur, 54100, Malaysia. S. Chuprat is with the Advanced Informations School, University Technology Malaysia, International Campus, Jalan Semarak, Kuala Lumpur, 54100, Malaysia.

rity bugs and holes be detected by static and dynamic analysis tools before final products become to the market, the financial benefits of company already decreased because of huge fixing cost [4, 5, and 6]. In this paper we present a new method of security analysis base on known properties and behaviors of SQL injection attack to enhance the security resistance of the developing software against this attack. In practice, there is a main difference between normal application testing and application testing for security point of view; in conventional application testing, the main focus is on functionality and performance but security view of application testing adds another approach that concerns about the errors which may happen unintentionally by normal users or intentionally by attackers who try to exploit the softwares vulnerabilities and consequently violate Confidentiality, Integrity or Availability of the software system [1]. By evaluating system conditions, security controls, and other relevant factors, this security analysis helps developer to improve the resistance of the developing software against SQL injection in the early phase of software design and before the starting of implementation and coding phase. The rest of this paper is organized as the following sections: Section II introduces similar works where the process of conducting security analysis is presented in Section III, and finally we conclude this work in Section IV.

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 12, DECEMBER 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

2 SIMILAR WORKS
The NIST checklists of 800-30 with title of Risk Management Guide for Information Technology Systems [7] and 800-37 with title of Guide for Applying the Risk Management Framework toFederal Information Systems [8] refer to two famous security checklists that the main concepts of our security analysis come from these two. The Unified Modeling Language Security (UMLsec) that was introduced in 2002 by Jan Jurjens [9] and ModelBased Design and Analysis of Permission-Based Security that also was introduced by Jan Jurjens in 2005 [10] along with Security Quality Requirements Engineering Methodology (SQUARE) which was introduced in 2005 by Nancy R. Mead, Eric D. Hough, and Theodore R. Stehney [11] refer to the other similar works to our security analysis.

If any type of input validation is performing, whether consider all potentially relevant properties such as: including length, type of input, the full range of acceptable values, missing or extra inputs, and syntax?

8 9 10

The critical information such as user names and password are stored in clear text or encrypted and hashed? Whether using the databases such as MS SQL, which allows shell command execution? Whether security checks are applied in both client and server side?

4 PROPOSED SECURITY ANALYSIS

The entire process of conducting SQL injection-based security analysis is divided into the several steps that each of them includes operations and actions. Establishing threats identification table refers the first step in this process where a database must be established with content of SQL injection signatures, bugs, actions and behaviors that attacker may be used in this attack. This information may be gathered from security agencies, security violation reports, incident reports, and media. Since the content of this database (List of potential security threats by source of environmental, natural, and human) must be asked from the system owners and stakeholders; these contents shall be prepared in form of security questions as is shown in table 1(as the content of threats identification table will be used to finding potential bugs and threats, it must be prepared by security experts who have practical experiences in deal with SQL injection and ask them to prepare this table as comprehensive as possible). TABLE 1 EXAMPLE OF THREATS IDENTIFICATION TABLE
No. 1 2 3 Security Questions Will the target website or application store high value data (business, political, social, etc)? Is there any automatic or scheduled mechanism for installing the patches and updates? Is there white or black list input validation mechanism? If yes it apply on which of them: 4 5 6 Input from users? Parameters from URL? Values from cookie?

After preparing the threats identification table and in the second step, general agreement must be set with system owners and technical staffs. In this step any needed information for answering security questions of threats identification table must be found. Various information such as the levels of access control mechanism, levels of confidentiality for different data types, programming language, level of trust for different users, communication channels and their secrecy, interfaces, target data base and its version, and many other critical information that must be gathered to specifically answer the technical questions of the threats identification table. When the answer of all security questions is extracted, we shall move to the next step that is Vulnerability Identification which uses security tests, audit results, security requirements checklist, vulnerability advisories, and security standards to find the potential vulnerabilities in associated with identified threats. Table 2 illustrates the correlation between an identified threats and corresponding vulnerabilities. TABLE 2 EXAMPLE OF VULNERABILITY/THREAT PAIR
Vulnerability Threat Action

Storing critical information such as usernames and password in form of plaintext and without any encryption mechanism Using old and risky versions of software (without installing updates and patches) Lack of any mechanism for checking contents of error messages

Dialing into the network of company and accessing proprietary info

Taking advantage from the found and known bugs in certain old versions for inject the SQL query Inserting unexpected input to receive error messages and extracting valuable information, which a error message may Show up

Receiving the input from untrusted users and send it to the data base without validate the content MS SQL allows shell command execution

Inserting SQL query and command instead of normal input

Is there any applying mechanism to strip the error messages from the information that may be used by attackers? The version of databases that allows batch execution is used (such as SQL Server 2000)? If you are using hosted servers or if you are using outsourced technical resources, is there any third party review of your site security?

Inserting shell command instead of normal input and executing shell command by attacker

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 12, DECEMBER 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

At the fourth step, the likelihood of launching SQL will be determinated based on the information that is found from previous steps such as threat capability, motivation, nature of the vulnerability, and existence and effectiveness of current controls. As the output of this step and according to the identified security conditions, the likelihood of launching successful SQL injection on the developing software will be estimated in one of the rate of Low, Medium or High. After finding the likelihood of attack, the impact of launching successful SQL injection on the software must be estimated (impact described in terms of loss of integrity, confidentiality, availability) where it also rated in one of the levels of Low, Medium or High. When the likelihood and impact of the threat be determined, the level of the risk may be calculated according to the following relation:

Medium

Using whitelist mechanism for input validation Using automated/scheduled mechanism for installing the patches and updates Applying mechanism of content checking for error messages

Low

Using an input validation mechanism No using of risky software versions

Table 4 illustrates an example of security controls and factors which may be recommended to developers based on determined risk level and other related factors to SQL injection. These recommendations try to eliminate or at least mitigate the risk.

Risk Level = Threat Impact * Threat Likelihood

4 CONCUSION
(1)
Since statistical reports proves that the rapid increasing in the number of security incidents is caused by malicious software and software bugs, our security analysis provides valuable security information to developers and help them to improve the resistance of developing software against losing Confidentiality, Integrity, and Availability caused by a successful SQL injection. In terms of best protection, this security analysis works in Synchronization with static analysis tools to enhance the level of quality into the final codes and bring higher level on confidence for users. As this research presents a new method of security analyze that works base on known properties and behaviors of SQL injection attack and without asking for a security expert team, it will bring commercial benefit for software companies by reducing total cost of software development.

TABLE 3 LEVELS OF RISK

Impact Levels of Risk Low (10) Medium (50) High (100)

High (1.0)

Low 10X1.0 = 10

Medium 50 X 1.0 = 50

High 100 X 1.0 =100

Threat Likeliood

Medium (0.5)

Low 10 X 0.5 = 5

Medium 50 X 0.5 = 25

Medium 100 X 0.5 = 50

Low (0.1)

Low 10 X 0.1 = 1

Low 50 X 0.1 = 5

Low 100 X 0.1 = 10

REFERENCES
[1] [2] Budi, R. Andika, T., and Maman, S (2004). Security Evaluation Checklist. PT INDO CISC. Arlene, M (2007). The Evolution of Software Estimating. PRICE Systems. Sanjay, R., and Ashutosh, S (2009). Application security code analysis: a step towards software assurance. International Journal of Information and Computer Security. Volume (3.1), p86. Dejan Baca. Identifying Security Relevant Warnings from Static Code Analysis Tools through Code Tainting. 2010 International Conference on Availability, Reliability and Security. 15-18 Feb.2010. Krakow: IEEE. 2010. 386-390 Ashish, A. Steven, F., and Rahul, T (2008). Estimating Benefits from Investing in Secure Software Development. Carnegie Mellon University. Dejan, B. Kai, P. Bengt, C., and Lars, L. Static Code Analysis to Detect Software Security Vulnerabilities - Does Experience Matter? 2009 International Conference on Availability, Reliability and Security. 16-19 March.2009. Fukuoka: IEEE. 2009. 804-810. National Institute of Standards and Technology. Risk Management Guide for Information Technology Systems. Washington, SP 800-30.2002. National Institute of Standards and Technology. Guide for Applying the Risk Management Framework to Federal Information Systems. Washington, SP 800-37. 2010.

Table 3 shows how the level of the risk will be determined based on likelihood and impact of threat. Now in the last step, security controls and factors shall be recommended to developers based on determined risk level and other factors such as: Effectiveness of recommended option, Operational impact, Organizational policy, Safety and reliability, and Legislation and regulation. TABLE 4 RISK SCALE & NECESSARY ACTIONS
Risk Level High Necessary Actions and Risk Description Using whitelist mechanism for input validation Encryption of sensitive data before storing in database Using automated/scheduled mechanism for installing the patches and updates Applying mechanism of content checking for error messages Applying security checks in both client and server side

[3]

[4]

[5]

[6]

[7]

[8]

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 12, DECEMBER 2012, ISSN (Online) 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

[9]

JAN, J. UMLSEC: EXTENDING UML FOR SECURE SYSTEMS DEVELOPMENT. LECTURE NOTES IN COMPUTER SCIENCE. 2002. 2460: 412-425

[10] JURJENS, J. LEHRHUBER, M. AND WIMMEL, G. MODEL-BASED

DESIGN AND ANALYSIS OF PERMISSION-BASED SECURITY.

ENGINEERING OF COMPLEX COMPUTER SYSTEMS, 2005. ICECCS 2005. PROCEEDINGS. 10TH IEEE INTERNATIONAL CONFERENCE. JUNE 16-20, 2005. MUNCHEN, GARCHING: IEEE. 2005. 224-233 [11] NANCY, R. TED, S. SECURITY
QUALITY REQUIREMENTS ENGINEERING

Saman Hedayatpour got the Bachelors degree in field of Software Engineering at the Jahad Daneshgahi Institute of Higher Education Iran 2008, Master degree in field of Information Security at the University Technology Malaysia 2012, and currently is a Doctor of Philosophy student at the University Technology Malaysia; he has number of conference papers and journal articles in fields of Software engineering and Computer Security; currently he is working on the research title of Secure Software Development under supervision of Dr. Suriayati Chuprat at the Advanced Informations School, University Technology Malaysia. Dr.Suriayati Chuprat is senior lecturer at University Technology Malaysia, Advanced Informatics School and also the Head of Department of Software Engineering.

(SQUARE)

METHODOLOGY.

ACM

SIGSOFT

SOFTWARE ENGINEERING NOTES.2005.30(4):1-7

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617