PRASAD V.POTLURI SIDDHARTHA INSTITUTE OF
PRASAD V.POTLURI SIDDHARTHA INSTITUTE OF
TECHNOLOGY, KANURU, VIJAYAWADA.
TECHNOLOGY, KANURU, VIJAYAWADA.
Software Requirements Specification
Software Requirements Specification
On
On
SQLIVs THWARTER
SQLIVs THWARTER
Submitted by
Submitted by
P.VIJAYA LAKSHMI P.VIJAYA LAKSHMI (07501A1266) (07501A1266) J.S.N.SASAJ.S.N.SASANK NK B.AMMAB.AMMAJIJI ((0077550011AA11228800) ) ((0077550011AA11228877)) K.MAINKYA RAO K.MAINKYA RAO (07501A1279) (07501A1279)
BATCH NO: 24
BATCH NO: 24
2010-2011
2010-2011
Under the guidance of
Under the guidance of
Dr.J.Rajendra Prasad , M.tech., Ph.D.,
Dr.J.Rajendra Prasad , M.tech., Ph.D.,
HEAD OF THE DEPARTMENT HEAD OF THE DEPARTMENT
DEPARTMENT OF INFORMATION TECHNOLOGY
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
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
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/
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.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
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.
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
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 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 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.
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
4.4 Class Diagram
Database check() update() delete() insert() Admin Home Reistration() transation() customer details() Amount credit() CustomerHome User details() Transaction() customer customer A d m i n Admin username() password() Customer Login Accnumber() password() A d m i n Cerdit Card Accnumber() Password() c r e d i t CreditProcess Bill process() c r e d i t4.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
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
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.
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.
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.
