Is it an XSS if you can only make it output code to your own browser? I can already execute whatever JavaScript I want in the console, so what's the advantage of having the server deliver that code to (only) me?
I can definitely see the issue if the server saves the unfiltered input and tries to print that out for other uses, but it seems to me that outputting a raw $_GET variable will only go to the requester and therefore could only run unfiltered code on that requesters machine.
EDIT: Answering my own question:
This is a security hole because the unsafe JavaScript is stored in the URL for the page (it is a GET parameter). This bad URL could then be sent as a link in a spam email or similar. Victims clicking on the link would then see a page that comes from the legitimate source, but is running unsafe code compromising that user's session. This sort of attack relies on the attacker distributing the link with the bad code as a URL parameter, and is not a vulnerability that a user could encounter when just visiting that site as I had first assumed.
That's _exactly_ what XSS is about. One possible way to exploit things like this is if I send you a link to a website, that embeds the target page through an iframe with javascript output injected. I could then have the JS steal your cookies/session or worse.
Or bit.ly/shortener links - you got it. I used to think like you did - what harm is there in 'exploiting' my own browser? Took a while for the penny to drop in my case.
Yes. They are referred to as "reflective" or "non-persistent" XSS vulnerabilities. The attacker might exploit these using for example an "invisible" iframe on a different website, and thus loading the vulnerable website, in the background, with the desired parameters.
This will result in the malicious javascript being executed "on the vuln. website", in the victims browser.
I can definitely see the issue if the server saves the unfiltered input and tries to print that out for other uses, but it seems to me that outputting a raw $_GET variable will only go to the requester and therefore could only run unfiltered code on that requesters machine.
EDIT: Answering my own question:
This is a security hole because the unsafe JavaScript is stored in the URL for the page (it is a GET parameter). This bad URL could then be sent as a link in a spam email or similar. Victims clicking on the link would then see a page that comes from the legitimate source, but is running unsafe code compromising that user's session. This sort of attack relies on the attacker distributing the link with the bad code as a URL parameter, and is not a vulnerability that a user could encounter when just visiting that site as I had first assumed.