[Catalyst] implementing ajax

[luke saunders]

On Wed, Mar 12, 2008 at 4:53 PM, Matt Pitts <mpitts at a3its.com> wrote:
> > -----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.

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?