Ch. 1 Introduction - INFLIBNETshodhganga.inflibnet.ac.in/bitstream/10603/24846/2/ch. 1... · A database management system ... communication of having participation in part of communication

Chapter-1 Introduction

1

CHAPTER - 1

INTRODUCTION

1.1 Background

1.1.1 Web Applications A web application is an application that is accessed over a network such as

the Internet or an intranet. The term may also mean a computer software application

that is coded in a browser-supported language (such as JavaScript, combined with a

browser-rendered markup language like HTML) and reliant on a common web browser

to render the application executable.

“A web application is any application that uses a web browser as a client. The

application can be as simple as a message board or a guest sign-in book on a website, or

as complex as a word processor or a spreadsheet [1].”

Web applications are popular due to the ubiquity of web browsers, and the convenience

of using a web browser as a client, sometimes called a thin client. The ability to update

and maintain web applications without distributing and installing software on

potentially thousands of client computers is a key reason for their popularity, as is the

inherent support for cross-platform compatibility. Common web applications

include webmail, online retail sales, online, wikis and many other functions [2].

1.1.1.1 What is a Client?

The client is used in client-server environment to refer to the program the person uses to

run the application. A client-server environment is one in which multiple computers

share information such as entering information into a database. The client is the

application used to enter the information, and the server is the application used to store

the information [1].

1.1.1.2 What are the Benefits of a Web Application?

A web application relieves the developer of the responsibility of building a client for a

specific type of computer or a specific operating system. Since the client runs in a web

browser, the user could be using an IBM-compatible or a Mac. They can be running


2

Windows XP or Windows Vista. They can even be using Internet Explorer or Firefox,

though some applications require a specific web browser.

Web applications commonly use a combination of server-side script (ASP, PHP, etc)

and client-side script (HTML, Javascript, etc.) to develop the application. The client-

side script deals with the presentation of the information while the server-side script

deals with all the hard stuff like storing and retrieving the information.

1.1.1.3 How Long Have Web Applications Been Around?

Web Applications have been around since before the web gained mainstream

popularity. For example, Larry Wall developed Perl, a popular server-side scripting

language, in 1987. That was seven years before the Internet really started gaining

popularity outside of academic and technology circles.

The first mainstream web applications were relatively simple, but the late 90's saw a

push toward more complex web applications. Nowadays, millions of Americans use a

web application to file their income taxes on the web.

1.1.1.4 What is the Future of Web Applications?

Most web applications are based on the client-server architecture where the client enters

information while the server stores and retrieves information. Internet mail is an

example of this, with companies like Yahoo and MSN offering web-based email clients.

The new push for web applications is crossing the line into those applications that do

not normally need a server to store the information. Your word processor, for example,

stores documents on your computer, and doesn't need a server.

Web applications can provide the same functionality and gain the benefit of working

across multiple platforms. For example, a web application can act as a word processor,

storing information and allowing you to download the document onto your personal

hard drive [1].

If you have seen the new Gmail or Yahoo mail clients, you have seen how sophisticated

web applications have become in the past few years. Much of that sophistication is

because of AJAX, which is a programming model for creating more responsive web

applications. Google Apps, Microsoft Office Live, and WebEx, WebOffice are

examples of the newest generation of web applications.


3

1.1.2 Database Management System

A database management system (DBMS) is a software package with computer

programs that control the creation, maintenance, and the use of a database. It allows

organizations to conveniently develop databases for various applications by database

administrators (DBAs) and other specialists. A database is an integrated collection of

data records, files, and other database objects. A DBMS allows different user

application programs to concurrently access the same database. DBMSs may use a

variety of database models, such as the relational model or object model, to

conveniently describe and support applications. It typically supports query languages,

which are in fact high-level programming languages, dedicated database languages that

considerably simplify writing database application programs. Database languages also

simplify the database organization as well as retrieving and presenting information from

it. A DBMS provides facilities for controlling data access, enforcing data integrity,

managing concurrency control, recovering the database after failures and restoring it

from backup files, as well as maintaining database security.

A DBMS is a set of software programs that controls the system organization, storage,

management, and retrieval of data in a database. DBMSs are categorized according to

their data structures or types. The DBMS accepts requests for data from an application

program and instructs the operating system to transfer the appropriate data.

The queries and responses must be submitted and received according to a format that

conforms to one or more applicable protocols. When a DBMS is used, information

systems can be changed more easily as the organization's information requirements

change. New categories of data can be added to the database without disruption to the

existing system.

Database servers are dedicated computers that hold the actual databases and run only

the DBMS and related software. Database servers are usually multiprocessor computers,

with generous memory and RAID disk arrays used for stable storage. Hardware

database accelerators, connected to one or more servers via a high-speed channel, are

also used in large volume transaction processing environments. DBMSs are found at the

heart of most database applications. DBMSs may be built around a


4

custom multitasking kernel with built-in networking support, but modern DBMS

typically rely on a standard operating system to provide these functions [3].

1.1.3 Information Security

Information security is the process of protecting information. It protects its availability,

privacy and integrity. Access to stored information on computer databases has increased

greatly. More companies store business and individual information on computer than

ever before. Much of the information stored is highly confidential and not for public

viewing [4].

Information security means protecting information and information systems from

unauthorized access, use, disclosure, disruption, modification, perusal, inspection,

recording or destruction.

The terms information security, computer security and information assurance are

frequently incorrectly used interchangeably. These fields are interrelated often and

share the common goals of protecting the confidentiality, integrity and availability of

information; however, there are some subtle differences between them.

These differences lie primarily in the approach to the subject, the methodologies used,

and the areas of concentration. Information security is concerned with the

confidentiality, integrity and availability of data regardless of the form the data may

take: electronic, print, or other forms [5].

Computer security can focus on ensuring the availability and correct operation of a

computer system without concern for the information stored or processed by the

computer.

Governments, military, corporations, financial institutions, hospitals, and private

businesses amass a great deal of confidential information about their employees,

customers, products, research, and financial status. Most of this information is now

collected, processed and stored on electronic computers and transmitted across

networks to other computers [4] [5].


5

Figure 1.1 Information Security

Should confidential information about a business' customers or finances or new product

line fall into the hands of a competitor, such a breach of security could lead to lost

business, law suits or even bankruptcy of the business. Protecting confidential

information is a business requirement, and in many cases also an ethical and legal

requirement.

1.1.3.1 Information Security Components:

Information security components or qualities are

A. accuracy

B. Availability

C. Authentication & identification

D. Access Control

E. Confidentiality

F. Integrity

G. Non repudiation


6

Information Systems are decomposed in three main portions: hardware, software and

communications with the purpose to identify and apply information security industry

standards, as mechanisms of protection and prevention, at three levels or layers:

physical, personal and organizational. Essentially, procedures or policies are

implemented to tell administrators, users and operators how to use products to ensure

information security within the organizations.

1.1.3.2 Principles of Security:

The main principles of security are:

A. Accuracy: -

Information is accurate when it is free from flaws and it has the value that the user

expects.

B. Availability: -

Computer resources accessible for and to authorized persons whenever required.

Resources are always available for authorized person to access the data.

A. Authentication & identification: -

Authentication of information show’s that the given information is genuine or original

rather than fabrication. Information is authenticated when it is originally created,

placed, or transferred .The data’s receiver must be able to determine its origin.

B. Access Control: -

In this principle, administrator provides controls to other who should be able to access

“what”. For example user A can only read the database, but B can read as well as

update the database.

E. Confidentiality: -

Any unauthorized person must not be able to access other’s data or other computing

assets.

F. Integrity:-

It is related with the accuracy of data. Only authorized persons are enabled to create,

edit, and delete data as per agreed terms and conditions.

G. Non repudiation: -


7

This principle does not allow the sender or a message to refute the claim of not sending

that message. It provides protection against denies by one of the entities involved in a

communication of having participation in part of communication.

1.1.3.3 Security Controls:

When Management chooses to mitigate a risk, they will do so by implementing one or

more of three different types of controls.

A. Administrative:-

Administrative controls (also known as procedural controls) consist of approved written

policies, procedures, standards and guidelines. Administrative controls form the

framework for running the business and managing people. They inform people on how

the business is to be run and how day to day operations are to be conducted. Laws and

regulations created by government bodies are also a type of administrative control

because they inform the business. Some industry sectors have policies, procedures,

standards and guidelines that must be followed – the Payment Card Industry (PCI) Data

Security Standard required by Visa and Master Card is such an example. Other

examples of administrative controls include the corporate security policy, password

policy, hiring policies, and disciplinary policies.

Administrative controls form the basis for the selection and implementation of logical

and physical controls. Logical and physical controls are manifestations of

administrative controls.

B. Logical:-

Logical controls (also called technical controls) use software and data to monitor and

control access to information and computing systems. For example: passwords,

network and host based firewalls, network intrusion detection systems, access control

lists, and data encryption are logical controls.

An important logical control that is frequently overlooked is the principle of least

privilege. The principle of least privilege requires that an individual, program or system

process is not granted any more access privileges than are necessary to perform the

task. A blatant example of the failure to adhere to the principle of least privilege is

logging into Windows as user Administrator to read Email and surf the Web. Violations


8

of this principle can also occur when an individual collects additional access privileges

over time. This happens when employees' job duties change, or they are promoted to a

new position, or they transfer to another department. The access privileges required by

their new duties are frequently added onto their already existing access privileges

which may no longer be necessary or appropriate.

C. Physical:-

Physical controls monitor and control the environment of the work place and

computing facilities. They also monitor and control access to and from such facilities.

For example: doors, locks, heating and air conditioning, smoke and fire alarms, fire

suppression systems, cameras, barricades, fencing, security guards, cable locks, etc.

Separating the network and work place into functional areas are also physical controls.

An important physical control that is frequently overlooked is the separation of duties.

Separation of duties ensures that an individual can not complete a critical task by

himself. For example: an employee who submits a request for reimbursement should

not also be able to authorize payment or print the check. An applications programmer

should not also be the server administrator or the database administrator – these roles

and responsibilities must be separated from one another [5].

1.1.3.4 Defense in Depth:

Information security must protect information throughout the life span of the

information, from the initial creation of the information on through to the final disposal

of the information. The information must be protected while in motion and while at

rest. During its lifetime, information may pass through many different information

processing systems and through many different parts of information processing

systems. There are many different ways the information and information systems can

be threatened. To fully protect the information during its lifetime, each component of

the information processing system must have its own protection mechanisms. The

building up, layering on and overlapping of security measures is called defense in

depth. The strength of any system is no greater than its weakest link. Using a defense in

depth strategy, should one defensive measure fail there are other defensive measures in

place that continue to provide protection.


9

Figure 1.2 Defenses in Depth

The three types of security controls can be used to form the basis upon which to build a

defense-in-depth strategy. With this approach, defense-in-depth can be conceptualized

as three distinct layers or planes laid one on top of the other. Additional insight into

defense-in- depth can be gained by thinking of it as forming the layers of an onion, with

data at the core of the onion, people the next outer layer of the onion, and network

security, host-based security and application security forming the outermost layers of

the onion. Both perspectives are equally valid and each provides valuable insight into

the implementation of a good defense-in-depth strategy [5].

1.1.4 Software Security

Software development is not yet a science or a rigorous discipline, and the development

process by and large is not controlled to minimize the vulnerabilities that attackers

exploit. Today, as with cancer, vulnerable software can be invaded and modified to

cause damage to previously healthy software, and infected software can replicate itself

and be carried across networks to cause damage in other systems. Like cancer, these


10

damaging processes may be invisible to the lay person even though experts recognize

that their threat is growing. And as in cancer, both preventive actions and research are

critical, the former to minimize damage today and the latter to establish a foundation of

knowledge and capabilities that will assist the cyber security professionals of tomorrow

reduce risk and minimize damage for the long term [6] [7].

1.1.4.1 Software’s Vulnerability to Attack:

The security of software is threatened at various points throughout its life cycle, both by

inadvertent and intentional choices and actions taken by “insiders”—individuals closely

affiliated with the organization that is producing, deploying, operating, or maintaining

the software, and thus trusted by that organization and by “outsiders” who have no

affiliation with the organization. The software’s security can be threatened.

A. During Its Development:-

A developer may corrupt the software intentionally or unintentionally in ways that will

compromise the software’s dependability and trustworthiness when it is operational.

B. During Its Deployment (Distribution and Installation):-

If those responsible for distributing the software fail to tamperproof the software before

shipping or uploading, or transmit it over easily intercepted communications channels,

they leave the software vulnerable to intentional or unintentional corruption. Similarly,

if the software’s installer fails to lock down the host platform, or configures the

software insecurely, the software is left vulnerable to access by attackers.

C. During Its Operation:-

Once COTS and open source software has gone operational, vulnerabilities may be

discovered and publicized; unless security patches and updates are applied and newer

supported versions (from which the root causes of vulnerabilities have been eliminated)

are adopted, such software will become increasingly vulnerable. Non-commercial

software and open source software (OSS) may also be vulnerable, especially as it may

manifest untrustworthy behaviors over time due to changes in its environment that

stress the software in ways that were not anticipated and simulated during its testing.

Any software system that runs on a network-connected platform has its vulnerabilities

exposed during its operation. The level of exposure will vary depending on whether the


11

network is public or private, Internet-connected or not, and whether the software’s

environment has been configured to minimize its exposure. But even in highly

controlled networks and “locked down” environments, the software may be threatened

by malicious insiders (users, administrators, etc.).

D. During Its Sustainment:-

If those responsible for addressing discovered vulnerabilities in released software fail to

issue patches or updates in a timely manner, or fail to seek out and eliminate the root

causes of the vulnerabilities to prevent their perpetuation in future releases of the

software, the software will become increasingly vulnerable to threats over time. Also,

the software’s maintainer may prove to be a malicious insider, and may embed

malicious code, exploitable flaws, etc., in updated versions of the code [7].

1.1.4.2 The Challenge of Building Secure Software:

External faults that threaten the software’s dependable operation are seen as a security

issue when (1) the faults result from malicious intent or (2) the faults, regardless of their

cause, make the software vulnerable to threats to its security. To be considered secure,

software must exhibit three properties:

A. Dependability:-

Dependable software executes predictably and operates correctly under all conditions,

including hostile conditions, including when the software comes under attack or runs on

a malicious host.

B. Trustworthiness:-

Trustworthy software contains few if any vulnerabilities or weaknesses that can be

intentionally exploited to subvert or sabotage the software’s dependability. In addition,

to be considered trustworthy, the software must contain no malicious logic that causes it

to behave in a malicious manner.

C. Survivability (Resilience):-

Survivable or resilient software is software that is resilient enough to (1) either resist

(i.e., protect itself against) or tolerate (i.e., continue operating dependably in spite of)

most known attacks plus as many novel attacks as possible, and (2) recover as quickly


12

as possible, and with as little damage as possible, from those attacks that it can neither

resist nor tolerate.

The objective of secure software development is to design, implement, configure, and

sustain software systems in which security is a necessary property from the beginning

of the system’s life cycle (i.e., needs and requirements definition) to its end

(retirement). Experience has taught that the most effective way to achieve secure

software is for its development life cycle processes to rigorously conform to secure

development, deployment, and sustainment principles and practices. Organizations that

have adopted a secure software development life cycle (SDLC) process have found

almost immediately upon doing so that they have begun finding many more

vulnerabilities and weaknesses in their software early enough in the SDLC that they are

able to eradicate those problems at an acceptable cost. Moreover, as such secure

practices become second nature over time, these same developers start to notice that

they seldom introduce such vulnerabilities and weaknesses into their software in the

first place [7].

1.1.4.3 Software Security Assurance:

Software Security Assurance (SSA) is the process of ensuring that software is designed

to operate at a level of security that is consistent with the potential harm that could

result from the loss, inaccuracy, alteration, unavailability, or misuse of the data and

resources that it uses, controls, and protects.

The software security assurance process begins by identifying and categorizing the

information that is to be contained in, or used by, the software. The information should

be categorized according to its sensitivity. For example, in the lowest category, the

impact of a security violation is minimal (i.e. the impact on the software owner's

mission, functions, or reputation is negligible). For a top category, however, the impact

may pose a threat to human life; may have an irreparable impact on software owner's

missions, functions, image, or reputation; or may result in the loss of significant assets

or resources.

Once the information is categorized, security requirements can be developed. The

security requirements should address access control, including network access and


13

physical access; data management and data access; environmental controls (power, air

conditioning, etc.) and off-line storage; human resource security; and audit trails and

usage records [8].

1.1.4.4 Causes Software Security Problems:

All security vulnerabilities in software are the result of security bugs, or defects, within

the software. In most cases, these defects are created by two primary causes: (1) non-

conformance, or a failure to satisfy requirements; and (2) an error or omission in the

software requirements.

A. Non-Conformance or a Failure to Satisfy Requirements:-

A non-conformance may be simple–the most common is a coding error or defect or

more complex (i.e., a subtle timing error or input validation error). The important point

about non-conformances is that verification and validation techniques are designed to

detect them and security assurance techniques are designed to prevent them.

Improvements in these methods, through a software security assurance program, can

improve the security of software.

B: Errors or Omissions in Software Requirements:-

The most serious security problems with software-based systems are those that develop

when the software requirements are incorrect, inappropriate, or incomplete for the

system situation. Unfortunately, errors or omissions in requirements are more difficult

to identify. For example, the software may perform exactly as required under normal

use, but the requirements may not correctly deal with some system state. When the

system enters this problem state, unexpected and undesirable behavior may result. This

type of problem cannot be handled within the software discipline; it results from a

failure of the system and software engineering processes which developed and allocated

the system requirements to the software [8].

1.1.4.5 Software Security Assurance Activities:

There are two basic types of Software Security Assurance activities.

A. Some focus on ensuring that information processed by an information system is

assigned a proper sensitivity category, and that the appropriate protection requirements

have been developed and met in the system.


14

B. Others focus on ensuring the control and protection of the software, as well as that of

the software support tools and data.

At a minimum, a software security assurance program should ensure that:

C. A security evaluation has been performed for the software.

D. Security requirements have been established for the software.

E. Security requirements have been established for the software development and/or

operations and maintenance (O&M) processes.

F. Each software review, or audit, includes an evaluation of the security requirements.

G. A configuration management and corrective action process is in place to provide

security for the existing software and to ensure that any proposed changes do not

inadvertently create security violations or vulnerabilities.

H. Physical security for the software is adequate [8].

1.1.4.6 Building in Security:

Improving the software development process and building better software are ways to

improve software security, by producing software with fewer defects and

vulnerabilities. A first-order approach is to identify the critical software components

that control security-related functions and pay special attention to them throughout the

development and testing process. This approach helps to focus scarce security resources

on the most critical areas.

A. Tools and Techniques:-

There are many commercial off-the-shelf (COTS) software packages that are available

to support software security assurance activities. However, before they are used, these

tools must be carefully evaluated and their effectiveness must be assured.

B. Common Weaknesses Enumeration:-

One way to improve software security is to gain a better understanding of the most

common weaknesses that can affect software security. With that in mind, there is a

current community-based program called the Common Weaknesses Enumeration

project, which is sponsored by The Mitre Corporation to identify and describe such

weaknesses. The list, which is currently in a very preliminary form, contains

descriptions of common software weaknesses, faults, and flaws.


15

C. Security Architecture or Design Analysis:-

Security architecture/design analysis verifies that the software design correctly

implements security requirements. Generally speaking, there are four basic techniques

that are used for security architecture/design analysis:

I. Logic analysis:-

Logic analysis evaluates the equations, algorithms, and control logic of the software

design.

II. Data analysis:-

Data analysis evaluates the description and intended usage of each data item used in

design of the software component. The use of interrupts and their effect on data should

receive special attention to ensure interrupt handling routines do not alter critical data

used by other routines.

III. Interface analysis:-

Interface analysis verifies the proper design of a software component's interfaces with

other components of the system, including hardware, software, and end-users.

IV. Constraint analysis:-

Constraint analysis evaluates the design of a software component against restrictions

imposed by requirements and real-world limitations. The design must be responsive to

all known or anticipated restrictions on the software component. These restrictions may

include timing, sizing, and throughput constraints, input and output data limitations,

equation and algorithm limitations, and other design limitations.

D. Secure Code Reviews, Inspections, and Walkthroughs:-

Code analysis verifies that the software source code is written correctly, implements the

desired design, and does not violate any security requirements. Generally speaking, the

techniques used in the performance of code analysis mirror those used in design

analysis.

Secure Code reviews are conducted during and at the end of the development phase to

determine whether established security requirements, security design concepts, and

security-related specifications have been satisfied. These reviews typically consist of

the presentation of material to a review group. Secure code reviews are most effective


16

when conducted by personnel who have not been directly involved in the development

of the software being reviewed.

I. Informal Reviews:-

Informal secure code reviews can be conducted on an as-needed basis. To conduct an

informal review, the developer simply selects one or more reviewer(s) and provides

and/or presents the material to be reviewed. The material may be as informal as pseudo-

code or hand-written documentation.

II. Formal Reviews:-

Formal secure code reviews are conducted at the end of the development phase for each

software component. The client of the software appoints the formal review group, who

may make or affect a "go/no-go" decision to proceed to the next step of the software

development life cycle.

III. Inspections and Walkthroughs:-

A secure code inspection or walkthrough is a detailed examination of a product on a

step-by-step or line-by-line (of source code) basis. The purpose of conducting secure

code inspections or walkthroughs is to find errors. Typically, the group that does an

inspection or walkthrough is composed of peers from development, security

engineering and quality assurance.

E. Security testing:-

Software security testing, which includes penetration testing, confirms the results of

design and code analysis, investigates software behavior, and verifies that the software

complies with security requirements. Special security testing, conducted in accordance

with a security test plan and procedures, establishes the compliance of the software with

the security requirements. Security testing focuses on locating software weaknesses and

identifying extreme or unexpected situations that could cause the software to fail in

ways that would cause a violation of security requirements. Security testing efforts are

often limited to the software requirements that are classified as "critical" security items

[8].


17

1.1.4.7 General Principles of Secure Software Development:

The following principles should guide the development of secure software, including all

decisions made in producing the artifacts at every phase of the software life cycle.

A. Minimize the Number of High-Consequence Targets:-

The software should contain as few high-consequence targets (critical and trusted

components) as possible. High-consequence targets are those that represent the greatest

potential loss if the software is compromised and therefore require the most protection

from attack. Critical and trusted components are high-consequence because of the

magnitude of impact if they are compromised. (This principle contributes to

trustworthiness and, by its implied contribution to smallness and simplicity, also to

dependability.)

B. Don’t Expose Vulnerable and High-Consequence Components:-

The critical and trusted components the software contains should not be exposed to

attack. In addition, known vulnerable components should also be protected from

exposure because they can be compromised with little attacker expertise or expenditure

of effort and resources. This principle contributes to trustworthiness.

C. Deny Attackers the Means to Compromise:-

The software should not provide the attacker with the means by which to compromise

it. Such “means” include exploitable weaknesses and vulnerabilities, dormant code,

backdoors, etc. Also, provide the ability to minimize damage, recover, and reconstitute

the software as quickly as possible following a compromising (or potentially

compromising) event to prevent greater compromise. In practical terms, this will require

building in the means to monitor, record, and react to how the software behaves and

what inputs it receives. This principle contributes to dependability, trustworthiness, and

resilience.

D. Always Assume “the Impossible” will Happen:-

Events that seem to be impossible rarely are. They are often based on an expectation

that something in a particular environment is highly unlikely to exist or to happen. If the

environment changes or the software is installed in a new environment, those events

may become quite likely. The use cases and scenarios defined for the software should


18

take the broadest possible view of what is possible. The software should be designed to

guard against both likely and unlikely events.

Developers should make an effort to recognize assumptions they are not initially

conscious of having made and should determine the extent to which the

“impossibilities” associated with those assumptions can be handled by the software.

Specifically, developers should always assume that their software will be attacked,

regardless of what environment it may operate in. This includes acknowledgement that

environment-level security measures such as access controls and firewalls, being

composed mainly of software themselves (and thus equally likely to harbor

vulnerabilities and weaknesses), can and will be breached at some point, and so cannot

be relied on as the sole means of protecting software from attack.

Developers who recognize the constant potential for their software to be attacked will

be motivated to program defensively, so that software will operate dependably not only

under “normal” conditions but under anomalous and hostile conditions as well. Related

to this principle are two additional principles about developer assumptions.

I. Never Make Blind Assumptions:-

Validate every assumption made by the software or about the software before acting on

that assumption.

II. Security Software is Not the Same as Secure Software: -

Just because software performs information security-related functions does not mean

the software itself is secure. Software that performs security functions is just as likely to

contain flaws and bugs as other software. However, because security functions are high-

consequence, the compromise or intentional failure of such software has a significantly

higher potential impact than the compromise or failure of other software [7].

1.1.4.8 What the Software Practitioner Needs to Know:

The main characteristics that discriminate the developer, tester, integrator, and sustainer

of secure software from those of non-secure software are awareness, intention, and

caution. A software professional who cares about security and acts on that awareness

will recognize that software vulnerabilities and weaknesses can originate at any point in

the software’s conception or implementation, from inadequate requirements, to poor


19

design and implementation choices, to inadvertent coding errors or configuration

mistakes.

The security-aware software professional knows that the only way these problems can

be avoided is through well-informed and intentional effort: requirements analysts must

understand how to translate the need for software to be secure into actionable

requirements, designers must recognize choices that conflict with secure design

principles, and programmers must follow secure coding practices and be cautious about

avoiding coding errors and finding and removing the bugs they were unable to avoid.

Software integrators must recognize and strive to reduce the security risk associated

with vulnerable components (whether custom-built, COTS, or open source), and must

understand the ways in which those modules and components can be integrated to

minimize the exposure of any vulnerabilities that cannot be eliminated.

The main reason for adding security practices throughout the SDLC is to establish a

software life cycle process that codifies both caution and intention.

Creating a secure development community using collaboration technologies and a well-

integrated development environment promotes a continuous process of improvement

and a focus on secure development life cycle principles and practices that will result in

the ongoing production of more dependable, trustworthy, survivable software systems

[7].

1.1.4.9 Integrating Security into the Software Life Cycle:

Security enhancement of the SDLC process mainly involves the adaptation or

augmentation of existing SDLC activities, practices, and checkpoints, and in a few

instances, it may also entail the addition of new activities, practices, or checkpoints. In a

very few instances, it may also require the elimination or wholesale replacement of

certain activities or practices that are known to obstruct the ability to produce secure

software [7].

The key elements of a secure software life cycle process are:

A. Security criteria in all software life cycle checkpoints (both at the entry of a life

cycle phase and at its exit).

B. Adherence to secure software principles and practices.


20

C. Adequate requirements, architecture, and design.

D. Secure coding practices.

E. Secure software integration/assembly practices.

F. Security testing practices that focus on verifying the dependability, trustworthiness,

and sustainability of the software being tested.

E. Secure distribution and deployment practices and mechanisms.

F. Secure sustainment practices.

G. Supportive tools.

H. Secure software configuration management systems and processes.

I. Security-knowledgeable software professionals.

J. Security-aware project management.

K. Upper management commitment to production of secure software.

Organizations can insert secure development practices into their software life cycle

process either by adopting a codified secure software development methodology and the

SDLC process content area of Build Security In, or through the evolutionary security

enhancement of their current practices. These, as well as the other Best Practices,

Knowledge, and Tools articles on Build Security In support organizations in making

progress toward achieving these goals. Those responsible for ensuring that software and

systems meet their security requirements throughout the development life cycle should

review, select, and tailor BSI guidance as part of normal project management

activities. Additional Resources on BSI and the references below provide additional,

experience-based practices and lessons learned that development organizations need to

consider.

1.1.5 Web Application Security

Web application security is a branch of information security that deals specifically with

security of websites and web applications. At a high level, Web application security

draws on the principles of application security but applies them specifically to Internet

and Web systems. Typically web applications are developed using programming

languages such as PHP, Java EE, Java, Python, Ruby, ASP.NET, C#, VB.NET or

Classic ASP.


21

With the emergence of Web 2.0, increased information sharing through social

networking and increasing business adoption of the Web as a means of doing business

and delivering service, websites are often attacked directly. Hackers either seek to

compromise the corporate network or the end-users accessing the website by subjecting

them to drive-by downloading. As a result, industry is paying increased attention to the

security of the web applications themselves in addition to the security of the underlying

computer network and operating systems.

The majority of web application attacks occur through cross-site scripting (XSS) and

SQL injection attacks which typically result from flawed coding, and failure to sanitize

input to and output from the web application [9].

1.1.6 Database Security

Database security entails allowing or disallowing user actions on the database and the

objects within it. Oracle uses schemas and security domains to control access to data

and to restrict the use of various database resources.

Oracle provides comprehensive Discretionary Access Control. Discretionary Access

Control regulates all user access to named objects through privileges. A privilege is

permission to access a named object in a prescribed manner; for example, permission to

query a table. Privileges are granted to users at the discretion of other users [10].

1.1.6.1 Database Users and Schemas:

Each Oracle database has a list of user names. To access a database, a user must use a

database application and attempt a connection with a valid user name of the database.

Each user name has an associated password to prevent unauthorized use.

1.1.6.2 Security Domain:

Each user has a security domain—a set of properties that determine such things as:

A. The actions (privileges and roles) available to the user.

B. The tablespace quotas (available disk space) for the user.

C. The system resource limits (for example, CPU processing time) for the user.

1.1.6.3 Privileges:

A privilege is a right to run a particular type of SQL statement. Some examples of

privileges include the right to:


22

A. Connect to the database (create a session).

B. Create a table in your schema.

C. Select rows from someone else's table.

D. Run someone else's stored procedure.

1.1.6.4 Storage Settings and Quotas:

You can direct and limit the use of disk space allocated to the database for each user,

including default and temporary tablespaces and tablespace quotas.

A. Default Tablespace:-

Each user is associated with a default tablespace. When a user creates a table, index, or

cluster and no tablespace is specified to physically contain the schema object, the user's

default tablespace is used if the user has the privilege to create the schema object and a

quota in the specified default tablespace. The default tablespace provides Oracle with

information to direct space use in situations where schema object's location is not

specified [10].

B. Temporary Tablespace:-

Each user has a temporary tablespace. When a user runs a SQL statement that requires

the creation of temporary segments (such as the creation of an index), the user's

temporary tablespace is used. By directing all users' temporary segments to a separate

tablespace, the temporary tablespace can reduce input/output contention among

temporary segments and other types of segments.

C. Tablespace Quotas:

Oracle can limit the collective amount of disk space available to the objects in a

schema. Quotas (space limits) can be set for each tablespace available to a user. This

permits selective control over the amount of disk space that can be consumed by the

objects of specific schemas.

D. Profiles and Resource Limits:-

Each user is assigned a profile that specifies limitations on several system resources

available to the user, including the following [10]:

I. Number of concurrent sessions the user can establish.


23

II. CPU processing time available for the user's session and a single call to Oracle made

by a SQL statement.

III. Amount of logical I/O available for the user's session and a single call to Oracle

made by a SQL statement.

IV. Amount of idle time available for the user's session.

V. Amount of connect time available for the user's session.

VI. Password restrictions:

• Account locking after multiple unsuccessful login attempts

• Password expiration and grace period

• Password reuse and complexity restrictions

1.1.7 SQL Injection Attacks (SQLIAs)

A SQL injection is often used to attack the security of a website by inputting SQL

statements in a web form to get a badly designed website to dump the database content

to the attacker. SQL injection is a code injection technique that exploits a security

vulnerability in a website's software. The vulnerability happens when user input is

either incorrectly filtered for string literal escape characters embedded in SQL

statements or user input is not strongly typed and unexpectedly executed. SQL

commands are thus injected from the web form into the database of an application (like

queries) to change the database content or dump the database information like credit

card or passwords to the attacker. SQL injection is mostly known as an attack vector for

websites but can be used to attack any type of SQL database [11] [12] [13] [14] [15].

How to Perform SQL Injection Attacks?

A common way of validating users in an application is to by checking if the user and

password combination exists in the users table. The following query will bring back one

record if there is one row where the login = 'abc' and the password = 'tcy12':

SELECT * FROM users WHERE login = 'abc' AND password = 'tcy12'

To code this, a common practice among developers is to concatenate a string with the

SQL command and then execute it to see if it returns something different to null. An

Active Server Page code where the SQL statement gets concatenated might look like:


24

var sql = "SELECT * FROM users WHERE login = '" + formusr + "' AND password =

'" + formpwd + "'";

SQL Injection occurs when an attacker is able to insert a series of SQL statements into a

'query' by manipulating data input.

If an attacker inserts: ' or 1=1 -- into the formusr field he will change the normal

execution of the query [16, 17].

(Variations)

admin’–

‘ or 0=0 –

” or 0=0 –

or 0=0 –

‘ or 0=0 #

” or 0=0 #

or 0=0 #

‘ or ‘x’='x

” or “x”=”x

‘) or (’x'=’x

1'or'1'='1

‘ or 1=1–

” or 1=1–

" or 1=1--

or 1=1--

' or 1=1--

or 1=1–

‘ or a=a–

” or “a”=”a

‘) or (’a'=’a

' or 'a'='a

" or "a"="a

“) or (”a”=”a


25

hi” or “a”=”a

hi” or 1=1 –

hi’ or 1=1 –

hi’ or ‘a’='a

hi’) or (’a'=’a

hi”) or (”a”=”a

By inserting a single quote the username string is closed and the final concatenated

string would end up interpreting or 1=1 as part of the command. The -- (double dash) is

used to comment everything after the or 1=1 and avoid a wrong syntax error. This could

also have been achieved by inserting the following command:

' or '1'='1

By injecting any of the two commands discussed, an attacker would get logged in as the

first user in the table. This happens because the WHERE clause ends up validating that

the username = ' ' (nothing) OR 1=1 (OR '1'='1' in the second statement) The first

conditional is False but the second one is True. By using OR the whole condition is

True and therefore all rows from table users are returned. All rows is not null therefore

the login condition is met.

The single quote character closes the string field and therefore allows all of the

following text to be interpreted as SQL commands.

To prevent this, a lot of the SQL Injection quick solutions found on the Internet suggest

escaping the single quote with a double quote. This is only a half remedy though

because there are always numeric fields or dates within forms or parameters that will

remain vulnerable. With a similar syntax a numeric login would not use single quotes

because in SQL you only need quotes for strings. This PHP / MySQL code example

concatenates a query that uses no single quotes as part of the syntax.

Injecting into a numeric field is very similar. The main difference with string injection

is that in numeric injection the first number is taken as the complete parameter (no need

to close it with a single quote) and all the text after that number will be considered as

part of the command.


26

In this case the # (number sign) is used instead of the -- (double dash) because we are

injecting into a MySQL database.

Symbol Usage in SQL99 complaint DBs:

+ Addition operator; also concatenation operator; when used in an URL it becomes a

white space)

|| Concatenation operator in Oracle and Postgres

- Subtraction operator; also a range indicator in CHECK constraints

= Equality operator

<> != Inequality operators

>< Greater-than and Less-than operators

( ) Expression or hierarchy delimiter

% Wildcard attribute indicator

, List item separator

@, @@ Local and Global variable indicators

. Identifier qualifier separator

‘’ “” Character string indicators

“” Quoted identifier indicators

-- Single-line comment delimiter

# Single-line comment delimiter in MySQL or date delimiter in MS Access

/*…*/ Begin and End multiline comment delimiter

1.2 Problem

The rapid growth of the Internet has created many services which have become an

integral part of our daily life. Web applications can be accessed over the Internet by

using any web browser that runs on any operating system and architecture. They have

become ubiquitous due to the convenience, flexibility, availability, and interoperability

that they provide [18]. Web applications are used for making reservations, paying bills,

and shopping online. They are vulnerable to a variety of new security threats. SQLIAs

are one of the most significant of such threats [19, 20, 21]. The rapid growth of SQLIAs

pose immense security risks as they give attackers unrestricted access to the databases

that lie under web applications.


27

This problem has been described by many researchers, security professionals and

hackers, and the information is widely spread on the Internet. Many security researchers

and security professionals have done attempts to stop SQL injection threats and their

countermeasures built-in earlier work that covers broader aspects of computer security,

including database security and the software development process itself. In addition, the

countermeasures constitute new solutions regarding application layer loopholes in

general and SQL injection threats [22, 23, 24, 25, 26, 27, 28, 29, 30, 31].

It seems to be a somewhat common assumption among writers to think that protecting

web applications from SQL injection is an easy task, so long as you have an

understanding of the SQL injection threat [32, 33]. Despite, researchers, companies,

security professionals and hackers continue to announce that SQL injection

vulnerabilities are inherent in web applications [34, 35, 36]. This is clearly indicated

that there still exist a lack of awareness, knowledge and respect of SQL injection attacks

inherent in web applications among security professionals and software developers.

One reason might be that software development companies and third party vendors do

not take a structured security approach when developing web applications. Another

reason is that software developers compete in introducing software to the market.

For my research, I thought that the area of SQL injection has not been properly

surveyed and that the countermeasures and prevention techniques proposed has not

always been systematically composed. I believe that proposed prevention techniques

may contain drawbacks or weaknesses. Therefore, they can not adequately cope with

SQL injection.

1.3 Purpose

My aim is to study a depth literature survey on SQL Injection Attacks SQLIAs and

capture as many aspects of the area as we can find. In addition, a potential coalesce

model will be developed against SQL injection and existing attack methods,

countermeasures and prevention techniques will be compiled.

1.4 Scope

Security standards attempt to assure a high level of security in systems by defining

security requirements that can be used for both development of computer based


28

products and for security validation assessments [37, 38]. These standards are therefore

meant for use by quality managers and developers as well as customers. In addition

with, development disciplines viz. Software Engineering involve best practices of

software development and cover areas such as process improvement, software

development processes and activities. By following this structured approach in software

development, programs will be more predictable and have higher quality and security

[39].

These standards and disciplines are important when trying to achieve a higher degree of

quality and security in software products, including web applications. My rest focus

mainly on technical aspects of a demarcated security problem and its existing

prevention techniques, and we consider therefore security standards, policies and

development disciplines to be overall issues concerning a software development

process.

1.5 Related Work

Abdulkader A. Alfantookh [2004] proposed an automated universal server level

solution called AUSELSQI. The solution is shown to be universal for any type of web

server and is applied automatically to all existing and future web applications residing

on a web server. Our proposed solution depends on examining the user input before

processing it by the web server and hence before executing any code on the server. This

prevents suspicious data form being delivered to the server. Also, it guarantees the

prevention of the SQL injection attack even if the code was changed seconds before the

request is submitted [40].

Tuong, Salvatore et al. [2005] used precise tainting of data. This paper focused on

precisely tracking taintedness within data values using program language semantics and

using context dependent checking. To prevent SQL injection attacks, they tokenize

query strings and preserve taint making. To check for attack they check if operator

symbol is marked as tainted or if identifier is tainted and keyword like UNION, DROP,

WHERE, OR, AND etc. [41].

Su and Wassermann [2006] worked on a formal definition of SQL injection attacks. In

their definition, SQL injection occurs when the intended syntactic structure of SQL


29

queries is changed by tainted input. To be able to check whether this policy is violated

by a program, they track tainted input dynamically by enclosing it within randomly

generated makers. When the program issues an SQL query, the markers indicate the

points of the query that contain potentially malicious values [42].

Cova, Balzarotti et al. [2007] proposed an anomaly based approach has for the detection

of volition of web application. They use “Swaddler” for the analysis of the internal state

of web applications and find the relationship between critical points and internal state.

By doing this, the Swaddler is able to identify attacks that attempt to bring violation of

the intended workflow of a web application [43].

Mehdi Kiani, Andrew Clark and George Mohay [2008] described an anomaly based

approach which utilizes the character distribution of certain sections of HTTP requests

to detect previously unseen SQL injection attacks. Our approach requires no user

interaction, and no modification of, or access to, either the backend database or the

source code of the web application itself. Our practical results suggest that the model

proposed in this paper is superior to existing models at detecting SQL injection attacks.

We also evaluate the effectiveness of our model at detecting different types of SQL

injection attacks [44].

R. Ezumalai, G. A [2009] used a signature based technique for the protection of SQL

Injection Attacks. In this technique, they used three modules to detect security issues. A

monitoring module which takes input from web application and sent to analysis module.

An analysis module which finds out the hotspots from application, it uses Hirschberg

algorithm. Hirschberg algorithm is a string comparison algorithm which works on

divide and conquer rule. It stores all the keywords in the specifications module [45].

Sushila Madan and Supriya Madan [2010] The aim of this research paper is to study

and analyze the various International Standards like ISO-27002, OWASP, COBIT,

PCI/DSS and depict the extent of coverage of countermeasures which focus on security

of web applications from the perspective of preventing web applications attacks

predominantly from Code Injections attacks [46].

B. Indrani & E. Ramaraj [2011] presented a new technique to protect web applications

against SQL injection. SQL-Injection Attacks are a class of attacks that many of these


30

systems are highly vulnerable to, and there is no known fool-proof defense against such

attacks. In this paper, we propose “X- Log Authentication Technique” to prevent SQL

Injection Attacks the deployment of this technique is by appending the vulnerability

Guard and X-Log Authentication as well as Stored Procedure of application scripts

additionally allowing seamless integration with currently-deployed systems [47].

1.6 Methodology

My research is based on vast literature study on SQL injection, as aforesaid in section

1.3. I attempt to gain the large information about SQLIAs. Along the way, I intend to

develop a uniform terminology of SQL injection and capture its characteristics, attack

methods, countermeasures and existing prevention techniques. The literature study also

covers conditions under which SQL injection works and within which context it

operates. Therefore, web applications, relational databases and SQL will also be

examined, though from a security perspective.

After depth study on SQL Injection Attacks, methods and the effectiveness of existing

prevention techniques, I proposed a potential solution to mitigate SQL Inject Attacks.

As I discussed in section 1.5, I believe that SQLIAs has never been studied extensively

and prevention techniques have not been systematically composed.

1.6.1 Method:

I have got inspiration and guidance from the field of security when choosing a proper

method for conducting our survey. The steps in my method are influenced by the idea of

risk analysis, a process with high bearing on security issues, as said by Connolly et al.

[48] and Ross J. Anderson [49]. According to Ian Sommerville [50], risk analysis as

viewed in the context of software systems involves analyzing a system and its

operational environment. The aim is to discover potential threats, their root causes and

associated risks. A general web application is considered to be our system and I will

focus on threats and risks associated with SQL injection Attacks.

In the first step, I will profile web applications by exploring their scope,

implementations, architecture, inherent components and communication principles. I

also identify assets that I believe many web applications share.


31

In step two, basic principles of RDBMS systems as well as SQL will be explored. In

addition, I identify security issues that Iconsider relevant.

Step three involves studying general aspects of computer security.

Step four constitutes my survey over SQL injection in which I classify the area in terms

of general criteria. Along the way, I try to capture as many general aspects as I can:

definitions, characteristics, conditions, vulnerabilities, attack methods and

countermeasures. The different ways in which SQL injection-related attacks may be

carried out on web applications are examined, and the attack methods will be divided

into broader groups related to threats, and mapped to different security services, e.g.

availability, confidentiality and integrity.

In step five, I analyze my security framework constructed in step four. alIso conduct an

examination of an existing prevention technique against SQL injection in the

perspective of my security framework. Then, I try to identify required countermeasures

needed in a prevention technique to adequately cope with SQL injection.

1.6.2 Method for Data Collection:

In addition to survey SQL injection Attacks, I will first attempt to find all synonyms for

SQL injection and use them as search criteria. Those criteria will be used to find any

conceivable material which published in proceedings, articles, white papers, technical

reports, books, Internet and other documents. The information about SQL injection in

general and its attack methods in particular will be complemented by security

advisories, FAQs and discussions within security communities and organizations on the

Internet. Furthermore, discussions in hacker communities on the Internet will be

considered. The process of collecting data about SQLIAs will undergo several

repeations.

The information about web applications will be collected in the same manner. I consider

relational database management systems, SQL and Information security to be well

researched subjects and therefore more documented, meaning that relevant books will

probably be enough to cover them. However, where certain database specific issues are

discussed in the context of SQL injection, I will check them out. I will search published


32

guides for information about web application vulnerabilities and security issues

regarding secure web application development.

1.7 Outline

In chapter 2, Database Management System and related security issues are covered.

In chapter 3 of this thesis, I discuss web applications, architecture and related security

issues.

In chapter 4, I discuss the classification of SQL Injection Attacks, Internet Security

Attacks in detail and cover security principles.

In chapter 5, I discuss the Database Security Layers and Database Security Policies.

In chapter 6, I discuss SQL Injection Attacks Mitigation Framework and technique in

depth.

In chapter 7, I discuss the Framework Validation with framework assessment by

industry assessment.

In chapter 8, I discuss implications of the framework and validation performed in

chapter 6 and 7. Moreover, I briefly discuss what I believe to be interesting directions

for the continued study of SQL injection. Finally, I summarize the findings of this study

and attempt to draw conclusi1ons about the framework against SQL injection.

Documents

Ch. 1 Introduction - INFLIBNETshodhganga.inflibnet.ac.in/bitstream/10603/24846/2/ch. 1... · A database management system ... communication of having participation in part of communication