Real World XSS
Author: David Zimmer <dzzie@yahoo.com>
Site: http://sandsprite.com/Sleuth
Article Downloads: small_xss_utilities.zip
Section 1
- Introduction
- Prerequisites
- About the Article Downloads
- Impacts (Attack Scenario)
- Impact Summary
Section 2 - Methods of Injection, and filtering
- Injection Points
- Injection methods and filtering
- XSS scripting tips and tricks
Section 3 - Inside the mind, mental walk along of a XSS hack
Section 4 - Conclusion
INTRODUCTION
So what is all the media fuss about XSS?
For those of you who don’t know the acronym, XSS stands for
Cross-Site Scripting. It is the term that has been given to
web pages that can be tricked into displaying web surfer supplied
data capable of altering the page for the viewer.
This is a pretty broad term and I apologize, but as you will see
XSS has such a wide ranging berth of attack vectors that such a
Description is necessary.
We have all seen the numerous Bugtraq postings "XSS FOUND IN
MANY MAJOR WEB SITES" and we have seen the examples to prove it
Does indeed exist, but many of these still leave many readers thinking
"Ok, so they can throw up an alert box, how dangerous can that be?"
This brings us to our first general truth..Finding XSS holes is the
easy part, knowing how to creatively exploit them and assessing the
possible impact of them is where the real coding and creativity comes in.
There are many many documents on the web detailing XSS and generalized
book definitions of it, what I haven’t seen is a practical approach and
example usage of outside of the bounds of the few default examples
usually given. I believe this has made people overlook XSS and not
realize its true impact.
For a brief background, I first started my study of XSS about 5 years ago,
when I (ab)used it playing pranks in 'no rules' html chatrooms. From there
I branched out using my knowledge and abilities to help secure sites and
perform web application security audits. I have a personal fascination with
programming and web technologies and have grown very familiar with windows
programming, ASP, database and other web technologies.
The knowledge contained in this document is a summation of these years of study
experience, intuition and experimentation. Many of these concepts are things
that I have been introduced to by piecing together bits of information and
conversations over the years. I am presenting them all here together in one
document because I have yet to find a comprehensive resource detailing the
exact impacts in conversational real world scenarios.
Prerequisites
Some topics basic to this document are an understanding of URL structure,
and some knowledge of html and JavaScript. Additionally knowledge of
URL encoding, http request methods and web application technologies such
as ASP, would be helpful.
About the Article Downloads
Accompanying this article is a small download of useful XSS utilities I have
developed over time. Included in the package is:
- Small Server - a specialized web server I developed specifically for exploring/
XSS vulns. Has built in support for basic auth, http header redirection,
logging, etc. Can serve up pictures and text, detect telenetters, and logs all hits
to a large display window for analysis.
- UrlMunge.exe - converts dotted decimal ips to several alternative formats
- Script encoder.html - simple html/javascript encoder utility
- CharConversion.exe - ascii <-> hex character encoder w/ URL encode option
- Sample ASP demo/tutorialof some XSS concepts in action
These are all things I developed in the course of actual use and found that I
needed/wanted. They are pretty old now, but they all still have utility.
XSS IMPACTS
Before we look at the specifics of how these page alterations are
possible, lets take a step back and enumerate some of the possible
impacts XSS can have on your web site. The root question we should
ask ourselves is what could an attacker be trying to gain by using
XSS ?
- Theft of Accounts / Services
Of course the first thing that comes to mind when XSS is mentioned is
Cookie theft and Account Hijacking. In fact, one of the default XSS examples
shown to the public is alert(document.cookie) signifying the importance and
inherent dangers of a third party being able to execute arbitrary web code
in the clients browser.
In a fair amount of cases, especially with older web applications,
a stolen cookie can easily lead to account hijacking. This occurs when the
cookie is used to hold all of the verification information on the client side
and nothing is tracked on the server as to the surfers state or credentials.
Some common motivations for this category would include:
- Identity theft
- Accessing confidential resources
- Accessing pay content
- Account Denial of service
- User Tracking / Statistics
Another usage of XSS is in gaining information on a sites web surfer
population. As an experiment some time ago I set up a simple mechanism where
I could literally monitor people’s clicks through a vulnerable site.
Yes this is perfectly possible, and indeed was shockingly easy to do,
Had I taken the experiment a step farther I could have also linked the surfers
email address to their surfing habits and interests, stats advertisers and spammers
dream of.
- Browser/ User exploitation
The second most common example of XSS exploitation provided is the
venerable alert('XSS Example') script. A simple alert box is a very innate
example of the type of attacks that fall into the category of user exploitation.
One visit to George Gunskies Site or a review of some of the browser
exploits discovered by ThePull should be enough to make anyone realize that
surfing the web can be a dangerous experience.
Imagine if I had, in the above example, not just tracked users, but had
instead been trying to actively exploit them? I could have used an unknowing
web site to discrimnate my malware to thousands of unsuspecting victims all at once!
A couple things that I should also mention that may not be to obvious with
this style of attack is
A) to a casual surfer, your site is the hostile site
B) I can be leveraging off of the credentials of your site.
eg. Say Microsoft.com had a XSS hole that someone exploited like this.
If I were to utilize a unsafe activex control in my exploit,
surfers would take into account that this was after all
Microsoft, and they very well may click ok to run it, even if
they would not on other sites.
c) I have a much much higher distribution rate and even a tighter target audience
than I would through many other distribution types.
d) I don’t actually have to exploit them, I can just steal them all from your
site and bring them to mine.
e) I might not even care about abusing your site, I might just care about
the number of surfers I can hit and force into actions on other
third party web sites.
The Sub category of User exploitation is a subtle variation but a distinction
worth making. Browser exploits rely on specific security holes in specific versions of
web browser software. User exploitation is the act of forcing users to take actions on
your behalf. These actions can include privileged actions only then can perform like
account modifications, sending email etc, or they can just be used to force random
unsuspecting web users to take general actions and give me an abstraction layer in the
chain of evidence.
- Credentialed Misinformation
One of the most dangerous, yet often overlooked, is the danger of Credentialed
Misinformation. Once we have active scripting executing in a browser, we can pretty much
do anything we could desire with the pages content. If you were a large trusted news site,
this could be quite a dangerous thing. Imagine seeing a link on a messageboard or email
saying that there were a reactor meltdown on the west coast and thousands were dead and
injured? the site was clearly a legitimate large news site and a trusted resource. The url
looks legit, is only about 50 characters long and raises no suspecisions. When you get to
the site, you are horrified to read through the pages of graphic detail. How can this be?
With a XSS vulnerable site...it could quite possible NOT be. Misinformation attacks
are not limited to news sites. With but a minor twist and a quick jaunt of thought, My
originally email message could have appeared to have come from some popular web site you
have an account with and asking you to visit this page to renew your password for
security measures. Again the Url aims directly into the heart of your beloved site, so you
think little of it and just fill out the information. What you don’t see behind the scenes
is that the crafted url you clicked on got your browser to display a phony login page
created by a malicious author and that the form just submitted all your login information
to him. Congratulations you have been duped with the help of a XSS vulnerable site, and you
will probably never know it.
- Free Information Dissemination
With the concept of page rewriting under our belts from the misinformation
dialogue, the concept of free information dissemination is one of the next logical
realizations we come to. Lets say I have a message I want to get out like SPAM or
some political extremist message. In both of these cases It would be desirable for
me to limit my personal attachment to the message and further draw out the evidential
chain leading to me. Again I can utilize a XSS vulnerable site to show my message.
All I would need to do is to post a crafted url on some messageboard, if the message
was relatively short I could include it all inline in the URL and not have to worry
about exposing my own web hosting account and linking it to the message,
- Other
This category is included for the simple fact that there are as many types
of attack possible as there are attackers , motivations and technologies available
to exploit. A couple scenarios that might fall into this category would be using
random web user as an abstraction layer..forcing their browsers to silently make
exploitive requests to other web servers. This blind proxying would again lengthen
the evidential chain leading back to you.
Another technique would be to use a XSS vulnerable sites large user
base to chew up a smaller sites bandwidth. Just insert a 1x1 image src to the largest
image on the target site. With a large enough viewing you could effectively chew up
the targets bandwidth for a while.
Finally there are techniques that aren’t really scripting attacks but are still
html injection attacks and are worth mentioning because the filtering is still in our
ballpark. Html injection attacks are ways to insert malicious html to wack someones
web pages. A couple brief examples will be covered down in the filtering section.
XSS IMPACT SUMMAARY
Now that you have seen of the possible utilizations of XSS, we shift gears slightly
and summarize its strengths and weaknesses as an attack vector.
Strength
- can include a very large and target audience with one injection point. In some
instances can hit every single user of your web application at once and be present
on every single page they visit
- can force a user to any action they are able to take, and can potentially access
any information they can access
- can be hard to detect and can be slipped in quietly, chain of evidence can be drawn
out and not readily apparent how exploit or actions occurred
- can be a powerful tool for information display and alteration. With the advanced
features of IE and dynamic html, every portion of a pages content can be changed on the fly through
active scripting.
Weaknesses -
XSS is 95% percent avoidable with proper filtering techniques on any user
supplied data. While making sure that every element is filtered in large (and especially
legacy) web applications can be a daunting task, properly implemented filters can prevent
your site from falling victim to the above mentioned attack scenarios. To date there
are several commercially available tools that will scan your web application and automate
the task timely task of XSS enumeration. One such tool is of course WebInspect from
SpiDynamics.
What is the 5% that is unavoidable? Reality, we have to accept that web
applications can be huge tangled beasts to edit and secure, we have to accept that
even a small last minute modification can have unforeseen impacts, that no one can
catch everything, that as new technology and browser capabilities emerge filters
have to be reevaluated, new attack concepts and finally that there is nothing
called a sure thing (tm). In the end its always better to know your process
capabilities and accept the reality of the unforeseeable.
Next Section
|