Second, the XSS attack. I seriously don’t even have a clue how I would have used that to attack a site, but regardless, it is the same thing, right?

In case of RXI holes at images.google.com and some other sites (which I wrote about in my news), it’s not possible to use XSS to attack users of that site, i.e. to steal cookies. Because code executes on other site (not target site). It’s only possible to execute JS code (malicious one), e.g. for spreading of malware.

But there are other RXI holes at other sites, like in case of RXI at webpark.ru, where it’s possible to conduct XSS attacks directly on users of this site (because code executes at this site).

I’m being accused of hacking someone’s site using the vulnerability listed on this page

From above-mentioned you can see, that you can’t use this hole to attack somes sites dirrectly with using this hole (i.e. by stealing someone’s cookie and get into his account), which can be made by other RXI holes. But this vulnerability at images.google.com can be used for phishing and malware spreading .

Since I’m being accused of using this vulnerability

John

Concerning this particular vulnerability at images.google.com, which allowed Cross-Site Scripting and Content Spoofing attacks, then this hole is already fixed by Google. It was done some time ago - I found it this year. But there are way how to “resurrect” this hole and conduct these attacks again (and sometime I’ll write article about this method).

But there are many other Remote XSS Include (RXI) holes (aka Frame Injection) in Internet, so you can easily find such ones for your testing. Including such major sites as Google and Yahoo, as on babelfish.altavista.com and babelfish.yahoo.com and other sites.

I think this is what you’re referring to as the content spoofing attack, right?

Creating a link which must be visited by victim is a way to trigger the attack (which concerns both XSS and Content Spoofing attacks), but it’s not Content Spoofing. If one link to one site leads to another site, it’s Redirector vulnerability (aka URL Redirector Abuse in WASC v.2.0). By content spoofing I mean that many parameters can be spoofed, such as small image (i.e imgurl leads to one site and imgrefurl to another).

First, by putting in whatever url I want for the imagerefurl, I can make someone believe they are going to images.google.com but simply have the path go to whatever site I want them to go to. This would require the attacked to click on a link, and for me to get them that link somehow. I think this is what you’re referring to as the content spoofing attack, right?

Second, the XSS attack. I seriously don’t even have a clue how I would have used that to attack a site, but regardless, it is the same thing, right? I construct a link that would be the hack, I then have to get the target to click on the link. I’m not creating a link and clicking on it myself to attack a third site?

Seriously, I’m not trying to play stupid. I’m being accused of hacking someone’s site using the vulnerability listed on this page and my black hat knowledge is focused in the click fraud world (where I’m the one fighting click fraud.)

And there are many others attacks vectors, than cookies stealing. Like XSS for remote controlling, redirecting (as I show in the post) for phishing and others attacks, and especially code execution as I said before. By code execution I mean that bad guys can execute malicious code in user’s browser (while hiding behind other site) - it can be used for malware, spyware, viruses, trojans and exploits execution.

So number of attacks is limited for RHI/RXI, but still wide. Therefore this type of vulns are dangerous and web developers need to be aware of it.

In case of Remote XSS Include (RXI) it is possible to execute malicious code in browser when user is at another site (so attack is hidden). Two mentioned redirectors are just for an example, that bad guys can redirect visitors. But others attacks are possible, so on the whole it is code execution vulnerability.