On Wed, Mar 12, 2008 at 4:53 PM, Matt Pitts <[EMAIL PROTECTED]> wrote: > > -----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.
Just use server side auth for sensitive data. Using a format that's slightly harder to parse is no protection at all. > 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? _______________________________________________ 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/
