Hi. I still see what this paper is calling "Javascript Hijacking" as a subset of session riding or cross site request forgery (CSRF). Javascript Hijacking has a bit more punch because it more easily exposes more of the payload. That's foiled by "Preventing Direct Execution of the Response" as described in the paper, and it sounds like a good practice if you don't have any other protections against session riding.
But session riding is possible with any service that is available from a URL. The only protections for it are to verify referrers, sessions and one time tokens on the server side as discussed earlier. Javascript hijacking is blocked by everything that blocks session riding. ----->Nathan .:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.: ||:. Nathan Young Cisco.com->Interface Development A: ncy1717 E: [EMAIL PROTECTED] > -----Original Message----- > From: jquery-en@googlegroups.com > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Ovenden > Sent: Wednesday, April 04, 2007 4:02 AM > To: jQuery (English) > Subject: [jQuery] Re: Web 2.0 is vulnerable to attack > > > I just read the paper and, correct me if I'm wrong, this vulnerability > *only* applies to JSON. XML is safe, because it has to be parsed > before the data can be extracted. I avoid JSON because I don't like to > have eval() statements in my code. This would seem a more obvious > solution to the problem than the one proposed. > > Chris >
