PRASAD V.POTLURI SIDDHARTHA INSTITUTE OF TECHNOLOGY, KANURU, VIJAYAWADA.

Software Requirements Specification

On

SQLIVs THWARTER

Submitted by

P.VIJAYA LAKSHMI

(07501A1266)

J.S.N.SASANK B.AMMAJI (07501A1280) (07501A1287)

K.MAINKYA RAO

(07501A1279)

BATCH NO: 24

2010-2011

Under the guidance of

Dr.J.Rajendra Prasad , M.tech., Ph.D.,

HEAD OF THE DEPARTMENT

DEPARTMENT OF INFORMATION TECHNOLOGY

Signature of guide

Table of Contents

1.0 Purpose of the system…………………………………………………………..….2

1.1. Introduction…………………………………………………………………….…2

1.2. Scope…………………………………………………………………………........2

1.3. Document overview………………………………………………………….…....3

1.4. Web references………………………………………………………………….…3

2.0 Overall description………………………………………………………….……...4

2.1. System environment………………………………………………………….…....4

2.2. Requirements……………………………………………………………………....5

2.3 Functional requirements…………………………………………………………....5

2.4. Non-functional requirement……………………………………………………………….6

3.0 Analysis model for our project…………………………………………………………….8

4.Design………………………………………………………………………………….8

4.1 Introduction to uml…………………………..………………………………………….…9

4.2 System Design……………………………………………………………………….…….10

4.3 Use case Diagram…………………………………………………………………………10

4.4 Class Diagram………………………………………………………………….…….….. 12

4.5 Detailed Use cases ………………………………………………………………....…….13

4.5.1. Usecase1: functionalities of admin………………………………………...13.

4.5.2. Usecase2: functionalities of customer.....…………………………………..14

4.5.3. Usecase3: bill processing by Credit card…………………………………..16

4.6 system evolution………………………………………………………………… 17

1

1.0. Purpose of the system

1.1. Introduction

A Software Requirement Specification (SRS) is the starting point of the

software developing activity. It is a complete description of the behavior of a system to be

developed. It includes a set of use cases that describe all the interaction the users will have with

the software. It is a complete description of the behavior of a system to be developed. It

includes set of use cases that describe all the interactions the users will have the software. Main

aim of organizations are protecting their precious data. The major issue of web application

security is the SQL Injection, which can give the attackers unrestricted access to the database

that underlie Web applications. Many software systems have evolved to include a Web-based

component that makes them available to the public via the Internet and can expose them to a

variety of Web-based attacks. One of these attacks is SQL injection, which can give attackers

unrestricted access to the databases that underlie Web applications and has become

increasingly frequent and serious.

In this paper, we propose SQL injection vulnerabilities (abbreviated as

SQLIVs) architecture for protecting Web applications against SQL injection that has both

conceptual and practical advantages over most existing techniques. From a conceptual

standpoint, the approach is based on the novel idea of positive tainting and on the concept

of syntax-aware evaluation. From a practical standpoint, our technique is precise and

efficient, has minimal deployment requirements, and incurs a negligible performance

overhead in most cases.

1.2. Scope

We can effectively provide the security to the database. SQLIVs Thwarter

provides the security to web applications by using WASP (web application SQL

injection preventer) tool. This system mainly consists of four modules:

1. Admin

2. Customer details

3. Credit card

4. Loan

2

1.3. Document overview

The remainder of this document is two chapters; the first provides a full description of

the project for the administrator, which lists all the functions performed by the system.

The final chapter contains details of each of the system functions and actions in full for

the software developers’ assistance. These two sections are cross-referenced by topic; to

increase understanding by both groups involved.

1.4. Web References

1. S.W. Boyd and A.D. Keromytis, “SQLrand: Preventing SQL Injection Attacks,” Proc.

Second Int’l Conf. Applied Cryptography and Network Security, pp. 292-302, June 2004.

2. G.T. Buehrer, B.W. Weide, and P.A.G. Sivilotti, “Using Parse Tree Validation to

Prevent SQL Injection Attacks,” Proc. Fifth Int’l

Workshop Software Eng. and Middleware, pp. 106-113, Sept. 2005

3. J. Clause, W. Li, and A. Orso, “Dytan: A Generic Dynamic Taint Analysis

Framework,” Proc. Int’l Symp. Software Testing and Analysis, pp. 196-206, July 2007.

4. W.R. Cook and S. Rai, “Safe Query Objects: Statically Typed Objects as Remotely

Executable Queries,” Proc. 27th Int’l Conf.

Software Eng., pp. 97-106, May 2005.

5. “Top Ten Most Critical Web Application Vulnerabilities,” OWASP Foundation,

http://www.owasp.org/documentation/

topten.html, 2005.

3

2.0 Overall description

SQLIVs Thwarter mainly deals with the web application security. To provide this

security we developed a web application SQL-injection preventer (WASP) tool. which

we used to perform an empirical evaluation on a wide range of Web applications that we

subjected to a large and varied set of attacks and legitimate accesses. WASP was able to

stop all of the otherwise successful attacks and did not generate any false positives.

2.1. System environment

The user, administrator are connected to the WASP tool in the system environment. The

user and admin with valid username and password login and process it. The administrator

by connecting with the system, he maintain database of user and maintain security. The

customers by connecting with system can edit or add details. The module diagram for the

SQL injection vulnerabilities Thwarter.

4

2.2 Requirements

Hardware Requirements:

Processor : Any Processor above 500 MHz.

Ram : 128Mb.

Hard Disk : 10 GB.

Input device : Standard Keyboard and Mouse.

Output device : VGA and High Resolution Monitor.

Software requirements:

Operating System : Windows Family.

Pages developed using : Java Server Pages and HTML.

Techniques : Apache Tomcat , JDK 1.5 or higher

Web Browser : Microsoft Internet Explorer.

Data Bases : SQlServer 2000

Client Side Scripting : Java Script

2.3. Functional requirements

Functional Requirements are those that refer to the

functionality of the system, i.e., what services it will provide to the user. Functional

requirements capture the intended behavior of the system. This behavior may be

expressed as services, tasks or functions the system is required to perform. In product

development, it is useful to distinguish between the baseline functionality necessary for

5

any system to compete in that product domain, and features that differentiate the system

from competitors’ products, and from variants in your company’s own product

line/family. Features may be additional functionality, or differ from the basic

functionality along some quality attribute (such as performance or memory utilization).

The precondition for to use the SQLIVs Thwarter architecture is the

admin must had register and access there account. After that user can access menu like

view details, view balances .

The precondition for to use the happi architecture is the user must had

register and access there account. After that user can access menu like view details, edit

details and add details.

2.4. Non-functional requirements

There are requirements that are not functional in nature.

Specifically, these are the constraints the system must work within. The user and vendor

must be registered in the application before using the system. This Supplementary

Specification lists the requirements that are not readily captured in the use cases of the

use-case model The Supplementary Specifications and the use-case model together

capture a complete set of requirements on the system. In general, functional requirements

define what a system is supposed to do whereas non-functional requirements define how

a system is supposed to be. Functional requirements are usually in the form of "system

shall <do requirement>", while non-functional requirements are "system shall be

<requirement>".Non-functional requirements are often called qualities of a system.

Other terms for non-functional requirements are "constraints", "quality attributes",

"quality goals", "quality of service requirements" and "non-behavioral requirements".

Qualities, that is, non-functional requirements, can be divided into two main categories:

1. Execution qualities, such as security and usability, which are observable at run

time.

2. Evolution qualities, such as testability, maintainability, extensibility and

scalability, which are embodied in the static structure of the software system.

Scope:

6

We can effectively provide security to the data in the darabase. SQLIVs

Thwarter solves the security problem by using WASP tool.

Usability:

Ease-of-use requirements address the factors that constitute the capacity of

the software to be understood, learned, and used by its intended users. Hyperlinks will be

provided for each and every service the system provides through which navigation will

be easier. A system that has high usability coefficient makes the work of the user easier.

This section lists all of those requirements that relate to, or affect the usability of the

system.

Design for ease of use:

The user interface of the SQLIVs Thwarter architecture shall be designed

for ease-of-use and shall be appropriate for a computer-literate user community with no

additional training on the System. For the beginners it needs training on how to view the

items and how to select and buy the products.

Flexibility:

If the organization intends to increase or extend the functionality of the software

after it is deployed, that should be planned from the beginning; it influences choices made during

the design, development, testing, and deployment of the system. New modules can be easily

integrated to our system without disturbing the existing modules or modifying the logical

database schema of the existing applications.

Integrity:

Integrity requirements define the security attributes of the system, restricting

access to features or data to certain users and protecting the privacy of data entered into

the software. Certain features access must be disabled to user such as modifying the

details of companies which is the sole responsibility of the administrator. Access can be

disabled by providing appropriate login screens for users and administrator separately.

Performance:

The performance is high when compared to others as it utilizes Heisenberg’s

algorithm whose efficiency is far better. Whereas this application doesn’t need any

7

external a resource hence working with it is easy by just using the appropriate software

which is compatible. And even the result can be computed faster

Security:

It can be used by any user at a time it provides authentication to the user.

3.0. Analysis model for our project

Software process is a framework for the tasks that are required to build

high-quality software. Software engineers and their managers adapt the process to their

needs and then follow it. As it provides stability, one can control the software

development. Processes that you adopt depend on the software you’re building.

We have different process models, they are

The Linear Sequential Model

The Prototype Model

The Spiral Model

The Incremental Model

In our project “SQLIVs THWARTER” we are using Incremental model.

We are following the Incremental model because predicting missing items in customer

details be developed in a series of incremental steps. As a part of incremental model, the

system includes user entering the input item set followed by system prediction.

Generates working software quickly and early during the software life

cycle. More flexible - less costly to change scope and requirements. Easier to test and

debug during a smaller iteration. Easier to manage risk because risky pieces are identified

and handled during its iteration.

4. Design

System design is the process of applying various techniques and principles of

defining a system in sufficient detail to permit its physical realization. Software design is

8

the kernel of the software engineering process. Once the software requirements have been

analyzed and specified, the design is the first activity.

4.1 Introduction to UML

The Unified Modeling Language allows the software engineer to express an

analysis model using the modeling notation that is governed by a set of syntactic

semantic and pragmatic rules. A UML system is represented using five different views

that describe the system from distinctly different perspective. Each view is defined by a

set of diagram, which is as follows.

User Model View

i. This view represents the system from the users perspective.

ii. The analysis representation describes a usage scenario from the

end-users perspective.

Structural model view

i. In this model the data and functionality are arrived from inside the

system.

ii. This model view models the static structures.

Behavioral Model View

It represents the dynamic of behavioral as parts of the system, depicting

the interactions of collection between various structural elements

described in the user model and structural model view.

Implementation Model View

In this the structural and behavioral as parts of the system are represented

as they are to be built.

Environmental Model View

In this the structural and behavioral aspects of the environment in which

the system is to be implemented are represented.

UML is specifically constructed through two different domains they are:

9

UML Analysis modeling, this focuses on the user model and structural model

views of the system.

UML design modeling, which focuses on the behavioral modeling,

implementation modeling and environmental model views.

4.2 System design

Module Description:

1. Admin

In this module admin login only when the username and password are

valid. If admin login successfully then he provides other sub modules like registration,

transaction, customer details, amount credit information

2. Customer details

In this module customer want to access the details he has to login successfully

then it contains other sub modules. If the customer want to change the details i.e.

changing password, editing information about customer are possible.

3. Credit card

Customer want to pay he bill by using the card then the bill is processed

only when the customer is a authorized one.

4. Loans

In this module viewer can see what the loans available in this bank are and

get the details of the loans. This module can see any one who accessing the application

4.3 Use case Diagram

Use case Diagrams represent the functionality of the system from a user’s

point of view. Use cases are used during requirements elicitation and analysis to represent

the functionality of the system. Use cases focus on the behavior of the system from

external point of view. Actors are external entities that interact with the system.

10

Examples of actors include users like administrator, bank customer …etc., or another

system like central database.

Any user can view the products and can perform the following

functions like selecting the products .But only registered users can purchase the products

by performing login operation and provide feedback.

Administrator maintains user details and the products information and

gets the feedback from the user and provides login to the user.

customer

admin

+provides

db

11

4.4 Class Diagram

12

4.5 Detailed Use cases

4.5.1. Usecase1: functionalities of admin:

admin

login

registration

transaction

customer details

amount credit

+enter username and password

provides

+performs

check

performs

Brief description:

The functionalities performed by the end user are:-

1. User Registration.

2. View Details.

3. View Transaction.

4. Credit amount.

Use Case Name

Functionalities of admin

Priority Essential

13

Trigger Menu selection

Precondition The admin must be registered.

Basic Path 1. The admin must provide the registration to the users.

2. The admin must check the customer details.

Alternate Path N/A

Post condition The details are posted into the database.

Exception Path given data is injecting the present query or

not .if it injected the query it not send the

value to data base and return to the same

page.

4.5.2 Usecase2: functionalities performed by customer:

customer

view the details

transaction

14

Brief description:

The functionalities performed by the Vendor are:

1. View Details.

2. Transaction.

Use Case Name

Functionalities of customers

Priority Essential

Trigger Menu selection

Precondition The customer must be registered.

Basic Path 1. The customer able to view the customer details.

2. The customer checks the transaction

Alternate Path N/A

Post condition The details are posted into the database.

Exception Path given data is injecting the present query or

not .if it injected the query it not send the

value to data base and return to the same

page.

4.5.3 Usecase3: : functionalities performed by customer by using credit card:

15

customer

login

view details

bill process

Brief description:

The functionalities performed by the utility companies are:

1. Login.

2. View Customer Details.

3. Process the bill.

Use Case Name functionalities performed by customer by using credit card

Priority Essential

Trigger Menu selection

Precondition The customer login must be successful.

Basic Path

1. customer can view the details.

2.process the bill if valid

16

Alternate Path N/A

Post condition The details are posted into the database.

Exception Path given data is injecting the present query or

not .if it injected the query it not send the

value to data base and return to the same

page.

4.6 System Evolution

The objectives of this maintenance work are to make sure that the system

gets into work all time without any bug. Provision must be for environmental changes

which may affect the computer or software system. This is called the maintenance of the

system. Nowadays there is the rapid change in the software world. Due to this rapid

change, the system should be capable of adapting these changes. In our project the

process can be added without affecting other parts of the system. This system has been

designed to favor all new changes. Doing this will not affect the system’s performance or

its accuracy.

The project has covered almost all the requirements. Further requirements and

improvements can easily be done since the coding is mainly structured or modular in

nature. Improvements can be appended by changing the existing modules or adding new

modules. One important development that can be added to the project in future is file

level backup, which is presently done for folder level.

17

18