[Catalyst] implementing ajax

[Matt Pitts]

> -----Original Message-----
> From: Wade.Stuart at fallon.com [mailto:Wade.Stuart at fallon.com]
> Sent: Wednesday, March 12, 2008 1:50 PM
> To: The elegant MVC web framework
> Subject: RE: [Catalyst] implementing ajax
> 
> "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.

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