ocCODE http://occ0de.wordpress.com obsessive-compulsive coding stuff. Wed, 20 Sep 2006 04:18:59 +0000 http://wordpress.com/ en hourly 1 http://www.gravatar.com/blavatar/d9c63f426e5e59304463274ada540608?s=96&d=http://s.wordpress.com/i/buttonw-com.png ocCODE http://occ0de.wordpress.com Full shownotes for L3pprd/ocC0DE’s Cross-site Scripting episode http://occ0de.wordpress.com/2006/09/19/hello-world/ http://occ0de.wordpress.com/2006/09/19/hello-world/#comments Tue, 19 Sep 2006 21:05:46 +0000 occ0de ]]>

What is Cross-site Scripting?

Cross-site scripting (XSS) is a very common vulnerability in web applications which can have a variety of different unintented effects.

The basics of cross-site scripting are simple: You use a website in an unintended way such that you can insert javascript code in with the HTML pages that the user normally sees.

What can it do?

Cross-site scripting can cause all sorts of problems. Since cross-site scripting is all javascript-based, an attacker who successfully exploits your site can do anything that Javascript can do. In a worst-case scenario, a cross-site scripting attack can execute anything on the local machine, with privileges of the logged-on user.

Nefarious hackers have done all sorts of things that are anything from annoying to incredibly malicious and profiteering.

Cross-site scripting is often used for cookie theft. A crafted cross-site scripting attack can be used to steal cookies from users who browse your site. If your site is an e-commerce site, it could expose their shopping history. It could their usernames and passwords, and be used to track where your users go on the net and what they do.

How the bad guys exploit it:

According to Wikipedia, there are three major types of Cross-site scripting attacks.

A Type-0 vulnerability is one where a malicious page tricks your browser into running Javascript code on your local computer in a trusted mode.

A Type-1 vulnerability is the most common type. In a Type-1 vulnerability, a text string is input from the user and written out to a browser without validation, which could possibly contain script. This is no big deal, usually, since a user can only write code out to their own browser. This becomes a big deal, however, if a spammer or phisher sends out a link containing some malicious script code.

A Type-2 vulnerability is similar with the exception that the user’s input is stored to a database or similar storage facility. This malicious script will usually be visible to the browser of anyone who visits the site. This can be devastating since there are a large number of users potentially affected, and the malicious code becomes persistent.

How to prevent against it if you’re a webmaster:

It may seem simple, but validate everything! Every piece of text that comes from the user needs to be validated, to ensure there is no javascript included. As a web programmer, this becomes incredibly complex when you take into account that there are a huge number of HTML tags that can contain javascript in their events, such as onclick. There is a very extensive cheat sheet on ha.ckers.org which shows different strings to test against forms and url parameters in your website to ensure it’s fairly safe against XSS vulnerabilities.

Most server-side scripting languages provide some sort of escape function to take potentially dangerous characters and translate them to something which is safe to write out to the web page a user’s browser will render.

The more complex a website becomes, the more places you have input coming from. Add a database, and your complexity increases again. It takes a lot of thought, testing, and thinking like a hacker to really make sure you’re safe. Preventing XSS vulnerabilities may even keep other exploits from working, like SQL injection (check out TWAT radio episode 33, by livinded).

Quite a few big-named websites have had very public XSS vulnerabilities: Hotmail, MySpace, Paypal, and even the new Netscape.com website. You can follow the Bugtraq and/or Full Disclosure Mailing Lists at http://seclists.org/ to see that there are new ones reported and fixed every day.

Demonstration:

The following page is sufficient to demonstrate the XSS vulnerabilities at the ha.ckers.org cheatsheet; simply save the contents as a .php file. WARNING: Do not put this page on any public internet-facing webserver!


<html>
<head>
<title>XSS Test</title>
</head>
<body>
<h1>XSS test</h1>
<p>Hey there, <?= $_GET['hithere'] ?>!</p>
</body>
</html>

After installing this vulnerable php page, (again, only recommended on a machine which is not visible to the outside world — you have been warned!) you can call it with parameters such as:

http://localhost/test.php?hithere=<script>alert('I am vulnerable!');</script>

How to guard yourself as a websurfer:

If you use Internet Explorer, it does include a zone-based security model which allows you to lock down a site until you give it explicit permission to execute Javascript. Steve Gibson, in Security Now episode 38, outlines the method he uses to secure IE.

If you use Firefox, install the free NoScript extension, which very simply performs the very same task. There is a small icon in the bottom right of the browser which you can click to temporarily or permanently allow a website to execute Javascript, once you trust it.

Referenced pages and links for more information:

Cgisecurity.com: Cross Site Scripting questions and answers

Cross-site scripting – Wikipedia entry

SecLists.org Security Mailing List Archives

TWAT ep. 33 – SQL Injection, by Livinded

XSS (Cross Site Scripting) Cheat Sheet

Security Now Episodes

NoScript Plugin for Firefox

]]> http://occ0de.wordpress.com/2006/09/19/hello-world/feed/ 0 occ0de