Incidentally, he just added some extra spice to hash (fragment) payload attacks:

eval(unescape(location))

This works if you break the hash with a %0A (newline) before your payload, because:

“http:” gets parsed as a label
“//host:port/path…#…” is ignored until newline (C++ style comment)

So simple, so nice :)
–
There’s a brower safer than Firefox… it’s Firefox, with NoScript – http://noscript.net

Here is what I tried out,

1.html:

window.name = unescape("alert('XSS!');");

and

2.html:

breakframe();
eval(window.name);

2.html still alerts XSS!

So it means we can use window.name even if frame breaking code is present.

So another ‘with’ may be necessary for window’.’

if (top.location != location)
  top.location.href = document.location.href ;

<img src=http://w onError=with(document)with(e)eval(unescape(innerHTML))

please tell me when the registration process is finished : )

http://www.ush.it/2007/06/27/x.....-payloads/

I didn’t know that. Actually this is very funny. I cannot see to what extend window.name can be used for malicious purposes although it is sort of interesting since it is almost like some kind of global dashboard where everyone can leave a message. So, we can implement some sort of a system where sites leave information about the user inside window.name and other sites can reuse that information in a clever way.

For example, site1.com writes a value into window.name. Any other websites that are visited in that browsing context (i.e. that browser tab or single browsing window) can read or write this value. In fact, I’ve got some cool demos where I track individual users across domains without web bugs/3rd part image server using JavaScript and window.name.

In fact, we touch on this in the upcoming Ajax security book in our attacking offline Ajax apps chapter. I even wrote a source code compatible implementation for Firefox’s sessionStorage object for ther other browsers.

Awesome AnDrEw Wrote:

---

But then in essence I would see the technique pdp has found as relatively useless unless it was able to be done through some type of service within the site. What I mean by that is I would think it’d only be useful if say I had the ability to post an IFRAME within a messageboard on the site that I am targetting, but then again it still is of little value. If you can get a user to navigate to a third-party page then you’ve already won, because you can use your own payloads without cross-site scripting as a prerequisite unless you absolutely need to use the frame to target the site.

Use the right tool for the right job… although I find ma1 technique rather cool, it may not work in some cases. For example, changes in the fragment identifier wont result in page refresh which is what you might want to achieve in some cases. Also, there are ways to make the fragment identifier to go away via a series of redirections, which is something that happens quite often. Another bad thing about the fragment identifier technique is that although everything is inside the URL, it looks too suspicious. Very often, attackers will use a 3rd party website which upon user arrival does the actual exploitation. Not to mention the fact that in some cases the # hash is used as communication mechanism between frames which are served from different origins. Any use of the fragment identifier will break the communication. You don’t want to do that if you want to be stealth.

Here is an example. Let’s say that you have a worm that exploits the user on several domains. For sure you can use the fragment identifier technique and compose URLs which are included inside a hidden iframe. However, you need to do all the manual work for nothing, when you can simply create the iframe, assign the name or the target with your payload and rotate the src value with the URLs you want to exploit. XSSED.com has tones of vectors that simply alert(1). All we need to do in order to make them work is /alert\((1|'XSS'|"XSS")\)/eval(name)/i and start rotating them inside an iframe. The chances of this technique to work are higher mainly because we do not add that much more characters into the payload. We don’t have to do any characters counting and we don’t have to think whether there is something before our code that makes uses of the information after the # hash. believe me, more and more applications make use of the hash today.

To sum up… do not be ignorant. use the right tools for the right job. as you can see, there are real applications of the technique I described.

That’s a killer snippet. Thanks a lot for that.

Anyway, great stuff. RSnake should include this one into his cheat sheet.

with(location)with(hash)eval(substring(1))

Much easier to post everywhere, because it’s self-contained and you don’t need to control the window name.

Cheers
–
There’s a brower safer than Firefox… it’s Firefox, with NoScript – http://noscript.net

<script>eval(name)</script>

as our XSS payload, then we can run JavaScript without any restrictions whatsoever.

So when testing for XSS, if we get a blank alert box when injecting

<script>eval(name)</script>

then we know we can run absolutely anything by visiting a third-party page that embeds our magic iframe.