sql injection krishna report

8/19/2019 SQL Injection Krishna Report

1/51

1

CHAPTER I

INTRODUCTION

1.1 INTRODUCTION

WEB applications are applications that can be accessed over the Internet by using any compliant

Web browser that runs on any operating system and architecture. They have become ubiquitous

due to the convenience, fleibility, availability, and interoperability that they provide.

!nfortunately, Web applications are also vulnerable to a variety of new security threats. "#$

In%ection &ttac's ("#$I&s) are one of the most significant of such threats. "#$I&s have become

increasingly frequent and pose very serious security ris's because they can give attac'ers

unrestricted access to the databases that underlie Web applications.

1.2 OVERVIEW:

*ur basic approach, as eplained in the following sections, automatically mar's as

trusted all hard+coded strings in the code and then ensures that all "#$ 'eywords and operators

are built using trusted data. In some cases, this basic approach is not enough because developers

can also use eternal query fragmentspartial "#$ commands that come from eternal input

sourcesto build queries. Because these string fragments are not hard coded in the application,

they would not be part of the initial set of trusted data identified by our approach and the

approach would generate false positives when the string fragments are used in a query. To

account for these cases, our technique provides developers with a mechanism for specifying

sources of eternal data that should be trusted.

The data sources can be of various types such as files, networ' connections, and server

variables. *ur approach uses this information to mar' data that comes from these additional

sources as trusted. In a typical scenario, we epect developers to specify most of the trusted

sources before testing and deployment. -owever, some of these sources might be overloo'ed

until after a false positive is reported, in which case, developers would add the omitted items to

the list of trusted sources.


2/51

In this process, the set of trusted data sources monotonically grows and eventually

converges to a complete set that produces no false positives. It is important to note that false

positives that occur after deployment would be due to the use of eternal data sources that have

never been used during in+house testing. In other words, false positives are li'ely to occur only

for totally untested parts of applications.

Therefore, even when developers fail to completely identify additional sources of trusted

data beforehand, we epect these sources to be identified during normal testing and the set of

trusted data to quic'ly converge to the complete set. It is also worth noting that none of the

sub%ects that we collected and eamined so far required us to specify additional trusted data

sources. &ll of these sub%ects used only hard+coded strings to build query strings.

1.3 ORGANISATIONAL REPORT:

Identifying trusted data sources and mar'ing data coming from these sources as trusted,

!sing dynamic tainting to trac' trusted data at runtime, and

&llowing only trusted data to form the semantically relevant parts of queries such as "#$

'eywords and operators.

!nli'e previous approaches based on dynamic tainting, our technique is based on

positive tainting, which eplicitly identifies trusted (rather than untrusted) data in a program.

This way, we eliminate the problem of false negatives that may result from the incomplete

identification of all untrusted data sources. /alse positives, although possible in some cases, can

typically be easily eliminated during testing. *ur approach also provides practical advantages

over the many eisting techniques whose application requires customi0ed and comple runtime

environments It is defined at the application level, requires no modification of the runtime

system, and imposes a low eecution overhead.


3/51

2

CHAPTER II

LITERATURE SURVEY

2.1 Intrusion !t!"tion #i$ st$ti" $n$%&sis

2.1.1 Introu"tion to t'! st$ti" $n$%&sis

*ne of the primary challenges in intrusion detection is modeling typical application

behavior, so that we can recogni0e attac's by their atypical effects without raising too many false

alarms. We show how static analysis may be used to automatically derive a model of application

behavior. The result is a host+based intrusion detection system with three advantages a high

degree of automation, protection against a broad class of attac's based on corrupted code, and

the elimination of false alarms. We report on our eperience with a prototype implementation of

this technique

2.1.2 Co()ut!r s!"urit& $n s!*u!n"! o+ (o!%s

3omputer security has undergone a ma%or renaissance in the last five years. Beginning

with "un4s introduction of the 5ava language and its support of mobile code in 1667, pro+

gramming languages have been a ma%or focus of security research. 8any papers have been

published applying pro+ gramming language theory to protection problems 97, :;, especially

information flow 91


4/51

:

specification construction.

To reduce the potentially huge volume of trace data, we consider only the security+relevant

behavior of the applica+ tion of interest. The monitoring strategy should then ensure that a

compromised application cannot compromise system integrity while still evading detection.

In general, it will always be possible for attac'ers to evade detection in our system if they do

not cause any harm, but if they want to cause harm, they will need to interact with the operating

system in a way which ris's detection.

In this section, we propose a sequence of models that we use to specify epected application

behavior first, a trivial model to illustrate the main idea= then, the callgraph model= third, a

refinement, the abstract stac' model= and finally, the low+overhead digraph model.Each model is

intended to satisfy a common soundness property false alarms should never occur. To achieve

this goal, we must ma'e a number of mild assumptions about our operating environment. We

consider only portable 3 code that has no implementation+defined behavior for e+ ample, we

assume that there are no intentional array bounds violations, >!$$+pointer dereferences, or

other memory errors= we assume there is no function pointer arithmetic or type+casting

between function pointers and other point+ ers= and we assume there is no application+defined

runtime code generation.

2.2 E,)%oitin- E,!"ution Cont!,t +or t'! D!t!"tion o+ Ano($%ous S&st!( C$%%s

2.2.1 Introu"tion to t'! Ano($%ous S&st!( C$%%s

&ttac's against privileged applications can be detected by analy0ing the stream of system

calls issued during process eecution. In the last few years, several approaches have been

proposed to detect anomalous system calls. These approaches are mostly based on modeling

acceptable system call sequences. !nfortunately, the techniques proposed so far are either

vulnerable to certain evasion attac's or are too epensive to be practical. This paper presents a

novel approach to the analysis of system calls that uses a composition of dynamic analysis and

learning techniques to characteri0e anomalous system call invocations in terms of both the

invocation contet and the parameters passed to the system calls. *ur technique provides a more


5/51

7

precise detection model with respect to solutions proposed previously, and, in addition, it is able

to detect data modi?cation attac's, which cannot be detected using only system call sequence

analysis.

2.2.2 S&st!( "$%% $r-u(!nt $n "$%%in- "ont!,t $n$%&sis

The eff ectiveness of system call analysis that includes call stac' information is directly related to

the number of contets in which a given argument value associated with the invocations of a

particular system call occurs. 8ore speci?cally, if argument values appear in many contets,

essentially randomly, contet+speci?c learning models are li'ely to off er no bene?t. /urthermore,

if each observed argument value appears (possibly multiple times) in only one contet, we would

epect system call argument analysis that includes call stac' information to outperform contet+insensitive models. In this section, we propose a metric to epress the degree of contet+

niqueness of argument values. We then use this metric to determine which applications are li'ely

to be amenable to system call analysis that ta'es into account stac'+speci?c behavior. the

following primary contributions@ It analy0es the relationship between system call arguments and

diff erent calling contets, and it introduces a novel metric to quantify the degree to

which argument values ehibit uniqueness across contets.

@ It demonstrates that the application4s call stac' can be leveraged to add contet to the argument

values that appear at the system call interface. It also demonstrates that the increased sensitivity

of contet+speci?c argument models results in better detection performance.

@ It de?nes a technique to detect data modi?cation attac's, which are notdetected by previously

proposed approaches based on system call sequences.

@ It presents an etensive real+world evaluation encompassing over :: million system call

invocations collected over A: days from 1 hosts

2.3 D!t!"tor S&st!( +or Coin"i!n"! D!t!"tion o+ intrusion.

2.3.1 Introu"tion +or Coin"i!n"! D!t!"tion o+ intrusion

The eff ectiveness of system call analysis that includes call stac' information is directly related to

the number of contets in which a given argument value associated with the invocations of a


6/51

A

particular system call occurs. 8ore speci?cally, if argument values appear in many contets,

essentially randomly, contet+speci?c learning models are li'ely to off er no bene?t. /urthermore,

if each observed argument value appears (possibly multiple times) in only one contet, we would

epect system call argument analysis that includes call stac' information to outperform contet+

insensitive models. In this section, we propose a metric to epress the degree of contet+

uniqueness of argument values. We then use this metric to determine which applications are

li'ely to be amenable to system call analysis that ta'es into account stac'+speci?c behavior.

2.3.2 Cont!,ts)!"i/" (o!%in- $))ro$"'

Eperience shows that evidence of attac's often appears in the argument values of system calls.

"ometimes this may be due to Ccollateral damageD to local (stac') variables when overwriting a

return address. In these cases, damaged variables are then used in system call invocations before

the procedure returns. In other cases, the attac' is leveraging the privileges of the application to

perform actions that are not normally performed by the victim program. In many instances, these

diff erences can be identi?ed by argument models. To determine the set of system calls to use for

our analysis, we studied the :2 system calls implemented in the version .A.1 of the $inu

'ernel to determine which additional calls represent avenues to leveraging or increasing the

privilege of applications. This study identi?ed 2A system calls, shown in Table 2, that we found

should be monitored to detect attempts to compromise the security of a host. >ote that in our

system only arguments that have intrinsic semanticmeaning are modeled. Integer rguments

corresponding to ?le descriptors and memory addresses, for eample, are ignored, since their

values are not meaningful across runs of an application. &dditionally, these values rarely contain

any semantic information about the operation being performed.

Strin- C'$r$"t!r Distri0ution The string character distribution model captures the concept of

a normal string argument by loo'ing at its character distribution. The approach is based on the

observation that strings have a regular structure, are often human+readable, and almost always

contain only printable characters. In the case of attac's that send binary data, a completely

diff erent character distribution can be observed. This is also true for attac's that send many

repetitions of a single character (e.g., the nop+sledge of a buff er overow attac'). The detection

of deviating arguments is performed using a statistical test (Fearson G+test) that determines the


7/51

<

probability that the character distribution of a system call argument ?ts the normal distribution

established during the training phase.

Strin- Stru"tur$% In+!r!n"! *ften, the manifestation of an eploit is immediately visible in

system call arguments as unusually long strings or strings that contain repetitions of non+

printable characters. There are situations, however, when an attac'er is able to craft her attac' in

a manner that ma'es its manifestation appear more regular. /or eample, non+printable

characters can be replaced by groups of printable characters. In such situations, we need a more

detailed model of the system call argument. "uch a model can be acquired by analy0ing the

argument4s structure. /or the purposes of this model, the structure of an argument is the regular

grammar that describes all of its normal, legitimate values. The process of inferring the grammar

from training data is based on a 8ar'ov model and a probabilistic state+merging procedure.


8/51

H

CHAPTER III

SYSTE ANALYSIS

3.1. O#!r$%% D!s"ri)tion

3.1.1. Prou"t P!rs)!"ti#!

3.1.1.1. E,istin- S&st!(

Frevious approaches that correlated or summari0ed alerts generated by independent I"s,

ouble Juard forms a container+based I" with multiple input streams to produce alerts.

The following are the features of eisting system

In the system Bac'+end database server is protected behind a firewall. Web servers that

are remotely accessible only over the Internet The system is susceptible to attac's that us web

requests as a means to eploit the bac' end.&ttac's are detected only after the occurrence of

data corruption

3.1.1.2. Dr$0$"s o+ E,istin- S&st!(

The following are the disadvantages of eisting system.

In eisting system the Web K atabase based virtual security scheme deployment is very

difficult.The 3omputational cost of the system is very high.The system has a lot of web server

traffic an d B server traffic

3.1.1.3. Pro)os! S&st!(

/ollowing are the 'ey features of the proposed system.

We presented an intrusion detection system that builds models of normal behavior for

multi tiered web applications from both front+end web (-TTF) requests and bac'+end database

("#$) queries.We have shown that correlation of input streams provides a better characteri0ation

of the system for anomaly detection because the intrusion sensor has a more precise normality

model that detects a wider range of threats.We achieved this by isolating the flow of information

from each web server session with a lightweight virtuali0ation./urthermore, we quantified the


9/51

6

detection accuracy of our approach when we attempted to model static and dynamic web

requests with the bac'+end file system and database queries.

We present ouble Juard, a system used to detect attac's in multi tiered web services. *ur

approach can create normality models of isolated user sessions that include both the web front+

end (-TTF) and bac'+end (/ile or "#$) networ' transactions. To achieve this, we employ a

lightweight virtuali0ation technique to assign each user4s web session to a dedicated container, an

isolated virtual computing environment. We use the container I to accurately associate the web

request with the subsequent B queries. Thus, ouble Juard can build a causal mapping profile

by ta'ing both the web server and B traffic into account.

3.1.1.4. A#$nt$-!s o+ Pro)os! S&st!(

The following are the advantages of proposed system over eisting system.The system can build

a causal mapping profile by ta'ing both the web server and B traffic into account. The system

can ma'e a high level secure system in both front end and bac' end.

The system is used to control remote attac's. In this detection system user session returns the

user behaviour

3.1.2. Prou"t +un"tions

/ollowing are the modules in this detection system.

1. !ser authentication. !ser "ession identification

2. -TTF Lequest processing

:. "#$ query processing7. 3ontainer I creation

A. Lequest 8apping K intrusion identification


10/51

1

This module is to ensure that the correct user entering and access the resources.

The admin can enter and alter the information provided by him. The modules will as' for

the password for the authentication.

2. Us!r S!ssion i!nti+i"$tion

"ession identification is the second module which helps to identify and gets the

http request and query request the session. The intrusion is a malicious activities or policy

violations. Then there should be an attempt to stop an intrusion attempt. This module is for

avoiding intrusion detection by analy0ing the rule violation. The person of a company will

not be allowed to send any mail to another company without the administrator permission.

If the person sends the person mail will be bloc'ed.

3. HTTP R!*u!st Pro"!ssin-:

The http process module deal with the http session hi%ac'ing attac's, whichattempts to gather and in%ects the http request. This module helps to detect the malicious

attempts from the http request. This is the one 'ind of web server attac'. &ccording to the

static model algorithm, this module identifies such sessions as suspicious so that it may

have false positives in our detections. Leceived front+end and bac'+end request validation

reports were generated using these data.

4. S5L *u!r& )ro"!ssin-:

The proposed system prevents the compleity against "#$ in%ection attac's."#$

in%ection is yet another common vulnerability that is the result of la input validation. The

goal of "#$ in%ection is to insert arbitrary data, most often a database query, into a string

that4s eventually eecuted by the database. The insidious query may attempt any number

of actions, from retrieving alternate data, to modifying or removing information from the

database.

4. Cont$in!r ID "r!$tion:

The container id creation is one 'ind of process which allocates an id for every user request.

!ser4s web requests are isolated into a container= an attac'er can never brea' into other users4

sessions. The container helps to maintain the details about the intruder as well as the normal

user. The request of each user will be identified and stored into the container for further

process of intrusion detection.


11/51

11

6. R!*u!st $))in- 7 intrusion i!nti+i"$tion:

The alert about the intruder based on http and sql in%ection request will be ta'en from the

request stream. !sing machine learning approach the details of the intruder will begathered and grouped with the 8eta alert schemes. The grouped data will be sending to

the admin. The admin can store the logs and intruder details in the database. The admin

can view all the details about users, intruders through their web logs.

8. R!)orts

The alert about the intruder based on their failure count, misbehaving will be ta'en

from the data stream i.e. the login form. !sing machine learning approach the details of the

intruder will be gathered and grouped with the 8eta alert schemes. The grouped data will be

sending to the admin. The admin can store the logs and intruder details in the database. The

admin can view all the details about users, intruders through their logs.

CHAPTER 1V

SYSTE SPECI9ICATION


12/51

1

2.4 9!$si0i%it& Stu&

& system is a feasible system only if it is feasible within limited recourse and time. In this

system each and every process can be feasible for the user and also developer. It proved user

friendly input such as device independent inputs and getting proper solution for the problem.

The different types of feasible system that have to analy0e are,

2.4.1 T!"'ni"$% 9!$si0i%it&

2.4.2 !'$#ior$% 9!$si0i%it&

2.4.3 E"ono(i"$% 9!$si0i%it&

2.4.4 O)!r$tion$% 9!$si0i%it&

2.4.1 T!"'ni"$% 9!$si0i%it&

Technical /easibility is the assessment of the technical view of the system. The system is

developed for ot net environment= a platform independent tool is used to develop the system.The consideration those are normally associated with the technical feasibility include the

following

evelopment ris'

Lesource availability

Technology

The development ris' concerns the probability, the function of all elements and its

performance should be same in all platforms and in the system that is being developed. This

system is developed according to the standards and the development software tools are selected

in such a way to avoid the problems cited above.

The software used to develop this system is Windows MF, visual studio ot net is doneefficiently, and the concept of "#$ helps to create the application bac'end. These components

are also helpful in providing interactivity to 5ava applications.

2.4.2 !'$#ior$% 9!$si0i%it&

It is common 'nowledge that computers illustrations have something to do with turnover

transfers, retraining and changes in user or developer status. The main emphasis is customer

service, personal contacts with customers.


13/51

12

/easibility report is directed towards management. It evaluates the impact of the

proposed changes on the area in question. The report is a formal document for management use,

brief enough and sufficiently non+technical to be understood.

2.4.3 E"ono(i"$% 9!$si0i%it&

Economic feasibility or cost benefit is an assessment of the economic %ustification for a

computer based system pro%ect. Though this system the administrator can use the tool from

anywhere within their concern. The system is developed using the eisting resources. "o the

pro%ect is economically feasible.

This is the most frequently used method for evaluating the effectiveness of a user system.

8ore commonly, 'now as cost analysis the procedure is to determine the benefits and savings

that are epected from a candidate system and compare them with costs.

This system getting hundreds present economical feasibility. It will be achieved goal very

efficiently. &nd evolution of development cost (hardware and software needed) is weighted

against the ultimate income or benefit derived from the system. /inally, it is assured that this

pro%ect is economically feasible

2.4.4 O)!r$tion$% 9!$si0i%it&:

*perational /easibility deals with the study of prospects of the system. This system

operationally eliminates all the tensions of the administrator and helps in effectively trac'ing the

pro%ect progress. This 'ind of automation will surely reduce the time and energy, which

previously consumed in manual wor'. Based on the study, the system proved to be operationally

feasible.

3. DEVELOPENT ENVIRONENT

3.1 HARDWARE RE5UIREENTS

The most common set of requirements defined by any operating system or

software application is the physical computer resources, also 'nown as hardware, a

hardware requirements list is often accompanied by a hardware compatibility list


14/51

1:

(-3$). &n -3$ lists tested, compatible, and sometimes incompatible hardware

devices for a particular operating system or application.

Frocessor Intel uel coreL&8 JB

-ard is' 6JB

Frinter -F In' 5et

Neyboard "amsung

8ouse $ogi Tech (*ptical)

2. "*/TW&LE LE#!ILE8E>T"

It is a complete description of the behavior of a system to be developed and It includes a

set of use cases that describe all the interactions the user will have with the software. In

addition to use cases, the "L" also contains non+functional requirements.

*perating "ystem Windows MF

/ront End &"F*T >ET

3oding language 3O*T >ETBac' End "#$ "erver

2.2 FL*JL&88I>J E>PIL*>8E>T

AOUT DOT NET 9RAEWOR;

The dot net framewor' is a new computing platform that simplifies application

development in the highly distributed environment of the internet.


15/51

17

O:

The common language runtime is the foundation of the *T>ET /ramewor'. It

manages code at eecution time, providing important services such as memory

management, thread management, and removing and also ensures more security and

robustness. The concept of code management is a fundamental principle of the runtime.

3ode that target the runtime is 'nown as managed code, while code that does not target

the runtime is 'nown as unmanaged code.

THE DOT NET 9RAE WOR; CLASS LIRARY:

It is a comprehensive= ob%ect+oriented collection of reusable types used to develop

applications ranging from traditional command+line or graphical user interface (J!I)

applications based on the latest innovations provided by &"F*T >ET, such as Web

/orms and M8$ Webs services.

The ot >et /ramewor' can be hosted by unmanaged components that load the

common language runtime into their processes and initiate the eecution of managed

code, thereby creating a software environment that can eploit both managed and

unmanaged features.

9EATURES O9 THE COON LANGUAGE RUNTIE:


16/51

1A

The common language runtime manages memory= thread eecution, code eecution,

code safety verification, compilation, and other system services these are all run on 3$L.

• "ecurity.

• Lobustness.

• Ferformance.

SECURITY

The runtime enforces code access security. The security features of the runtime thus

enable legitimate Internet+deployed software to be eceptionally feature rich.

ROUSTNESS

The runtime also enforces code robustness by implementing a strict type+ and code+

verification infrastructure called the common type system (3T"). The 3T" ensures that

all managed code is self+describing.

PER9ORANCE

The runtime is designed to enhance performance. &lthough the common language

runtime provides many standard runtime services, managed code is never interpreted. &

feature called %ust+in+time (5IT) compiling enables all managed code to run in the native

machine language of the system on which it is eecuting.

3.3.1 AOUT ASP DOTNET

&"F*T >ET is the net version of &ctive "erver Fages (&"F)= it is a

unified Web development platform that provides the services necessary for developers to

build enterprise+class Webs applications. While &"F*T >ET is largely synta

compatible, it also provides a new programming model and infrastructure for more

secure, scalable, and stable applications. &"F*T >ET is a compiled, >ET+based

environment= user can author applications in any *T >ET compatible language,

including Pisual Basic *T >ET, 3O, and 5"cript *T >ET.&dditionally, the entire *T >ET /ramewor' is available to any &"F*T >ET

application. evelopers can easily access the benefits of these technologies, which

include the managed common language runtime environment (3$L), type safety,

inheritance, and so on. &"F*T >ET has been designed to wor' seamlessly with


17/51

1<

WQ"IWQJ -T8$ editors and other programming tools, including 8icrosoft Pisual

"tudio *T >ET.

evelopers can choose from the following two features when creating an &"F*T

>ET application. Webs /orms and Webs services, or combine these in any way they see

fit. Each is supported by the same infrastructure that allows using authentication

schemes= cache frequently used data, or customi0es your applicationRs configuration, to

name only a few possibilities. &"F*T >ET provides a simple model that enables Webs

developers to write logic that runs at the application level. evelopers can write this code

in the global.asp tet file or in a compiled class deployed as an assembly.

This logic can include application+level events, but developers can easily etend

this model to suit the needs of their Web application.&"F*T >ET provides easy+to+use

application and session+state facilities that are familiar to &"F developers and are readily

compatible with all other *T >ET /ramewor' &FIs. &"F*T >ET offers the

I-ttp-andler and I-ttp8odule interfaces.

&"F*T >ET ta'es advantage of performance enhancements found in the *T

>ET /ramewor' and common language runtime. &dditionally, it has been designed to

offer significant performance improvements over &"F and other Web development

platforms. &ll &"F*T >ET code is compiled, rather than interpreted, which allows

early binding, strong typing, and %ust+in+time (5IT) compilation to native code, to name

only a few of its benefits. &"F*T >ET is also easily factorable, meaning that

developers can remove modules (a session module, for instance) that are not relevant to

the application they are developing.

Web /orms allows us to build powerful forms+based Web pages. When building

these pages that use &"F*T >ET server controls to create common !I elements, and

program them for common tas's. These controls allow to rapidly building a Web /orm

out of reusable built+in or custom components, simplifying the code of a page. &n M8$

Web service provides the means to access server functionality remotely. !sing Web


18/51

1H

services, businesses can epose programmatic interfaces to their data or business logic,

which in turn can be obtained and manipulated by client and server applications.

&"F*T >ET provides etensive caching services (both built+in services and

caching &FIs). &"F*T >ET also ships with performance counters that developers and

system administrators can monitor to test new applications and gather metrics on eisting

applications. &"F.>ET is a server+side technology. That is, it runs on the web server.

8ost web designers cut their teeth learning client+side technologies such as -T8$,

5ava"cript, and 3ascading "tyle "heets (3""). When a web browser requests a web page

created with only client+side technologies, the web server simply grabs the files that the

browser (or client) requests and sends them down the line. The client is entirely

responsible for reading the mar'up in those files and interpreting that mar'up to display

the page on the screen.

AOUT C?DOT NET

• 3O language is intended to be a simple, modern, general+purpose, ob%ect+oriented

programming language.

•

The language, and implementations are used to provide support for softwareengineering principles such as strong type chec'ing, array bounds chec'ing,

detection of attempts to use uninitiali0ed variables, and automatic garbage

collection. "oftware robustness, durability, and programmer productivity are

important.

• The language is intended for use in developing software components suitable for

deployment in distributed environments.

• "ource code portability is very important, as is programmer portability, especially

for those programmers already familiar with 3 and 3SS.

• "upport for internationali0ation is very important.

9EATURES

http://en.wikipedia.org/wiki/Strongly_typed_programming_languagehttp://en.wikipedia.org/wiki/Strongly_typed_programming_languagehttp://en.wikipedia.org/wiki/Bounds_checkinghttp://en.wikipedia.org/wiki/Bounds_checkinghttp://en.wikipedia.org/wiki/Garbage_collection_(computer_science)http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)http://en.wikipedia.org/wiki/Software_componentshttp://en.wikipedia.org/wiki/Internationalization_and_localizationhttp://en.wikipedia.org/wiki/Internationalization_and_localizationhttp://en.wikipedia.org/wiki/Bounds_checkinghttp://en.wikipedia.org/wiki/Garbage_collection_(computer_science)http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)http://en.wikipedia.org/wiki/Software_componentshttp://en.wikipedia.org/wiki/Internationalization_and_localizationhttp://en.wikipedia.org/wiki/Strongly_typed_programming_language


19/51

16

• There are no global variables or functions. &ll methods and members must be

declared within classes. "tatic members of public classes can substitute for global

variables and functions.

• $ocal variables cannot shadow variables of the enclosing bloc', unli'e 3 and 3S

S. Pariable shadowing is often considered confusing by 3SS tets.

• In addition to the try...catch construct to handle eceptions, 3O has a try...finally

construct to guarantee eecution of the code in the finally bloc'.

• 8ultiple inheritances are not supported, although a class can implement any

number of interfaces. This was a design decision by the languageRs lead architect

to avoid complication and simplify architectural requirements throughout 3$I.

• Enumeration members are placed in their own scope.

• /ull type reflection and discovery is available.

• 3O currently has ET, have different requirements for

wor'ing with data. >ever need to directly edit an M8$ file containing data + but it is very

useful to understand the data architecture in &**T >ET.

&**T >ET offers several advantages over previous versions of &*

• Interoperability

• 8aintainability

• Frogrammability

• Ferformance "calability

INTEROPERAILITY:

&**T >ET applications can ta'e advantage of the fleibility and broad

acceptance of M8$. Because M8$ is the format for transmitting datasets across the

networ', any component that can read the M8$ format can process data. The receiving

component need not be an &**T >ET component.

http://en.wikipedia.org/wiki/Variable_shadowinghttp://en.wikipedia.org/wiki/Multiple_inheritancehttp://en.wikipedia.org/wiki/Enumerated_typehttp://en.wikipedia.org/wiki/Scope_(programming)http://en.wikipedia.org/wiki/Scope_(programming)http://en.wikipedia.org/wiki/Reflection_(computer_science)http://en.wikipedia.org/wiki/Reserved_wordhttp://en.wikipedia.org/wiki/Reserved_wordhttp://en.wikipedia.org/wiki/Variable_shadowinghttp://en.wikipedia.org/wiki/Multiple_inheritancehttp://en.wikipedia.org/wiki/Enumerated_typehttp://en.wikipedia.org/wiki/Scope_(programming)http://en.wikipedia.org/wiki/Reflection_(computer_science)http://en.wikipedia.org/wiki/Reserved_word


20/51

AINTAINAILITY:

In the life of a deployed system, modest changes are possible, but substantial,

&rchitectural changes are rarely attempted because they are so difficult. &s the

performance load on a deployed application server grows, system resources can become

scarce and response time or throughput can suffer.

PER9ORANCE

&**T >ET datasets offer performance advantages over &* disconnected

record sets. In &**T >ET data+type conversion is not necessary.

SCALAILITY:

&**T >ET accommodates scalability by encouraging programmers to

conserve limited resources. &ny &**T >ET application employs disconnected

access to data= it does not retain database loc's or active database connections for long

durations.

XML WEB SERVICES

M8$ web services are applications that can receive the requested data using M8$

over -TTF. M8$ web services are not tied to a particular component technology or

ob%ect+calling convention but it can be accessed by any language, component model, or

operating system. In Pisual "tudio *T >ET, user can quic'ly create and include M8$

web services using Pisual Basic, Pisual 3O, 5"cript, 8anaged Etensions for 3SS, or

&T$ "erver.

SOAP

"*&F originally defined as Si()%! O0@!"t A""!ss Proto"o%, is a protocol specification

for echanging structured information in the implementation of Web "ervices in


21/51

1

computer networ's. It relies on Etensible 8ar'up $anguage (M8$) for its message

format, and usually relies on other &pplication $ayer protocols, most notably -ypertet

Transfer Frotocol (-TTF) and "imple 8ail Transfer Frotocol ("8TF), for message

negotiation and transmission.

CONSTRUCTORS AND DESTRUCTORS:

3onstructors are used to initiali0e ob%ects, whereas destructors are used to destroy

them. In other words, destructors are used to release the resources allocated to the ob%ect.

In 3O*T >ET the sub finali0e procedure is available. The sub finali0e procedure is

used to complete the tas's that must be performed when an ob%ect is destroyed. The sub

finali0e procedure is called automatically when an ob%ect is destroyed. In addition, the

sub finali0e procedure can be called only from the class it belongs to or from derived

classes.

WSDL

The W!0 S!r#i"!s D!s"ri)tion L$n-u$-! is an M8$+based language that is used

for describing the functionality offered by a Web service. & W"$ description of a web

service provides a machine+readable description of how the service can be called, what

parameters it epects, and what data structures it returns. It thus serves a roughly similar

purpose as a method signature in a programming language.

GARAGE COLLECTION: Jarbage 3ollection is another new feature in 3O*T >ET. The *T >ET

/ramewor' monitors allocated resources, such as ob%ects and variables. In addition, the

*T >ET /ramewor' automatically releases memory for reuse by destroying ob%ects

that are no longer in use. In 3O*T >ET, the garbage collector chec's for the ob%ects

that are not currently in use by applications. When the garbage collector comes across an

ob%ect that is mar'ed for garbage collection, it releases the memory occupied by the

ob%ect.

UDDI

Uni#!rs$% D!s"ri)tion Dis"o#!r& $n Int!-r$tion (UDDI) is a platform+

independent, Etensible 8ar'up $anguage (M8$)+based registry for businesses

worldwide to list themselves on the Internet and a mechanism to register and locate web

service applications. I was originally proposed as a core Web service standard. It is


22/51

designed to be interrogated by "*&F messages and to provide access to Web "ervices

escription $anguage (W"$) documents describing the protocol bindings and message

formats required to interact with the web services listed in its directory.

ULTITHREADING:

3O*T >ET also supports multithreading. &n application that supports

multithreading can handle multiple tas's simultaneously, user can use multithreading to

decrease the time ta'en by an application to respond to user interaction. To decrease the

time ta'en by an application to respond to user interaction, !ser must ensure that a

separate thread in the application handles user interaction.

3.3.2 AOUT S5LSERVER 2BB6

The *$&F "ervices feature available in "#$ "erver version


23/51


24/51

:

& macro is a set of actions. Each action in macros does something. "uch as opening a

form or printing a report .Web write macros to automate the common tas's the wor' easy

and save the time.


25/51

7

CHAPTER V

SYSTE DESIGN

6.1 9UNDAENTAL ELEENTS O9 DESIGN

It is where the approach to the creation of the new system. It provides

understanding of the procedural details necessary for implementing the system. It involves

first logical design and logistical construction of the system. $ogical design is li'e blue print.

Fhysical design produces software, files and wor'ing system. The fundamental ob%ect in the

design is that it ensures very attractive and user friendly.

/ig 7.1 Intrusion detection

8ultitier web &pplication &rchitecture

The above diagram depicts simple intrusion detection in multitier web application architecture

where three clients (for eample) are trying to access a atabase server. Though they are trying

to access the data from the database server they are forced to traverse through the applicationserver. &nd the application server ta'es the request as input and gives the response as output.

The above diagram depicts little bit comple intrusion detection in multitier web application

architecture where the clients are requesting for a data but on the other had the system first

authenticates the user and then assign a session to each and every client and then it processes the

C%i!nts

C%i!nts

C%i!nts

D$t$ $s!

S!r#!r


26/51

A

-TTF request and the "#$ query request. "o after creating these sessions and processing all the

requests the system assigns then with a container so that the data and the transaction is safe and

secure.

ARCHITECTURE DIAGRA:

It describes the overall process of the Froposed "ystem./irst the client is authenticated and

then the "essions are &ssigned for each 3lient,.-ttp request and "#$

Lequest are processed.3reate the 3ontainer for each client and then finally map all those

requests./inally the output is obtained.

CONTET DIAGRA:

LEVEL B:

!ser

Lequirements

9i- 6.3.Cont!,t Di$-r$( o+ Dou0%! -u$r IDS

The $evel data flow diagram is the first flow for this module where the admin plays a vital

role. The admin passes the user requirements to the server and then the server as' for those

details from the B say for eample the company details and then it returns to the admin.

LEVEL 1:

Legistration.

!ser >ame!ser >ame

/ig7.: $evel 1 / of ouble guard I" /ig7.: $evel 1 / of ouble guard I"

The $evel 1 data flow diagram is the net flow for this module where a new company is being The $evel 1 data flow diagram is the net flow for this module where a new company is being

registered with the details of a company and those details are stored in a database. Then the admin logins to theregistered with the details of a company and those details are stored in a database. Then the admin logins to the

application and can do various tas's.application and can do various tas's.

"erver

3ompanyuser details&dmin

&dmin

Lo-in

Us!r

!t$i%s

N! "o()$n&

Maillinformation

Rule

Allocation

Hackeridentication

R!-istr$tio

n

Co()$n

& !t$i%s

8ail

D!t$i%s

Logindetails Lule

&llocatedetails

-ac'er D!t$i%s


27/51

<

The admin can retrieve the user details or the mail information or the hac'er information

or finally the rule allocation as well. /or each and every section the admin can retrieve the details

across each module which would be helpful for the admin to identify the hac'er as well.

1 iagram *f ouble Juard I"

$EPE$ $EPE$

9i- 6.6.L!#!%2 D9D o+ Dou0%! -u$r IDS

The $evel data flow diagram is the net module in the ouble guard I" where the user logins

to the application as the authenticated user and then his login details are referred as well and after

logging in the user is able to perform different operations.The user is able to chec' the company

details if heshe is interested to 'now the company details and then the user is also able to viewthe mailing process if interested and at the same time heshe can chec' the user details of that

particular user and finally the user can also chec' the 8il log for the future references

$EPE$ 2$EPE$ 2

UserLo-in

Company

Details

Mailingprocess

User details

Mail log

Co()$n

& !t$i%s

$i%in-)ro"!ss

Userdetails

$i% %o-

Lo-in

!t$i%s

A(in Lo-in

Us!r

D!t$i%s

Hackingidentication

Us!r

ri-'ts

!t$i%s

Mailstatus

-ac'er

List

Login

Details


28/51

H

V!ri+& 3oding

Wor

"tatus details"tatus details

9i- 6.8.L!#!%3 D9D o+ Dou0%! -u$r IDS

The final data flow diagram of this double guard intrusion detection system is that the

admin logins to the application and view many important details.

&t first the admin is authenticated with the authentication process and then heshe can

chec' the status details as well. Then the admin here identifies the hac'er if any and then the

admin analyses the hac'er details completely such a way that the hac'er can be placed in a

bloc'ed list and in near future the hac'er if suppose tries to hac' the application will be bloc'ed

completely for the entire period.


29/51

6

4.1.8 D$t$0$s! D!si-n

The database is a collection of interrelated data with minimum of redundancy to

serve the user quic'ly and efficient. atabase Environment common data are available

and used by several users Instead of each program managing its own data, data across

applications are shared authori0ed users with the atabase software managing the data of

the entity.

Froper case has been ta'en is designing in atabase to achieve the following

ob%ectives.1. ata Integration

. ata 3onsistency

2. ata Independence

Stru"tur! o+ D$t$0$s!

The database design is a must for any application developed especially more for the

data store pro%ects. "ince the chatting method involves storing the message in the table

and produced to the sender and receiver, proper handling of the table is a must.

In the pro%ect, login table is designed to be unique in accepting the username and the

length of the username and password should be greater than 0ero. Both the user and

intruder username are stored in the same table with different flag values.

CHAPTER Vi


30/51

2

6. SYSTE TESTING AND IPLEENTATION

6.1 S&st!( T!stin-

It is the stage of implementation, which ensures that system wor's accurately

effectively before the live operation 3ommences. It is a confirmation that all are correct

opportunity to show the users that the system must be tested with tet data and show that

system will operate successfully and produce epected results under epected conditions.

Before implementation, the proposed system must be tested with raw data to ensure the

modules of the system wor' correctly and satisfactorily. The system must be tested with

data to achieve its ob%ective.

The purpose of system testing is to identify and correct errors in the candidate

system. &s important as this phase is, it is one that is frequently compromised.

Typically, the pro%ect the schedule or the user is eager to go directly to conversion.

&ctually, testing is done to achieve the system goal. Testing is vital to the parts of the

system are correct= the goal will be successfully achieved. Inadequate testing or non+

testing leads to errors that may not appear until months later.

This creates two problems

• The time lag between the cause and appearance of the problem.

• The effect of system errors on files and records within the system. & small system

error can conceivable eploded into larger problem. Effectively early in the

process translates directly into long term cost savings from a reduced number of

errors.

6.1.1 Unit t!stin-


31/51


32/51

2

• Eercise all logical decisions on their true and false sides.

• Eecute all loops at their boundaries and within their operational bounds.

6.1.8 %$" 0o, t!stin-

Blac' bo testing methods focus on the functional requirements of the software.

Blac' bo testing attempts to find errors in the following categories.

• Incorrect or missing function.

• Interface errors. Errors in data structure or eternal database access.

Ferformance errors. Initiali0ation and termination errors.

6.1. V$%i$tion t!stin-

Jenerally a validation succeeds when the software functions in a manner that can

be reasonably epected by customer.

The validation procedures are designed to chec' each record, data item, field

against certain criteria. If acceptability criteria is missing then whole of an error message.

&ll the above said tests are considerably carried out in the system and each and

every part of the software has been tested and validated, such that all the ma%or and minor

level errors are rectified.

6.2 SYSTE IPLEENTATION

In this pro%ect, propose virtual 0ing -arvard architecture on top of the eisting

memory architecture of modern computers, including those without non+eecutable

memory page support, so as to prevent the in%ection of malicious code entirely.

-arvard architecture is simply one wherein code and data are stored separately.

ata cannot be loaded as code and vice+versa. In essence, users create an environment


33/51

22

where in any code in%ected by an attac'er into a process4 address space cannot even be

addressed by the processor for eecution.

In this way, user is attac'ing the code in%ection problem at its root by regarding the

in%ected malicious code as data and ma'ing it unaddressable to the processor during an

instruction fetch. "plit memory architecture produces an address space where data cannot

be fetched by the processor for eecution. /or an attac'er attempting a code in%ection,

this will prevent him from fetching and eecuting any in%ected code.

6.2.1 S&st!( S!"urit&

& security eploit is a prepared application that ta'es advantage of a 'nown wea'ness.

Fassword crac'ing is the process of recovering passwords from data that has been stored in or

transmitted by a computer system. & common approach is to repeatedly try guesses for the password. & typical approach in an attac' on Internet+connected system is

>etwor' enumeration iscovering information about the intended target.

Pulnerability analysis: Identifying potential ways of attac'.

Eploitation: &ttempting to compromise the system by employing the vulnerabilities

found through the vulnerability analysis.

In order to do so, there are several recurring tools of the trade and techniques used by

computer criminals and security eperts.


34/51

2:

8.3 Coin-:

using System;using System.Data;using System.Configuration;

using System.Web;using System.Web.UI;using System.Web.UI.WebControls;using System.Web.UI.WebControls.WebParts;using System.Web.UI.HtmlControls;using System.Drawing;using System.Windows.Forms;using System.Data.SqlClient;

publi partial lass !Default " System.Web.UI.Page #

string ConnString $Configuration%anager.&ppSettings'(ConnetionString().*oString+,; publi SqlConnetion Conn; publi SqlCommand md;

proteted -oid Page!oad+ob/et sender0 1-ent&rgs e, # if +2Page.IsPost3a4, # *5tUser6ame.Fous+,; Di-Seret.7isible $ false; 8

8 proteted -oid 3tnogin!Cli4+ob/et sender0 1-ent&rgs e, # try # string retri-eString $ (Selet User6ame0Company6ame0emailid0 Userpassword0 Seurity9uestion0Seurity&nswer from usertable w:ere 1mailid$( <*5tUser6ame.*e5t.*oower+, < ( and UserPassword$( <*5tPwd.*e5t.*oower+, < ((;

Conn $ new SqlConnetion+ConnString,; md $ new SqlCommand+retri-eString0 Conn,; SqlData&dapter da $ new SqlData&dapter+md,; Conn.=pen+,; SqlData>eader red $ md.15eute>eader+,; if +red.>ead+,, #


35/51

27

if +*5tUser6ame.*e5t.*oower+, $$red'?).*oString+,.*oower+,, # Session'(User6ame() $ red'@).*oString+,; Session'(User%ailid() $ red'?).*oString+,;

Session'(Company6ame() $ red'A).*oString+,; Session'(t5tUserPwd() $ red'B).*oString+,; Session'(Seurity9() $ red').*oString+,; Session'(Seurity&ns() $ red').*oString+,; Session'(Company%ailid() $ (E( <red'A).*oString+, < (.om(; string rr $ (E( < red'A).*oString+, < (.om(; Conn.Close+,; if +Session'(UserHa41nter() 2$ null, # Di-Seret.7isible $ true; t5tSeret&ns.Fous+,; lblSeret9.*e5t $Session'(Seurity9().*oString+,; return; 8 Session'(UserHa41nter() $ null; >esponse.>ediret+(HomePage.asp5(0 false,; 8 else Conn.Close+,; 8 else

# string retri-eStringA $ (Selet Userpassword fromusertable w:ere 1mailid$( < *5tUser6ame.*e5t.*oower+, < ((; Conn $ new SqlConnetion+ConnString,; md $ new SqlCommand+retri-eStringA0 Conn,; SqlData&dapter daA $ new SqlData&dapter+md,; Conn.=pen+,; SqlData>eader redA $ md.15eute>eader+,; if +redA.>ead+,, Session'(t5tUserPwd() $ redA'@).*oString+,; red.Close+,;

redA.Dispose+,; if +Session'(t5tUserPwd() 2$ null, # if +Session'(t5tUserPwd().*oString+,.Substring+@0 ?,.*oUpper+, $$*5tPwd.*e5t.*rim+,.Substring+@0 ?,.*oUpper+,, # Session'(UserHa41nter() $ (es(;


36/51


37/51

2<

>esponse.>ediret+(&dmin.asp5(0 true ,; 8 else

Conn.Close+,; 8

else # string retri-eStringA $ (SeletCompany6ame0ompanypassword from Companydetails w:ereCompany6ame$( < *5t>ig:tUser6ame.*e5t.*oower+, < ((; Conn $ new SqlConnetion+ConnString,; md $ new SqlCommand+retri-eStringA0 Conn,; SqlData&dapter daA $ new SqlData&dapter+md,; Conn.=pen+,; SqlData>eader redA $ md.15eute>eader+,; if +redA.>ead+,, Session'(ompanypassword() $ redA'A).*oString+,; redA.Close+,; redA.Dispose+,; if +Session'(ompanypassword() 2$ null, # if +Session'(ompanypassword().*oString+,.Substring+@0 ?,.*oUpper+,$$ *5t>ig:tPassword.*e5t.Substring+@0 ?,.*oUpper+,, #

string insertquery $ (insert into :a4erslist+userid0userpwd0atta4time0atta4date, -alues +( <*5t>ig:tUser6ame.*e5t.*oower+, < (0( <

*5t>ig:tPassword.*e5t.*oower+, < (0( <System.Date*ime.6ow.*ime=fDay.*oString+, < (0( <System.Date*ime.*oday.Date.*oS:ortDateString+, < (,(;

md $ new SqlCommand+insertquery0 Conn,;md.15eute6on9uery+,;

Conn.Close+,; 8 8 bl>ig:t1rror.*e5t $ (In-alid User6ame G Password(; 8

8

proteted -oid 3tn>ig:tCanel!Cli4+ob/et sender0 1-ent&rgs e, # >esponse.>ediret+(login.asp5(,; 8


38/51

2H

proteted -oid rb&dmin!C:e4edC:anged+ob/et sender01-ent&rgs e, # try #

if +rb&dmin.C:e4ed $$ true, # >ig:tsContent.7isible $ true; Useroginontent.7isible $ false; Di-Seret.7isible $ false; 8 else # >ig:tsContent.7isible $ false; Useroginontent.7isible $ true; Di-Seret.7isible $ false; 8 8 at: +15eption e5, # %essage3o5.S:ow+e5.%essage,; 8 8

proteted -oid rbUser!C:e4edC:anged+ob/et sender0 1-ent&rgse, # try

# if +rbUser.C:e4ed $$ true, # >ig:tsContent.7isible $ false;

Useroginontent.7isible $ true; Di-Seret.7isible $ false; 8 else # >ig:tsContent.7isible $ true; Di-Seret.7isible $ false;

8 8 at: +15eption e5, # %essage3o5.S:ow+e5.%essage,; 8 8


39/51

26

proteted -oid btn=4!Cli4+ob/et sender0 1-ent&rgs e, # try # if +Session'(Seurity&ns().*oString+,.*oUpper+, $$

t5tSeret&ns.*e5t.*oUpper+,, # Session'(UserHa41nter() $ null; >esponse.>ediret+(HomePage.asp5(0 false,; 8 else # %essage3o5.S:ow+(Seurity answer does notmat:.(,; t5tSeret&ns.Fous+,; 8 8 at: +15eption e5, # %essage3o5.S:ow+e5.%essage,8

LE"!$T"

The results obtained for implementation are shown below


40/51

:

/igure A.1. log in form

The above screen shows the log in form for both admin and user where the activities are

performed by them.


41/51

:1

/ig A.

&ccess Lights


42/51

:

/ig A.2

3ompany registration


43/51

:2

/igA.A user log in form

9i- 8. Us!r $i%


44/51

::

The above fig shows the sent items right is denied by admin to that user.where the user cant

view the sent items .

9i- 8. R!)orts


45/51

:7

CHAPTER VII

CONCLUSION AND 9UTURE ENHANCEENT

8.1.Con"%usion

The intrusion detection system that builds models of normal behavior for multitiered web

applications from both front+end web (-TTF) requests and bac'+end database ("#$) queries.

!nli'e previous approaches that correlated or summari0ed alerts generated by independent I"s,

oubleJuard forms container+based I" with multiple input streams to produce alerts. We have

shown that such correlation of input streams provides a better characteri0ation of the system for

anomaly detection because the intrusion sensor has a more precise normality model that detects a

wider range of threats.

We achieved this by isolating the flow of information from each webserver session with a

lightweight virtuali0ation. /urthermore, we quantified the detection accuracy of our approach

when we attempted to model static and dynamic web requests with the bac'+end file system and

database queries. /or static websites, we built awell+correlated model, which our eperiments

proved to be effective at detecting different types of attac's. 8oreover, we showed that this held

true for dynamic requests where both retrieval of information and updates to the bac'+end

database occur using the webserver front end.

When we deployed our prototype on a system that employed &pache webserver, a blog

application, and a 8y"#$ bac' end, ouble Juard was able to identify a wide range of attac's

with minimal false positives. &s epected, the number of false positives depended on the si0e

and coverage of the training sessions we used. /inally, for dynamic web applications, we

reducedthe false positives to .A percent.


46/51

:A

8.2. 9utur! En'$n"!(!nt

The double guard intrusion detection system where the number of false positives depends on the

si0e and coverage of the training sessions. /inally, for dynamic web applications, the false

positive was .A percent. In /uture for dynamic web applications, the false positive should be

less than .A percent say for eample .1 percent such that we can ensure a complete security

system which detects intrusions in the mulitiered applications with full efficiency.


47/51

:<

RE9ERENCES

91; 8eiing $e,&ngelos "tavrou,8ember,IEEE,&> Brent Byung-oon 'ang, member, IEEED

oubleguardetecting intrusions in 8ultitier Web &pplications, PF$ 6,no :, %uly&ugust

1

9; . Wagner and . ean, CIntrusion etection via "tatic &nalysis,DFroc. "ymp. "ecurityand Frivacy (""F 41), 8ay 1.

92; T. Perwoerd and L. -unt, CIntrusion etection Techniques and &pproaches,D 3omputer

3omm., vol. 7, no. 17, pp. 127A+12A7, <

9:; 8. 3ova, . Bal0arotti, P. /elmetsger, &n &pproach for the &nomaly+Based etection of

"tate Piolationsin Web &pplications,D Froc. Int4l "ymp. Lecent &dvances in Intrusion

etection (L&I 4


48/51

:H


49/51

:6


50/51


51/51

71

sql injection krishna report

Documents