Firstly, you’re probably asking yourself. How the hell did I end up here. Well “mes amigos”, I shall elaborate on your predicament with a 101 in XSS, and why you shouldn’t trust an application you didn’t write yourself.
What is XSS?
XSS, or Cross Site Scripting as it’s known in its unabbreviate form, is the act of inserting ECMAScript (usually javascript) onto a trusted website page, and utilising it to perform actions unknown to the users (victims). It is essentially a form of hacking, utilising the trustworthiness of the exploited site to facilitate actions which can sometimes have repercussions for the user.
How does it happen?
There are 3 types of attack, but all 3 are based on the same principle. The insertion of unescaped, unentitised javascript into the website page. Type 0 and 1 have similarities in convincing the user to follow a socially engineered link to a vulnerable page with a query parameter. Type 2 however, is different. It is “persistent”, i.e. lives on the page beyond the URL call, in a flat file or database, and doesn’t (usually) require social engineering.
How the attacker can benefit:
Malicious perpitrators can code many different things into their XSS hack. I include some of the more common ones from the more minor to the more serious:
- Dynamically updating the DOM (webpage) to include a “you’ve been h4cked” message.
- Extension on 1: Writing a link to the page pointing to an external site.
- Redirecting the victim to another website to increase web traffic (see greyhat seo).
- Extension on 2: Writing a link to the page pointing to an external site for further social engineering.
- Stealing cookie information.
- Extension on 6: Hijacking a stolen Session cookie.
Other extensions on the above might include, placing google Adsense on the site that the victim is being redirected to, to generate revenue.
How to avoid the issues:
A common mistake is to escape the input, or html entitise it. When in actual fact you want to filter it. There is a distinct difference here. Filtering involves making sure the user input fits a particular pattern, more often that not a regular expression. The entitising should occur on output, converting all html type characters into their respective non-harmful cousins. This still allows users to write what they want while maintaining the safety of the site.
Using closed source software, i.e. something you have written yourself, instead of a freely available product where the source code is available to other. The main benefit is that perpetrators don’t know how it operates, so merely having to guess at the functionality and hope that the code itself will provide some errors, gives the attacker an extra hurdle. Of course it’s by no means a sure method of protecting your application. Obfuscation doesn’t resolve badly coded applications. Again referring to the point made above, filter the input, and escape the output.
In summary:
So you may be asking yourself, how did my shoutbox suddenly become vulnerable to this? The answer my friend, is right here for you to find. You may also wish to ask yourself the question. What if the XSS is a worm? Maybe you got lucky this time? But perhaps you won’t be so lucky next time!
Tags: The Dark Arts, XSS
So this is your doing? You hijacked the Ajaxdaddy script?
Thank you for the ajaxdaddy example. I will fix that today.
I appreciate that several of you have expressed negative opinions about the particular hack that was performed on Ajax Daddy.
But, I feel it worth noting that because the hack was relatively harmless and the owner of the site has acknowledged the vulnerability after being informed (prior to the demonstration), my overall point still exists; do you trust external scripts written by 3rd parties?
In this case, the hack was trivial, and I have a patch available for those utilising a version of the script that is vulnerable.