One Drop on A Spider Web
# sign) and evaluate it within the attacked application context. This can be achieved by using something like this:
This works really well when you are restricted in terms of the vulnerable field length. It was found that we can squeeze XSS payloads into 50 to 60 characters in size. Keep in mind that this is only when we use script elements (
Another interesting point to outline is that the fragment identifier technique is quite stealth. Every information that is behind the hash (
#) sign is not sent to the server. The fragment identifier is only used on the client. This means that this technique is suitable for circumventing firewalls, intrusion detection and intrusion prevention systems.
It is recommended to check the Playing in Large article, if you are not familiar with this technique.
In this post, I will show you a technique that I have developed in the last half an hour, which is as stealth compared to what we have discussed before, but a lot smaller in terms of length of characters needed and does not require special characters such as:
square brackets 
The character set that is required is composed of lower case letters and the round brackets
(). In order to explain how the technique works, I am going to lay out a hypothetical scenario which is as follows:
- create a blank html page with the following content:
- open the page within your browser - you should see a blank alert box
- create a blank html page with the following content:
<iframe name="test" src="path_to_the_first_page.htm"></iframe>
open the page within your browser - you should see an alert box with the message test
If you haven't realized yet, we can use this technique to circumvent filters in a very clever and quite sneaky way. Let's get back to our hypothetical scenario with the XSS vulnerability in acme.com which cannot be exploited easily. By using the technique I discussed above, we can bypass the restriction and here it is how:
If you take the code displayed above and place it inside an innocent HTML page, you will be able to XSS anyone who visits it and is on the acme.com domain, although acme does a good job of sanitizing some of the meta characters.
Some of the sceptical XSSers may not see the point of using this technique for a number of reasons. The first reason is based on the fact that there are other ways to exploit acme.com. This is true, but the example here was provided as a case study only. Very often we can
alert(1) but nothing else, because the string needs to be short and can only contain standard characters. This is exactly when this technique is most suitable, because the character set is standard and
eval(name) is a lot like
Keep in mind that this attack leaves a very small footprint on the attacked system. The data that is contained in the
name variable is never submitted to the server. It is worth mentioning that HTML/XML attributes are usually allowed to contain quite a lot of data which allows attackers to include entire XSS frameworks within the boundaries of
This technique was published in order to raise the security awareness in regards to XSS (Cross-site Scripting) attacks. There are more then one way of doing things, which we usually overlook.
then we know we can run absolutely anything by visiting a third-party page that embeds our magic iframe.
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
Awesome AnDrEw Wrote: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
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.
alert(1). All we need to do in order to make them work is
/alert\((1|'XSS'|"XSS")\)/eval(name)/iand 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.
window.namecan 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.nameand other sites can reuse that information in a clever way.
please tell me when the registration process is finished : ) http://www.ush.it/2007/06/27/xss-cheat-sheet-two-stage-payloads/
<img src=http://w onError=with(document)with(e)eval(unescape(innerHTML))
if (top.location != location) top.location.href = document.location.href ;
window.name = unescape("alert('XSS!');");
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'.'
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