This information is from “Malware: Fighting malicious code” by Ed Skoudis. I am just providing a summary. I highly recommend this book, btw. It's also extremely condensed..I just tried to get the basics in.

Just to show the flipside of the XST (cross site tracking), is XSS (cross site scripting). In simple terms, it is injecting malicious code into a vulnerable website so that the visitor's browser unknowingly executes the code. The code tends to be in the form of a browser script, configured to steal cookies, or hijack the victim's browser session.

One vulnerability of a web site is if it reflects input back to the user. For example, a search engine. When you query, for instance “free porn”, the site echoes back something along the lines of “Here are the results of your search for: free porn”. The premise of XSS is, what if you include JavaScript in your query? If the site does not strip out the script, it would be executed when the results page loaded. This would allow you to hack yourself. By expanding this technique, an attacker can clone other peoples sessions by getting them to reflect malicious code back to themselves.

A normal search engine query would look something like this:

www. example.com/search.cgi?query=free+porn

If the search engine does not strip out the JavaScript, the URL might look like:

www. example.com/search?cgi?qeury=< script> alert(document.cookie)</script>

An attacker interested in obtaining someone's search engine cookies (spyware purposes?) could trick the victim into clicking on the URL. The browser releases the cookies because JavaScript is embedded in the page that is authorized to view them. A couple of ways to trick a user into clicking on the links is by including it on a third party web site, via email, or embed it in a posting on a discussion forum.

Actions typically involved in an attack:

1.The potential victim sets up an account on a vulnerable web site. The web site uses cookies to maintain session information.
2.The attacker creates a link that includes the cookie stealing code, and tricks victim into clicking on the link (i.e click here and win one million dollars).
3.The victim's browser transmits the attacker's scripts to the web site as part of the URL.
4.The site reflects the input, including the malicious script, back to the victim.
5.The script runs in the victim's browser. Because the browser thinks the script came from the “approved” web site, the browser runs the script within the context of the vulnerable site. The browser grabs the victim's cookies and relays them back to the attacker.
6.The attacker is then able to clone the victim's session with the target web site.

Including input as part of the URL is known as the GET submission method, so in order for the exploit to work, the target site needs to support the GET method.In contrast, some sites only support the POST method. With this type of attack, the code is embedded in an HTML form. In order for this to work, the victim would have to submit the crafted form for the site to reflect the attacker's script back to the user.

Another much more dangerous method of launching XSS attacks takes advantages of sites that take input from one user, and present it as output to another user. This method allows malicious code to be executed as soon as the victim views the infected page. This method works regardless of whether the site uses GET or POST to collect user input.

**** I'm not going to include the example here, because if some skiddie wants it, he can buy the damn book himself For anybody that is interested, ask, and I will try to elaborate a little.********

What is dangerous about this method, is that for instance, were I to capture a senior member's cookies, it would be theoretically possible to masquerade as that senior member. (or even a moderator)

DEFENDING AGAINST ATTACKS-Defenses can be applied in 2 general areas: at the web server and at the user's browser.

Server side filtering-Web sites need to carefully filter out input that a user's browser could interpret as a script. By removing this data, there is nothing harmful to be reflected back to the user.

***The book here lists 9 different methods of introducing malicious scripts into HTML files*****

Since there are so many different methods to introducing scripts, the book indicates that the best way to filter is to eliminate (if possible) the following characters:

< > ( ) = ” ' ; % &

Instead of deleting the characters, the web application can translate them into counterparts that look like the original symbols, but do not have the same contextual significance. This is also known as 'escaping' the characters.

A web site must know what encoding the visitor's browser will use to recognize them. To eliminate potential “work-arounds” for an attacker, the site should explicitly tell the browser what character set it should operate in. EXAMPLE:

<meta http-equiv=”content-type” content=”text/html; charset=ISO-8859-1>

***This is just one method listed***

Client side defense- for starters, never browse logged in as superuser, root, or administrator. Any scripts that may be running in your browser will have the same privelages.Most security concerns can be addressed by disabling scripts. If you need more flexibility, you can set up each individual web site according to your needs (i.e. Trusted zones) The downside to blanket disabling of scripts is that you may (and probably will) lose functionality.

I hope this helps you a little Lv4