[Catalyst] implementing ajax

[Wade.Stuart at fallon.com]

"Matt Pitts" <mpitts at a3its.com> wrote on 03/12/2008 11:53:45 AM:

> > -----Original Message-----
> > From: Jonathan Rockway [mailto:jon at jrock.us]
> > 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.

-Wade