> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 12, 2008 1:50 PM > To: The elegant MVC web framework > Subject: RE: [Catalyst] implementing ajax > > "Matt Pitts" <[EMAIL PROTECTED]> wrote on 03/12/2008 11:53:45 AM: > > > > -----Original Message----- > > > From: Jonathan Rockway [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, March 12, 2008 12:12 PM > > > To: The elegant MVC web framework > > > Subject: Re: [Catalyst] implementing ajax > > > > > > * On Wed, Mar 12 2008, Matt Pitts wrote: > > > > The main reason against JSON for me is security. Something that > can > > > be > > > > eval'd is very dangerous and I'm sure we're all aware of the > cross- > > > site > > > > vulnerabilities that take advantage of JSON returned data. > > > > > > Don't parse JSON with eval. Use a parser. (How do you think Perl > > > parses JSON?) > > > It's a code vs. data issue. Yes, evalling code is dangerous. So > > don't > > > do that. Treat your data as data and you won't have a problem. > > > > Sure, I can do this in my own client-side JS, but what if I can't > trust > > the client? Even if my returned JSON is purely JSON structure (no > "var x > > = { <JSON DATA> };", just "{ <JSON DATA> }") can I still be > guaranteed > > that if someone does: > > > > <script type="text/javascript" > > > src="http://myapp.com/some/cat/action/that/returns/json/data";></script> > > > > in their own pages that the local JS engine won't actually put my > data > > (with potential user info) into memory and allow a malicious person > to > > get it? I see where you could maybe make this same argument against > XML, > > but since JSON is really, really close to being eval-able as JS code > > whereas XML is not, I'd rather err on the side of caution. > > > > If data is data and you have to use a parser anyway, then again, why > not > > use a format that is less vulnerable to malicious access? > > > > Matt, > > I have absolutely no idea what additional security you are > inferencing by this email. If you toss sensitive data out whether the > format is json, xml, or xor 3|\|CoD3d it is still in their hands.
Obviously, one shouldn't put out sensitive info. without some form of authorization, I made the *assumption* that authorization was *assumed* for my scenario. However... That's the point of cross-site scripting attacks, they get to authenticated pages by using the client's browser to access the page. The scenario I outlined is much like some of the Gmail cross-site vulnerabilities... http://jeremiahgrossman.blogspot.com/2006/01/advanced-web-attack-techniq ues-using.html My argument is this: if you want to return sensitive data for an AJAX app doing so using eval-able JS or even pure JSON increases the risk that your data could be hijacked via cross-site attacks. v/r -matt pitts _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
