The Security Of Web Applications Computer Science Essay

Published: Last Edited:

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

The "Web" or World Wide Web is today used very often in everybody's life. Since its creation in the 1990s, the Web never ceased to grow and counted more and more web sites and web applications. Web application domain is currently in big expansion. We can see more and more application on the Web, such as webmails, bank services, etc. These applications can be very sensitives and store privates data. A security assessment by the Application Defense Center, which included more than 250 Web applications from e-commerce, online banking, enterprise collaboration, and supply chain management sites, concluded that at least 92% of Web applications are vulnerable to some form of attack. Because of this and because web applications can be reached by everybody connected to the Internet, web application security is both very important and very difficult to apply.

On October 4, 2005, the "Samy Worm" became the first major worm to use XSS for infection propagation. Overnight, the worm altered over one million personal user profiles on

On January 13, 2006, Russian computer criminals broke into a Rhode Island government web site and allegedly stole credit card data from individuals who have done business online with state agencies.

In December 2009, an attacker breached a RockYou! plaintext database containing the unencrypted usernames and passwords of about 32 million users by using a SQL injection attack.

The purpose of this lab is to show how a vulnerability in a web application can be exploited in various ways. We are going to locate and exploit two common web application vulnerabilities: SQL-injection and Cross-Site Scripting (XSS).


The web application used in this lab is a system where we have the ability to request the grade we wish to receive for the course along with a motivation why we should receive this grade. The administrator then has the ability to approve or disprove of your request. Our objective is to make sure our request is approved before the administrator has a chance to look at it.

For this, we will use vulnerabilities of the application using two techniques: SQL injection and XSS injection.

SQL Injection


SQL Injection consists in manipulating the query on the server side by inserting special characters in some user input or in the address bar. The hacker will to include and execute is own SQL query.

The main idea is to break the attended query. For instance, a form asks for the user and password. The attended query would be:

statement = "SELECT * FROM users WHERE name = '" + userName + " and password = "+ password +"';"

If the attacker enters his username following by a tautology and the comment character, such as "bob' OR 1=1;--", then the executed query will be:

SELECT * FROM users WHERE name = 'bob' OR 1=1;-- AND password = ''

This is the basic SQL injection. Often it's needed to be more complicated to succeed the attack. For example, you need to retrace the database structure.

In this part, we will explain how we succeed our SQL injection, the vulnerabilities of the web application and finally explain some protection mechanisms again SQL injection.

What kind of exploits can we do?

It exists two types of SQL injection. It can happen in a user input or the attacker can modify the parameters in the url. The form injection could be done using the motivation text area. The URL injection could be done when the web application loads the details of a request, via this URL: http://ws2008.lbs/webappsec/Details.aspx?request=4

The idea to succeed the exploit is to get the table structure where the request are stored, and then, inject a update query to set the attribute "approved" to true.

The first step is so to find how our exploit can succeed.

Obviously, if we try to insert SQL in the motivation field, then nothing abnormal happen.

However, if we try to add for instance one quote at the end of the URL, we'll have an error.

C:\Users\Romain\Desktop\Failure URL SQL injection.png

We are on the good way! And if we add "OR 1=1" at the end of the request, we can see all requests.

C:\Users\Romain\Desktop\OR 1=1.png

The exploit will definitely take place here.

Exploit the vulnerability

Find the information using error messages

The first step is to define the table structure, using error message. We will voluntarily raise errors.

C:\Users\Romain\Desktop\table name.png

The table name is tblUserGrade. Now, we are looking for each attributes in the table, until we found the one corresponding to the status of the grade (approved/refused).

C:\Users\Romain\Desktop\Group by userid.png

C:\Users\Romain\Desktop\group by approved.png

So we have this kind of schema:








We don't know the type of each attribute, but we can guess. If we have an error, we would see it.

Execute the query

We found the structure of the table, and we know where the vulnerability is. We just need know to build our query and finally inject it.

This is the query:

UPDATE tblUserGrade

SET approved='true'

WHERE userId='3c98426d-1e47-45cf-9215-e7177ec12cdb'

AND requestNr=20

C:\Users\Romain\Desktop\query succeed.png

Vulnerabilities and exploits

Several ways to achieve SQL injection exist.

Vulnerability using escaped characters: Such as our exploit, if SQL escaped character are not filtered, SQL injection will remain possible. This kind of exploit can be really dangerous because if the attacker know the database structure, he can potentially do a lot of things, such as update tuples.

Vulnerability using no strongly typed languages: If the developer use language without type checking, such as php, it can be source of attacks. For instance, if the function attends one number, and receives instead one number + one other query, there will be no errors in the code, and the second query will be executed.

Use xp_cmdshell: xp_cmdshell is a built-in extended stored procedure working with SQL Server that allows the execution of arbitrary command lines. For example:

exec master..xp_cmdshell 'dir'

will obtain a directory listing of the current working directory of the SQL Server process.

If we can run commands, the webserver cannot help to find SQL injection but be compromised. Access to xp_cmdshell is usually limited to administrative accounts, but it's possible to grant it to lesser users.

Blind SQL Injection: Sometimes, the vulnerability exists but there are no error messages. Hackers can still proceed some attacks but it will take more time and be more difficult since there is no error message so no indication about the database query.

Stored SQL queries: Sometimes, classical SQL injection are not possible since the web application is escaping special characters. It can still be possible to do attacks. The malicious code will not be executed immediately but stored in the database, ready to be executed. Here is a small example:

The criteria, entered by the user: ');DELETE Orders;--

The query generated by the web application will look like it, and will delete the tuples in the table Orders.

INSERT INTO favourites (UserID, FriendlyName, Criteria)

VALUES(123, 'My Attack', '');DELETE Orders;--')

Function call injection: Function call injection is the insertion of Oracle database functions or custom functions into a vulnerable SQL statement. These function calls can be used to make operating system calls or manipulate data in the database.

Buffer Overflow: A number of standard Oracle database functions are susceptible to buffer overflows, which can be exploited through a SQL injection attack in an un-patched database.

By exploiting the buffer overflow via a SQL injection attack, remote access to the operating system can be achieved. Besides, the web process will usually hang until the connection to the client is terminated, thus if the database is down, it makes a very effective denial of service attack.

From there, hackers can use these vulnerabilities to insert malicious queries. Kind of exploits are many and various:

Display all the data in the table: By making one condition still true, it can be possible to see all the data. For instance, if the query is

SELECT * FROM user WHERE id='$id' AND password='$password'

the attacker can give his id as "id OR 1=1 --". Thus, the query become

SELECT * FROM user WHERE id=id OR 1=1 -- (the end in comment)

and the attacker can see all the table user.

Schema field mapping: As we did for the assignment, one exploit is to map the structure of the database using error messages

Crack a log in form: By using the first exploit concept, it becomes possible to log in a web site without any password, even without any user id.

Update the database: Since we have the table structure and the vulnerability, it's possible to update current record, to insert new one or even delete some entries or tables in the database. We used the kind of exploit to succeed our attack and update the approved attribute.

Protection mechanisms against SQL injection

Sanitize the input: SQL injections come from user inputs. It's really important to control what the user write in the user inputs, but also what he can write in the address bar. He is not supposed to write here, but it can do it.

The developer should limit the size of the inputs to avoid overflow and injection. A first is not bigger than 20 characters in general.

Filter out special characters such as slash, backslash, quote, and extended characters such as NULL, carry return, new line in all strings from user input and parameters from URL.

When it's possible, the developer could refuse all inputs containing some known keywords such as "insert", "Select", etc.

It's important to verify the type of data inserted by the user.

The developer should NEVER build dynamic SQL statement directly from the user input and never concatenate user input, with SQL statements, which is not validated.

New programming language have built-in functionalities, called "parametriable queries" or "prepareted statements". The idea is to prepare a query is some special characters (usually '?') and replace the empty fields by the user input. The difference is that no SQL injection are possible since the user input will replace the '?' and never modify the structure of the query.

It's really hard, maybe impossible, to avoid all SQL vulnerabilities. It better to think SQL injection are possible, and protect the database in consequence. The access to the database can be reduced.

When you need to display some information, you could only use a "view", containing no critical information (no mail, no password, etc). Thus, if the attacker scan the view, he cannot use the structure to insert other tuple, he cannot see critical information, etc.

One important thing to do is to reduce the permission for the current user. If the website just need to see information, the developer should modify the permission to just allow read functionalities on the database. To reword, privileges of the user account used in the application for executing SQL statements on the database must be defined.

When the database server supports them, it's better to use stored procedures for performing access on the application's behalf, because, if the stored procedures themselves are written properly, it can eliminate SQL entirely in case of malicious code.

The developer should apply personalised error messages to control what is displayed in case of error. Thus, the attacker would not be able to find easily the database schema.

After applying everything, it's still possible to miss something and leave the server open to compromise. If the hacker enters the network it should never take complete control of the webserver. It would be better to protect the server, for instance by putting it in a DMZ. It means that if one attack happens, the hacker doesn't automatically grant full access to everything. This won't stop the attack, of course, but it makes it a lot harder.



Cross-Site Scripting or XSS attacks results in inserting malicious scripts into websites. Generally, malicious code is sent using form, and when one field is displayed, the malicious code is executed instead.

For instance, if the attacker add some malicious code in his comment, such as <body onload=alert('test1')>, and send the form, when the comment will be displayed, an alert box with the message "test1" will appear.

Thi part explains how we exploited the vulnerability in the web application to achieve the goal. We will also talk about existing XSS vulnerabilities and how to avoid them.

Is the Web application vulnerable?

The first step is to know if the web application is vulnerable, and the way to use to achieve the attack.

To produce XSS injection, we need that our own code be displayed. The only form we have access is the one for adding a request: we choose a grade, and write our motivation. We have to choose the grade in a list, but we can write anything in the text area corresponding to the motivation. Here will be the injection. We just need to check if it's vulnerable by submitting this motivation for instance: <body onload=alert('test1')>

When we display the details of the request, a alert message is shown with the text "test1". There is a vulnerability.

Exploit the vulnerability

The goal of the exploit is that our request would be accepted automatically by the administrator.

When we are on the details page, we can see two buttons: approve and refuse. By viewing the source code of the web page, we can see the function called after pressed on approve button: name of function.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">

<html xmlns="">


Lab 3 - Web application security


<script language="javascript" type="text/javascript">

// <!CDATA[

function a33c98426d(approve) {

var rand = 546404091;

document.location = 'Approve.aspx?request=' + 4 + '&rand=' + rand + '&id=' + '3c98426d-1e47-45cf-9215-e7177ec12cdb';


// ]]>




<form name="form1" method="post" action="Details.aspx?request=4" id="form1">


<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKMTQ4NDY4MzYxN2Rk3sb1ZjMhcmi8a9TkzdNVCRx7GV4=" />



<table><tr><td>userid</td><td>requestNr</td><td>grade</td><td>motivation</td><td>approved</td><td>dateCreated</td><td>dateModified</td></tr><tr><td>3c98426d-1e47-45cf-9215-e7177ec12cdb</td><td>4</td><td>4</td><td>' having 1=1--</td><td>True</td><td>2010-05-04 11:29:58</td><td>2010-05-04 11:29:58</td></tr></table>

<input id="approve" type="button" value="Approve" onclick="a33c98426d(true)" />

<input id="reject" type="button" value="Reject" onclick="a33c98426d(false)" />





The only thing to do is to call the approve function, with "true" as parameter, when the page is loaded. Thus, when the administrator will go on the request page, the request will be automatically approved, because the approve function will be called.

<script type="text/javascript">a33c98426d(true) </script>

Vulnerabilities and exploits

Two kinds of vulnerabilities

Non Persistent or Reflected vulnerability: It is by far the most common type. It occurs when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to generate a page of results for that user, without properly sanitizing the response.

Persistent or stored vulnerability: It occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping. Our attacks fits more with the persistent vulnerability since the malicious code is stored on the database and executed each time the page is loaded, by anyone.

Just as before, many kind of exploits can be found:

Identity theft

Accessing sensitive or restricted information

Gaining free access to otherwise paid for content

Spying on user's web browsing habits

Altering browser functionality

Public defamation of an individual or corporation

Web application defacement

Denial of Service attacks

Finally, here is a small scenario of how exploits can occurs, both for the persistent attack and the non persistent attack.

Non-persistent attack:

Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to log in with a username/password pair and store sensitive information, such as billing information.

Mallory observes that Bob's website contains a reflected XSS vulnerability.

Mallory crafts a URL to exploit the vulnerability, and sends Alice an email, enticing her to click on a link for the URL under false pretenses. This URL will point to Bob's website, but will contain Mallory's malicious code, which the website will reflect.

Alice visits the URL provided by Mallory while logged into Bob's website.

The malicious script embedded in the URL executes in Alice's browser, as if it came directly from Bob's server (this is the actual XSS vulnerability). The script can be used to send Alice's session cookie to Mallory. Mallory can then use the session cookie to steal sensitive information available to Alice (authentication credentials, billing info, etc) without Alice's knowledge.

Persistent attack:

Mallory posts a message with malicious payload to a social network.

When Bob reads the message, Mallory's XSS steals Bob's cookie.

Mallory can now hijack Bob's session and impersonate Bob.


Protection mechanisms against XSS injection

To avoid XSS injection, there is no perfect protection, but there are above all good programming practices. The following point are the main rules to respect to be more protected.

RULE #0 - Never Insert Untrusted Data Except in Allowed Locations

RULE #1 - HTML Escape Before Inserting Untrusted Data into HTML Element Content

RULE #2 - Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes

RULE #3 - JavaScript Escape Before Inserting Untrusted Data into HTML JavaScript Data Values

RULE #4 - CSS Escape Before Inserting Untrusted Data into HTML Style Property Values

RULE #5 - URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values

RULE #6 - Use an HTML Policy engine to validate or clean user-driven HTML in an outbound way

RULE #7 - Prevent DOM-based XSS



It's very important to test the web site or web application against any kind of injections. Attacks by injection represent 25% of the web application attacks. If the site is very sensitive, it's also possible to ask external organisation to do security audits.

It's impossible to have a web application without any bug. During the last week, an important privacy bug was found in the web application Facebook.

Stay alert, solve all issues you can see and have an specific attention on sensitive data.