SOFTWARE REQUIREMENT SPECIFICATION

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 J.S.N.SASANK (07501A1280)

B.AMMAJI B.AMMAJI (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

2

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

3

4. Loan

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.

4

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.

5

2.2 Requirements Hardware Requirements:

: Any Processor above 500 MHz.

•

Processor

•

Ram

: 128Mb.

•

Hard Disk 

: 10 GB.

•

Input device

: Standard Keyboard and Mouse.

•

Output device

: VGA and High Resolution Monitor.

Software requirements :

: Windows Family.

•

Operating System

•

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 

6

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 ", while non-functional requirements are "system shall be ".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:

7

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

8

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.

9

Software design is 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:

10

•

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.

11

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 db

admin

12

4.4 Class Diagram Cerdit Card

CreditProcess

Accnumber() Password()

Bill process()  d  i  t  c  r e

Customer Login Database Accnumber() password()

customer 

c    r    e    d     i     t    

CustomerHome

customer  check() update() delete() insert()  i n A d m

Admin

User details() Transaction()

Admin Home Reistration() transation() customer details() Amount credit()

A d   m i   n 

username() password()

13

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

14

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

15

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:

16

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

17

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

18

modules. One important development that can be added to the project in future is file level backup, which is presently done for folder level.

19