Warning: This will be a long post but worth it!
XSS or Cross-Site Scripting can be described as commonly found website vulnerably. The types of vulnerabilities can be broken down into three sub-types:
Non-persistent / Reflected
Persistent / Stored
Here I will be explaining non-persistent and persistent attacks as they are more commonly found and easier to understand.
Simply put the difference between a persistent attack and non, is the attacks’ ability to become stored on the vulnerable server. A persistent XSS attack has the ability to serve potentially malicious code to anyone visiting that page, the attack is said to be ‘stored’.
Here’s a big hint when looking for possible reflected (non-persistent) XSS attack, it’s described as reflected because whatever is searched for is reflected back to the user, we can use this to our advantage when performing an XSS attack.
<p>You searched <b>someDomainName.com</b> for <i><b>hello</b>
The source code clearly shows that whatever we type in will be placed within the
With this knowledge in mind what would happen if we searched for:
If the website is completely vulnerable we would get an alert box with sup printed in the box.
This is not the case for this website in particular (which will remain unnamed), it seems as though the search function will strip-out any symbols it deems unsafe.
onto the end of the search we are able to search straight from the address bar.
N.b. it will not always be
check the source code to find out.
Finding vulnerabilities is more secure systems will take time and will require more digging around to find a feature that could be vulnerable.
What became more interesting at this point is that despite dropping symbols in the search another feature on the same page gave us exactly what we want!
It’s not quite working because the HTML syntax is incorrect if we just submit the previous test, so we need to fix it!
So what would be needed to fix that last query? While remembering that modern browsers are very forgiving when they interpret code.
Go back and have a look at the end of the snippet…
Well, I’m going to tell you anyway!
We need to fix that previous attempt at XSS, how about if we were to finished off the previous tag at the beginning of a submitted query?
Correctly finish the previous tag? I think so!
The final query is as follows:
This will pop-up an alert box with sup printed, bingo!
Why? Because the syntax is now correct:
ONCLICK="window.location.href='http://someDomainName.com/addressbook/default.aspx?s=""><script>alert('XSS')</script>" ' ">
Notice the extra
" ' "> at the end? This will actually get put onto the page itself, but now anything can be placed after
" "> and it will get executed!
The wrap-up will come later, but this is the basic anatomy of a cross-site scripting vulnerability.