egroupware

mirror of https://github.com/EGroupware/egroupware.git synced 2024-11-21 15:33:20 +01:00

Table of Contents

Section 1 - Description, and overview

Introduction
Prerequisites
XSS Impacts
XSS Impact summary

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Wiki ▸ [Developer Docs](Developer Docs) ▸ [Cross Site Scripting](Cross Site Scripting) ▸ Editing XSS Description, and overview

Section 1 - Description, and overview

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 havent 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.

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 ?

1) 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

2) 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 peoples 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.

3) 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.

4) 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 dont 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.

5) 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,

6) 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 summary

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

1) 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

2) can force a user to any action they are able to take, and can potentially access any information they can access

3) 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

4) 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.

Wiki ▸ [Developer Docs](Developer Docs) ▸ [Cross Site Scripting](Cross Site Scripting) ▸ Editing XSS Description, and overview Go To: next Section

Language: