Assessment of Potential SQL Injection Threat into the Design Phase

7/29/2019 Assessment of Potential SQL Injection Threat into the Design Phase

1/4

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 ofdollars annually because of finding different securitybreaches and bugs in their software products where

such a problem may turn the company into the biggerdisaster with losing public confidence and market. The

Computer Emergency Response Team (CERT) that trackssecurity incidents caused by malicious software, reports2099% increasing in the number of these types of inci-dents from 1998 to 2002.Because of this rapid increasing in number of securityincidents; developing software products that only re-sponse the expected functionalities, is not the only con-cern of today software developers but also there must besufficient proofs to ensure that developed software pro-tects users and system assets from security threatsbreaches [1, 2, and 3].In facing with security threats, static and dynamic analy-

sis tools address the main security features that have beenused for the years but unfortunately there is still a bigproblem in deal with these tools where the COCOMOdevelopers confirm that the cost of fixing all type errors infailed software is about 20 times more than the cost offixing errors at the design level. It means, even if the secu-

rity bugs and holes be detected by static and dynamicanalysis tools before final products become to the market,the financial benefits of company already decreased be-cause of huge fixing cost [4, 5, and 6]. In this paper wepresent a new method of security analysis base on known

properties and behaviors of SQL injection attack to en-hance the security resistance of the developing softwareagainst this attack.In practice, there is a main difference between normalapplication testing and application testing for securitypoint of view; in conventional application testing, themain focus is on functionality and performance but secu-rity view of application testing adds another approachthat concerns about the errors which may happen unin-tentionally by normal users or intentionally by attackerswho try to exploit the softwares vulnerabilities and con-sequently violate Confidentiality, Integrity or Availability

of the software system [1].By evaluating system conditions, security controls, andother relevant factors, this security analysis helps devel-oper to improve the resistance of the developing softwareagainst SQL injection in the early phase of software de-sign and before the starting of implementation and cod-ing phase. The rest of this paper is organized as the fol-lowing sections: Section II introduces similar workswhere the process of conducting security analysis is pre-sented in Section III, and finally we conclude this work inSection IV.

S. Hedayatpour is with the Advanced Informations School, University

Technology Malaysia, International Campus, Jalan Semarak, Kuala Lum-

pur, 54100, Malaysia.

S. Chuprat is with the Advanced Informations School, University Technol-

ogy Malaysia, International Campus, Jalan Semarak, Kuala Lumpur,

54100, Malaysia.

S

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 12, DECEMBER 2012, ISSN (Online) 2151-9617

https://sites.google.com/site/journalofcomputing

WWW.JOURNALOFCOMPUTING.ORG 1

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


2/4

2 SIMILAR WORKS

The NIST checklists of 800-30 with title of Risk Manage-ment Guide for Information Technology Systems [7] and800-37 with title of Guide for Applying the Risk Man-agement Framework toFederal Information Systems [8]refer to two famous security checklists that the main con-

cepts of our security analysis come from these two.The Unified Modeling Language Security (UMLsec) thatwas introduced in 2002 by Jan Jurjens [9] and Model-Based Design and Analysis of Permission-Based Securitythat also was introduced by Jan Jurjens in 2005 [10] alongwith Security Quality Requirements Engineering Meth-odology (SQUARE) which was introduced in 2005 byNancy R. Mead, Eric D. Hough, and Theodore R. Stehney[11] refer to the other similar works to our security analy-sis.

4 PROPOSED SECURITY ANALYSIS

The entire process of conducting SQL injection-based se-curity analysis is divided into the several steps that eachof them includes operations and actions. Establishingthreats identification table refers the first step in thisprocess where a database must be established with con-tent of SQL injection signatures, bugs, actions and beha-viors that attacker may be used in this attack. This infor-mation may be gathered from security agencies, securityviolation reports, incident reports, and media.Since the content of this database (List of potentialsecurity threats by source of environmental, natural, andhuman) must be asked from the system owners and

stakeholders; these contents shall be prepared in form ofsecurity questions as is shown in table 1(as the content ofthreats identification table will be used to finding poten-tial bugs and threats, it must be prepared by security ex-perts who have practical experiences in deal with SQLinjection and ask them to prepare this table as compre-hensive as possible).

TABLE 1EXAMPLE OF THREATS IDENTIFICATION TABLE

No. Security Questions

1 Will the target website or application store high value data (busi-

ness, political, social, e tc)?

2 Is there any automatic or scheduled mechanism for installing the

patches and updates?

3 Is there white or black list input validation mechanism? If yes it

apply on which of them:

- Input from users?

- Parameters from URL?

- Values from cookie?

4 Is there any applying mechanism to strip the error messagesfrom

the information that may be used by attackers?

5 The version of databases that allows batch execution is used (such as

SQL Server 2000)?

6 If you are using hosted servers or if you are using outsourced tech-nical resources, is there any third party review of your site security?

7 If any type of input validation is performing, whether consider all

potentially relevant properties such as: including length, type of in-

put, the full range of acceptable values, missing or extra inputs, and

syntax?

8 The critical information such as user names and password are stored

in clear text or encrypted and hashed?

9 Whether using the databases such as MS SQL, which allows shell

command execution?

10 Whether security checks are applied in both client and server side?

After preparing the threats identification table and in thesecond step, general agreement must be set with systemowners and technical staffs. In this step any needed in-formation for answering security questions of threatsidentification table must be found. Various informationsuch as the levels of access control mechanism, levels ofconfidentiality for different data types, programminglanguage, level of trust for different users, communica-

tion channels and their secrecy, interfaces, target database and its version, and many other critical informationthat must be gathered to specifically answer the technicalquestions of the threats identification table.When the answer of all security questions is extracted, weshall move to the next step that is VulnerabilityIdentification which uses security tests, audit results, se-curity requirements checklist, vulnerability advisories,and security standards to find the potential vulnerabilitiesin associated with identified threats. Table 2 illustrates thecorrelation between an identified threats and correspond-ing vulnerabilities.

TABLE 2EXAMPLE OF VULNERABILITY/THREAT PAIR

Vulnerability Threat Action

Storing critical information such as

usernames and password in form of

plaintext and without any encryption

mechanism

Dialing into the network of compa-

ny and accessing proprietary info

Using old and risky versions of soft-

ware (without installing updates and

patches)

Taking advantage from the found

and known bu gs in certain old ver-

sions for inject the SQL query

Lack of any mechanism for checking

contents of error messages

Inserting unexpected input to re-

ceive 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

Inserting SQL query and command

instead of normal input

MS SQL allows shell command ex-

ecution

Inserting shell command instead of

normal input and e xecuting shellcommand by attacker






3/4

At the fourth step, the likelihood of launching SQL will bedeterminated based on the information that is found fromprevious steps such as threat capability, motivation,nature of the vulnerability, and existence andeffectiveness of current controls. As the output of this stepand according to the identified security conditions, thelikelihood of launching successful SQL injection on thedeveloping software will be estimated in one of the rateof Low, Medium or High.After finding the likelihood of attack, the impact oflaunching successful SQL injection on the software mustbe estimated (impact described in terms of loss of integ-rity, confidentiality, availability) where it also rated inone of the levels of Low, Medium or High. When thelikelihood and impact of the threat be determined, thelevel of the risk may be calculated according to thefollowing relation:

Risk Level = Threat Impact * Threat Likelihood

(1)

TABLE 3LEVELS OF RISK

Levels of Risk

Impact

Low (10) Medium (50) High (100)

ThreatLikeliood

High (1.0) Low

10X1.0 =10

Medium

50 X 1.0 =50

High

100 X 1.0 =100

Medium(0.5)

Low10 X 0.5=5

Medium50 X 0.5 =25

Medium100 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

Table 3 shows how the level of the risk will be deter-mined based on likelihood and impact of threat. Now inthe last step, security controls and factors shall be rec-ommended to developers based on determined risk level

and other factors such as: Effectiveness of recommendedoption, Operational impact, Organizational policy, Safetyand reliability, and Legislation and regulation.

TABLE 4RISKSCALE &NECESSARY ACTIONS

Risk Level Necessary Actions and Risk Description

High 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

Medium Using whitelist mechanism for input validation

Using automated/scheduled mechanism for installing

the patches and updates

Applying mechanism of content checking for error mes-

sages

Low Using an input validation mechanism No using of risky software ve rsions

Table 4 illustrates an example of security controls andfactors which may be recommended to developers basedon determined risk level and other related factors to SQLinjection. These recommendations try to eliminate or atleast mitigate the risk.

4 CONCUSION

Since statistical reports proves that the rapid increasing inthe number of security incidents is caused by malicioussoftware and software bugs, our security analysis pro-vides valuable security information to developers andhelp them to improve the resistance of developing soft-ware against losing Confidentiality, Integrity, and Avail-ability caused by a successful SQL injection. In terms ofbest protection, this security analysis works in Synchroni-zation with static analysis tools to enhance the level ofquality into the final codes and bring higher level on con-fidence for users. As this research presents a new methodof security analyze that works base on known propertiesand behaviors of SQL injection attack and without asking

for a security expert team, it will bring commercial benefitfor software companies by reducing total cost of softwaredevelopment.

REFERENCES

[1] Budi, R. Andika, T., and Maman, S (2004). Security Evaluation

Checklist. PT INDO CISC.

[2] Arlene, M (2007). The Evolution of Software Estimating. PRICE

Systems.

[3] 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.

[4] Dejan Baca. Identifying Security Relevant Warnings from StaticCode Analysis Tools through Code Tainting. 2010 International

Conference on Availability, Reliability and Security. 15-18 Feb.2010.

Krakow: IEEE. 2010. 386-390

[5] Ashish, A. Steven, F., and Rahul, T (2008). Estimating Benefits

from Investing in Secure Software Development. Carnegie Mel-

lon University.

[6] Dejan, B. Kai, P. Bengt, C., and Lars, L. Static Code Analysis to

Detect Software Security Vulnerabilities - Does Experience Mat-

ter? 2009 International Conference on Availability, Reliability and

Security. 16-19 March.2009. Fukuoka: IEEE. 2009. 804-810.

[7] National Institute of Standards and Technology. Risk Manage-

ment Guide for Information Technology Systems. Washington, SP

800-30.2002.

[8] National Institute of Standards and Technology. Guide for Apply-

ing the Risk Management Framework to Federal Information Sys-

tems. Washington, SP 800-37. 2010.






4/4

[9] J AN, J. UMLSEC: EXTENDING UML FOR SECURE SYSTEMS

DEVELOPMENT. LECTURE NOTES IN COMPUTER SCIENCE. 2002.

2460: 412-425

[10] J URJENS, 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 I NTERNATIONAL CONFERENCE.

JUNE 16-20, 2005. MUNCHEN, GARCHING: IEEE. 2005. 224-233

[11] N ANCY, R. TED, S. SECURITY QUALITY REQUIREMENTS

ENGINEERING (SQUARE) METHODOLOGY. ACM SIGSOFT

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

Saman Hedayatpourgot the Bachelors degree in field of SoftwareEngineering at the J ahad Daneshgahi Institute of Higher EducationIran 2008, Master degree in field of Information Security at the Uni-versity Technology Malaysia 2012, and currently is a Doctor of Phi-losophy student at the University Technology Malaysia; he has num-ber of conference papers and journal articles in fields of Softwareengineering and Computer Security; currently he is working on theresearch title of Secure Software Development under supervision ofDr. Suriayati Chupratat the Advanced Informations School, Universi-ty Technology Malaysia.

Dr.Suriayati Chuprat is senior lecturer at University TechnologyMalaysia, Advanced Informatics School and also the Head of De-partment of Software Engineering.





Assessment of Potential SQL Injection Threat into the Design Phase

Documents

Transcript of Assessment of Potential SQL Injection Threat into the Design Phase