MIECT: Security 2014-15

Practical Exercise:XSS: Cross-Site Scripting

December 9, 2014 Due date: no date

Changelog

• v1.0 - Initial Version.

Introduction

Cross-Site Scripting (XSS) attacks are a kind of attacks within Web in-teractions where an attacker performs indirect attacks against Web clientsthrough a vulnerable Web application.

Script code deployed to Web browsers within ordinary Web interactions isoften filtered when coming from certain Web servers (blacklisted) or blockedby default unless coming from a trusted Web servers (whitelisted). In bothcases, the solution for an attacker to deploy malicious scripts to Web clientsis to lead clients to a trusted servers and to make clients download maliciousscripts from those servers. To achieve this, an attacker has two options:

1. Upload the scripts to some trusted Web pages, which will then providethose scripts to clients.

2. Redirect the client to a trusted Web page in such a way that theresulting page contains the script to upload to clients.

In the first case, the attacker will fill forms with script data instead of plain,non-active text. If such data is stored as is on the servers’ database andreproduced latter on within a dynamic Web page, then it can be executedby a client in the future.

In the second case, the attacker redirects the victim to a trusted Webserver which replicates part of the client input data (e.g. HTML parameters)as part of the dynamic Web page of the result. This way, an attacker can

1

inject a script as part of a Web server invocation URL.

For a quick example, check http://www.joaobarraca.com/page/teaching/security/xss/example.

1 Environment setup

For this project you should use the virtual machine provided for these classes,and available http://www.joaobarraca.com/page/teaching/security. Wewill be using software that is purposely vulnerable. Do not useyour own laptop!. Some software may already be installed into the virtualmachine. Please check it before installing.

The following actions should be taken:

1. Install openjdk-6-jdk and tomcat:apt-get install openjdk-6-jdk tomcat7

2. Deploy the WebGoat application:cd /var/lib/tomcat7/webappswget http://webgoat.googlecode.com/files/WebGoat-5.4.war

3. Add the required users for authentication purposes:edit file /etc/tomcat7/tomcat-users.xml and add the following en-tries to the <tomcat-users> section:

<user username="webgoat" password="webgoat" roles="webgoat_admin"/><user username="basic" password="basic" roles="webgoat_user,webgoat_basic"/><user username="guest" password="guest" roles="webgoat_user"/><user username="admin" password="admin" roles="admin,manager"/>

4. Restart the tomcat server:service tomcat7 restart

5. Proceed to http://localhost:8080/WebGoat/attack and use the We-bGoat application. The default usernames and passwords were the onesdefined previously (e.g., guest / guest).

2 Cross-Site Scripting

2.1 Stored XSS Attack

The Stored XSS Attack (or persistent) allows an attacker to place a maliciousscript (usually Javascript) into a webpage. Victims accessing the webpagewill render all scripts, including the one injected by the attacker. This attackis very common in place where information is shared between users through

2

1) Store maliciousScript 2) Get Page

(with malicious script)

3) Executemalicious

Script

Web Server

Figure 1: Stored XSS Attack

web technologies (e.g., forums). In these case, an attacker could compose anordinary message, and hide some script in its source code. All users accessingthat message would execute the exploit. Figure 1 depicts this attack.

WebGoat provides an application which is vulnerable to Stored XSS At-tacks. You can find it in the left menu, inside Cross-Site Scripting (XSS).

This application allows for users send messages to the system, which areafterwards presented in a Message List. This would be the case of a forum.

1. Add a simple message to the form and push Submit.

2. In the message field, instead of writing a text message, write HTML. 1

3. Now try with some javascript. Javascript code must be enclosed be-tween <script>...</script> HTML tags. 2

2.2 Reflected XSS Attack

A Reflected XSS attack is similar to the previous, but it is assumed that theattack is non-persistent. With this attack it becomes possible to manipulatethe browser DOM for a single user, or for multiple users which access a page

1This is not a XSS attack, but it is useful for understanding that the browser willprocess whatever is in the message field

2TIP: Remember the alert() javascript function.

3

1) Send maliciouslink

2) Get Page(using malicious link)

3) Process pagewith

injected code

Web Server

Figure 2: Reflected XSS Attack

through a specially crafted URL. Figure 2 depicts a typical attack scenario.

Proceed to the Reflected XSS Attack section of WebGoat. You willbe presented with a shopping form where one or more fields are not properlyvalidated for its content.

1. Find the vulnerable field which allows for injecting Javascript.

2. Find the HTML id of the vulnerable field and verify that you can includethe field in the URL of the webpage to set its initial content (e.g.,&field_name=value).

3. Build an URL with Javascript code in the vulnerable field. You willneed to encode the source code using the tool available at http://www.joaobarraca.com/page/teaching/security/xss/encode.

2.3 CSRF Attack

The Cross-Site Request Forgery (CSRF) attack consists in injecting codethat, using the credentials and capabilities of the browser viewing a givenobject, may attack another system. This attack can be used for simple DoS,tracking users, or invoke requests on systems with the identity of the victim.Figure 3 depicts a typical attack scenario.

4

1) Store maliciousscript

2) Get Page(with malicious script)

Chat Web Server

Bank Web Server

3) Execute malicious request

Figure 3: CSRF Attack

This exploits the fact that, for usability, functionality and performancepurposes, system cache authentication credentials in small tokens namedcookies. When a user accesses a service, such as a social sharing application,or a Online Banking solution, a session is initialised, and will be kept validfor a long period. Even if the user abandons the webpage. However, if theuser visits another page which has a CSRF exploit targeting the first page, itis possible to invoke services using the user identity, without his knowledge.This attack is frequently done using the <img> tag, however, other tags canbe used.

As an example, consider that a forum post contains the following content:

LOL. Essa foi boa Op. :)<img src=’http://banco.pt/transfer.jsp?amount=1000&to_nib=12345300033233’></img>

1. In WebGoat, access the CSRF section.

2. Using the CSRF technique, place an img using as src the URL ofthe session, adding the parameter transferFunds=4000. Submit themessage.

3. View the message. A green mark should appear in the left section ofthe webpage.

5

Further Reading

1. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

2. https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

3. http://html5sec.org

6