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

change pasword
view details
amount transaction

positive tainting
syntax-aware

admin
injection found

No injection or
user WASP injection
customer

admin

tarnsastion detail
New Registraton
amount credit

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

5
development, it is useful to distinguish between the baseline functionality necessary for
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.

+provides
customer

admin db

11
4.4 Class Diagram

Cerdit Card
CreditProcess

Accnumber()
Bill process()
Password()

dit
cre

cre
CustomerHome
Customer Login

dit
Database
Accnumber()
User details()
password() customer customer
Transaction()
check()
update()
delete()
insert()
in
Adm Admin Home

Admin Ad Reistration()
mi transation()
n
customer details()
username() Amount credit()
password()

12
4.5 Detailed Use cases
4.5.1. Usecase1: functionalities of admin:

login

+enter username and password

registration
provides

admin +performs

check transaction

performs

customer details

amount credit

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:

view the details

customer
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
 login

view details
customer

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