Automated Vulnerability Detection In Web Application Computer Science Essay

Published:

As the popularity of the web increases and web applications become tools of everyday use, the role of web security has been importance as well. Last few years have shown a significant increase in the number of web-based attacks. Automated vulnerability scanner verifies whether Web based applications are vulnerable or secure when they are subjected to malicious input data. Web scanner is a tool designed to discover security holes in your web applications that an attacker can access to your systems and data. It looks for multiple vulnerabilities including SQL injection, cross site scripting and weak passwords etc.

This paper demonstrates how easy it is for attackers to automatically discover and exploit web application-level vulnerabilities in a large number of web applications. Using this research paper researcher can examine how vulnerability scanner work and components to implement any vulnerability scanner. This approach allows researcher/developer to develop an extensive good scanner.

Lady using a tablet
Lady using a tablet

Professional

Essay Writers

Lady Using Tablet

Get your grade
or your money back

using our Essay Writing Service!

Essay Writing Service

Keywords: SQL Injection, Cross Site Scripting, web crawler, Web Scanner, Penetration Testing, Web application vulnerability

2. INTRODUCTION

Web application is becoming more and more popular and important part of our lives. As the important role of web application, the web security is becoming critical. Because of the widely used of web, any web security vulnerability will mostly be observed and be exploited by hackers, and through which he can easily access the databases.

In computer security, the term vulnerability is applied to a weakness in a system that allows an attacker to violate the integrity of that system [1]. Vulnerabilities may result from weak passwords, software bugs, a computer virus or a script code injection, and a SQL injection.

Many web application security vulnerabilities result from generic input validation problems [10]. Examples of such vulnerabilities are SQL injection and Cross-Site Scripting (XSS).Although the majority of web vulnerabilities are easy to understand and to avoid, many web developers are, unfortunately, not security-aware. As a result, there exist a large number of vulnerable applications and web sites on the web. There are two main approaches to testing software applications for the presence of bugs and vulnerabilities [8]:

• In white-box testing, the source code of the application is analyzed in an attempt to track down defective or vulnerable lines of code. This operation is often integrated into the development process by creating add-on tools for common development environments.

• In black-box testing, the source code is not examined directly. Instead, special input test cases are generated and sent to the application. Then, the results returned by the application are analyzed for unexpected behaviour that indicates errors or vulnerabilities.

So far, white-box testing has not experienced widespread use for finding security flaws in web applications. An important reason is the limited detection capability of white-box analysis tools, in particular due to heterogeneous programming environments and the complexity of applications that incorporate database, business logic, and user interface components.

In practice, black-box vulnerability scanners are used to discover security problems in web applications. These tools operate by launching attacks against an application and observing its response to these attacks.

The main contributions of this paper are that we demonstrate how easy it is for attackers to automatically discover and exploit application-level vulnerabilities in a large number of web applications. Detecting vulnerabilities is generally not an easy task, and not all of the common vulnerabilities can be successfully detected by automated scanners. In addition, this paper helps you to suggest areas for Web Vulnerability Scanner tool improvement.

3. TYPICAL WEB ATTACKS\

SQL injection attack

SQL injection attacks are based on injecting strings into database queries that alter their intended use. This can occur if a web application does not properly filter user input [8]. There are many varieties of SQL. Most dialects are loosely based on the most recent ANSI standard SQL-92 .The typical unit of execution in the SQL language is the query, a collection of statements that are aimed at retrieving data from or manipulating records in the database. A query typically results in a single result set that contains the query results. Apart from data retrieval and updates, SQL statements can also modify the structure of databases using Data Definition Language statements ("DDL").

Lady using a tablet
Lady using a tablet

Comprehensive

Writing Services

Lady Using Tablet

Plagiarism-free
Always on Time

Marked to Standard

Order Now

A web application is vulnerable to an SQL injection attack if an attacker is able to insert SQL statements into an existing SQL query of the application. This is usually achieved by injecting malicious input into user fields that are used to compose the query. For example [7], consider a web application that uses a query such as the one shown in Listing 1 for authenticating its users.

SELECT ID,LastLogin FROM Users WHERE User = 'john' AND Password = 'doe '

Listing 1: SQL Injection Step 1

This query retrieves the ID and LastLogin fields of user "john" with password "doe" from table Users. Such queries are typically used for checking the user login credentials and, therefore, are prime targets for an attacker. In this example, a login page prompts the user to enter her username and password into a form. When the form is submitted, its fields are used to construct an SQL query (shown in Listing 2) that authenticates the user.

sqlQuery = "SELECT ID , LastLogin FROM Users WHERE User = '" + userName + "' AND Password = '" + password + "'"

Listing 2: SQL Injection Step 2

If the login application does not perform correct input validation of the form fields, the attacker can inject strings into the query that alter its semantics. For example, consider an attacker entering user credentials such as the ones shown in Listing 3.

User: ' OR 1=1 --

Password :

Listing 3: SQL Injection Step 3

Using the provided form data, the vulnerable web application constructs a dynamic SQL query for authenticating the user as shown in Listing 4.

SELECT ID, LastLogin FROM Users WHERE User = ''OR 1=1 -- AND Password = '

Listing 4: SQL Injection Step 4

The "--" command indicates a comment in Transact- SQL. Hence, everything after the first "--" is ignored by the SQL database engine. With the help of the first quote in the input string, the user name string is closed, while the "OR 1=1" adds a clause to the query which evaluates to true for every row in the table. When executing this query, the database returns all user rows, which applications often interpret as a valid login.

Cross-Site Scripting (XSS) attack

Cross-Site Scripting, or XSS (not to be confused with CSS or Cascading Style Sheets), allows attackers to inject client-side script in a web page [7]. The attacker injects script, such as JavaScript, VBScript, ActiveX, HTML, or flash into an application to try to get access to sensitive information Dynamic websites (using AJAX, Flex, for example) are vulnerable. Static websites are not at risk [8].

XSS attacks are generally simple to execute, but difficult to prevent and can cause significant damage. There exist two different types of XSS attacks: reflected and stored XSS attacks [7].

The most common one found in web applications today is called reflected XSS attack. Unfortunately, the search form on the web site fails to perform input validation, and whenever a search query is entered that does not return any results, the user is displayed a message that also contains the unfiltered search string. For example [8], if the user enters a search string "<i>Hello World<i>", the italics markers (i.e., <i>) are not filtered, and the browser of the user displays "No matches for Hello World" (note that the search string is displayed in italics).

This indicates that there is a reflected XSS vulnerability present in the application, which can be exploited in the following way. First, an attacker writes a JavaScript snippet that, when executed in a victim's browser, sends the victim's cookie to the attacker. Now, the attacker tricks the victim into clicking a link that points to the action target of the vulnerable form and contains the malicious script as URL (GET) parameter (as shown in Listing 5:).

www.myonline -banking .com/search .php?searchterm ={ attacker's script goes here}

Listing 5: Malicious XSS Link

When the user clicks on this link, the vulnerable application receives a search request similar to the previous one, where the search term was <i>Hello World<i>. The only difference is that now, the search term is the malicious script written by the attacker. Instead of a harmless phrase in italics, the victim's browser now receives malicious JavaScript code from a trusted web server and executes it. As a result, the user's cookie, which can contain authentication credentials, is sent to the attacker.

Lady using a tablet
Lady using a tablet

This Essay is

a Student's Work

Lady Using Tablet

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Examples of our work

This example also makes clear why the attack is called reflected; the malicious code arrives at the victim's browser after being reflected back by the server.

The second type of XSS attack is called stored XSS attack [8]. As its name suggests, the difference compared to the reflected attack is that the malicious script is not immediately reflected back to the victim by the server, but stored inside the vulnerable application for later retrieval.

Here in listing 6 is example of an XSS attack string which generates a page with arbitrary content on an XSS vulnerable site:

http://www.VulnerableSite.com/search?q=<iframstyle=height:100%;width=100%;border:none;transparent:none;position:absolute;top:0;left:0; src=http://www.AttackerSite.com/ >

Listing 6: Malicious XSS string

The attack string can be URL encoded so that the content is unreadable for the average Internet user. An attack is successful if a victim visits an URL containing the XSS attack. This can be achieved by e.g. E-mail from a sender in which the user has trust.

4. AUTOMATED VULNERABILITY DETECTION

Our Automated vulnerability scanner consists of four components. First the Crawling component that gathers a set of target web sites. Second Attack component launches the configured attacks against these targets. Third Analysis component examines the results returned by the web applications to determine whether an attack was successful. Finally Generate Report

Figure: 1 How Automated vulnerability scanner work

The web crawler interacts with web applications, and gathers information (e.g. web pages, form information) for detection engine. Detection engine constructs web request with some specified attacking code. Detection engine waits for the response and analyzes it, once the specified key words can be detected in the responded data, the vulnerability is identified.

4.1. Crawling Component

A Web crawler is a computer program that browses the World Wide Web in a methodical, automated manner. In this component, the crawler that operates as iteratively downloading a web page, processing it, and following the links in that page to other Web pages.

To start a crawling session, the crawling component of Scanner needs to be seeded with a root of web address. Using this address as a starting point, the crawler steps down the link tree, collecting all pages and included web forms during the process. The end result of crawling is a collection of Web pages, HTML or plain text at a central location.

Just as a typical web crawler, Scanner has configurable options for the maximum link depth, maximum number of pages per domain to crawl, maximum crawling time, and there is an option or function that drops external links.

4.2. Attack Component

After the crawling phase has completed, the attack component scans each page for the presence of web forms. The reason is that the fields of web forms constitute our entry points to web applications.

For each web form, we extract the action and the method (i.e., GETS or POST) used to submit the form content. Also, the form fields and its corresponding parameters are collected. Then, depending on the actual attack that is launched, appropriate values for the form fields are chosen. Finally, the form content is uploaded to the server specified by the action address (using either a GET or POST request). After that attacked server responds to such a web request by sending back a response page via HTTP.

Detecting Vulnerabilities

The most efficient way of finding vulnerabilities in web applications is manual code review. This technique is very time-consuming, requires expert skills, and is prone to overlooked errors. Therefore, security society actively develops automated approaches to finding security vulnerabilities. These approaches can be divided into two wide categories: black-box testing and white-box testing.

White-box analysis consists of examining the code with­out executing it. Developers can do this in one of two ways [4]: manually, during code inspections and reviews; or auto­matically, using automated analysis tools. Peers systematically examine the delivered code, search­ing for programming mistakes. Security inspections are the most effective way to minimize vulnerabilities in an application; they are a crucial procedure when developing software for critical systems.

Black-box testing [7] refers to the analysis of program ex­ecution from an external point of view. In short, it consists of comparing the software execution outcome with the ex­pected result. Testing is probably the most used technique for software verification and validation.

Penetration Testing

Penetration testing approach is based on simulation of attacks against web applications. Currently, penetration testing is implemented as black box testing. Thus the Scope of analysis is limited to HTTP responses. Actually black box penetration testing is working as following process [2]:

1. The first step is to identify all pages being part of the web application. This phase is crucial for black box testing as attacks could be launched only against recognized application Data Entry Points. This task can be fulfilled automatically (Using web crawlers),

2. The second step is to extract Data Entry Points (DEPs) from pages visited in the first step. The result is a set of DEPs to be analyzed.

3. The third step is simulation of attacks. Every parameter in every DEP is fuzzed with malicious patterns and used within an HTTP request to web application.

4. Finally every received HTTP response is scanned for indications of vulnerability. [2]

4.3. Analysis component

After an attack has been launched, the analysis component has to parse and interpret the server response. An analysis component uses attack-specific response criteria and keywords to calculate a confidence value to decide if the attack was successful or any false positives are possible.

4.4. Generate Report

In this module we generate report of which vulnerability found by penetrating testing in the web page. And report will generate category-wise and vulnerability-wise and risk level-wise.

5. CONCLUSIONS AND FUTURE WORKS

The main contribution of this research paper is to show how easy it is to automatically discover and exploit web application- level vulnerabilities in a large number of web applications. Many web application security vulnerabilities result from generic input validation problems [8]. Examples of such vulnerabilities are SQL Injection and Cross-Site Scripting (XSS). Although the majority of web vulnerabilities are easy to understand and avoid, many web developers are unfortunately not security-aware and there is general consensus that there exist a large number of vulnerable applications and web sites on the web [10]. Research proposed the flow of web vulnerability scanner that analyzes web sites for exploitable SQL and XSS vulnerabilities. Automated Vulnerability Detection method based on web crawling is proposed in this research paper. To the end, this paper helps you to suggest areas for Web Vulnerability Scanner tool improvement and it allows developer to develop an extensive good scanner.

In the future, our research will includes improving on detecting web security vulnerabilities. In order to build a better SQL injection and XSS vulnerability detection approach and more works on studying the complex-form analyzing, the attacking codes constructing and the response analyzing.

6. REFRENCES

[01] V. Suhina, S. Groš, Z. Kalafatić, Detecting vulnerabilities in Web applications by clustering Web pages (pp. 01-07) , Faculty of Electrical Engineering and Computing, University of Zagreb , Croatia

[02] Andrey Petukhov, Dmitry Kozlov. (2008) . Detecting Security Vulnerabilities in Web Applications Using Dynamic Analysis with Penetration Testing (pp. 01-05) , Dept. of Computer Science, Moscow State University. 

[03] Xin Wang, Luhua Wang, Gengyu Wei, Dongmei Zhang, Yixian Yang. (2010). Hidden Web Crawling For Sql Injection Detection (pp. 14-18) , Published by the IEEE. (978-1-4244-6769-3/10)

[04] Nuno Antunes , Marco Vieira. (2012). Defending against Web Application Vulnerabilities (pp. 66-72) , Published by the IEEE Computer Society. 0018-9162/12. Volume.-2.

[05] Jeremiah Grossman WhiteHat Security founder & CTO Website Vulnerabilities Revealed (pp. 08-14). WhiteHat Security. (2008)

[06] Vebjørn Moen, Andr´e N. Klingsheim, Kent Inge Fagerland Simonsen, Kjell Jørgen Hole. Vulnerabilities In E-governments. (pp. 01-04). University of Bergen.

[07] Dafydd Stuttard, Marcus Pinto. (2011). The Web application Hacker's Handbook Finding an Exploiting Security Flaws. second edition.

[08] Stefan Kals, Engin Kirda, Christopher Kruegel, Nenad Jovanovic. SecuBat: A Web Vulnerability Scanner. Secure Systems Lab, Technical University of Vienna.

[09] David Shelly, Randy Marchany, Joseph Tront. (2010). Closing the Gap: Analyzing the Limitations of Web Application Vulnerability Scanners. Virginia Polytechnic Institute and State University

[10] Katkar Anjali S , Kulkarni Raj B. (2012) Web Vulnerability Detection and Security Mechanism . (pp. 237-241). International Journal of Soft Computing and Engineering (IJSCE). ISSN: 2231-2307, Volume-2. 

[11] Kanganand Monika. Web Application Vulnerabilities and Detection. (pp. 02-05). U.I.E.T, Punjab University, Chandigarh, U.T, India

[12] Marco Vieira, Nuno Antunes, Henrique Madeira CISUC. Using Web Security Scanners to Detect Vulnerabilities in Web Services Department of Informatics EngineeringUniversity of Coimbra - Portugal

[13] Acunetix WVS (2004) . Acunetix web vulnerability scanner a real world review (pp. 02-20) Available at http://www.acunetix.com

[14]William G.J. Halfond, Shauvik Roy Choudhary, Alessandro Orso..Penetration Testing with Improved Input Vector Identification. (pp. 01-03). College of Computing ,Georgia Institute of Technology.