RE: [Catalyst] Re: implementing ajax
> -Original Message- > From: J. Shirley [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 13, 2008 11:51 AM > To: The elegant MVC web framework > Subject: Re: [Catalyst] Re: implementing ajax > > On Thu, Mar 13, 2008 at 6:41 AM, KH <[EMAIL PROTECTED]> wrote: > > The only /real/ vulnerability to JSON - as I understand it, and I > could be > > wrong - is when you read JSON from untrusted hosts. JSON doesn't > have the > > requirement like XML does that the response come the from the same > host that > > you requested it from - and this where some of the cross-site > scripting > > exploits come in to play (as I understand it). But I'm sure there > are some > > pretty good ways of mitigating that risk. The two ways I can think > of off > > the top of my head are: including a sha-1 challenge in every request, > and > > sha-1 response with the returned data; or just crypt every data field > with a > > cheap encryption scheme using a certificate you push to the client. > > Actually, I just read a great article on pushing certs to the client: > > http://drnicwilliams.com/2008/02/22/zero-sign-on-with-client- > certificates/ > > This is incorrect, you can read XML and JSON from 3rd party domains if > you know how to instruct the browser to do it. The browser will only > limit host if you use XmlHttpRequest as the transport. The format of > the data has nothing to do with the security rules applied to > transport. > > If you try to do an XmlHttpRequest to a different domain, it will > fail. It doesn't know anything at all about the format - you can send > anything: plain text, html, JSON, PHP Serialization. To handle > cross-domain requests, you can use an iframe transport and it will > work for any other domain, regardless of the wireformat. Cross-site > scripting is a completely different beast, though. > > The real core issue is that relying on the browser to always do what > you want is not a good idea, much like trusting the referrer headers. > Just don't. > > Code responsibly, and JSON and XML are both equal in this regard - > done responsibly the only difference is personal taste. I'll have to concede to the greater knowledge levels of those around me. I guess JSON just scares me more because of how close it is to being eval-able by a malicious client and captured with a simple
Re: [Catalyst] Re: implementing ajax
One JSON security tangent worth knowing:
http://bob.pythonmac.org/archives/2007/04/05/fortify-javascript-
hijacking-fud/
Why I mentioned earlier, wrap it in "{}."
-Ashley
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: implementing ajax
On Thu, Mar 13, 2008 at 6:41 AM, KH <[EMAIL PROTECTED]> wrote: > The only /real/ vulnerability to JSON - as I understand it, and I could be > wrong - is when you read JSON from untrusted hosts. JSON doesn't have the > requirement like XML does that the response come the from the same host that > you requested it from - and this where some of the cross-site scripting > exploits come in to play (as I understand it). But I'm sure there are some > pretty good ways of mitigating that risk. The two ways I can think of off > the top of my head are: including a sha-1 challenge in every request, and > sha-1 response with the returned data; or just crypt every data field with a > cheap encryption scheme using a certificate you push to the client. > Actually, I just read a great article on pushing certs to the client: > http://drnicwilliams.com/2008/02/22/zero-sign-on-with-client-certificates/ This is incorrect, you can read XML and JSON from 3rd party domains if you know how to instruct the browser to do it. The browser will only limit host if you use XmlHttpRequest as the transport. The format of the data has nothing to do with the security rules applied to transport. If you try to do an XmlHttpRequest to a different domain, it will fail. It doesn't know anything at all about the format - you can send anything: plain text, html, JSON, PHP Serialization. To handle cross-domain requests, you can use an iframe transport and it will work for any other domain, regardless of the wireformat. Cross-site scripting is a completely different beast, though. The real core issue is that relying on the browser to always do what you want is not a good idea, much like trusting the referrer headers. Just don't. Code responsibly, and JSON and XML are both equal in this regard - done responsibly the only difference is personal taste. -J ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: implementing ajax
I think the 2007 Calendar had a great Javascript/JSON/Catalyst tutorial.
http://catalyst.perl.org/calendar/2007/9
If you've never used javascript with callbacks before, or even if you have,
it's a great reference.
Honestly, I find myself modeling much of how I use javascript after how that
example works,
as it's really a simple approach - and simple is better imho.
The only /real/ vulnerability to JSON - as I understand it, and I could be
wrong - is when you read JSON from untrusted hosts. JSON doesn't have the
requirement like XML does that the response come the from the same host that
you requested it from - and this where some of the cross-site scripting
exploits come in to play (as I understand it). But I'm sure there are some
pretty good ways of mitigating that risk. The two ways I can think of off
the top of my head are: including a sha-1 challenge in every request, and
sha-1 response with the returned data; or just crypt every data field with a
cheap encryption scheme using a certificate you push to the client.
Actually, I just read a great article on pushing certs to the client:
http://drnicwilliams.com/2008/02/22/zero-sign-on-with-client-certificates/
Infact, here a couple articles that hit the AJAX(y) JSON/XSS/etc..
vulnerabilities - but really, look at the data your serving and your
potential audience when deciding on the level of security you need:
http://secwatch.org/advisories/1020538/
http://www.securityfocus.com/infocus/1881
http://jibbering.com/blog/?p=514
http://jpsykes.com/47/practical-csrf-and-json-security
On Thu, Mar 13, 2008 at 5:57 AM, Aristotle Pagaltzis <[EMAIL PROTECTED]>
wrote:
> * Jennifer Ahn <[EMAIL PROTECTED]> [2008-03-12 18:20]:
> > I'm sure that JSON and all the other goodies are perfect tools
> > for implementing ajax, but i would like to learn what's really
> > going on in teh black box before I use it.
>
> JSON is not a "blackbox." (Does that even mean anything?) It's
> simply a data format. It's no different from XML in this respect,
> it's just a much simpler format than XML that looks exactly like
> Javascript (though that doesn't mean you should `eval` it, as
> Jonathan said) and deserialises to plain old in-memory Javascript
> data structure. Therefore it's much easier to work with on the
> client than XML is: you write regular Javascript object/array
> accesses instead of painstakingly examining a DOM.
>
> That's it. That's all there is to it.
>
> > So far, my javascript is able to send an xmlhttprequest to my
> > catalyst controller method which then does some processes and
> > outputs data into an xml document. i'm having trouble sending
> > that document over to my xmlhttprequest.responseXML object. in
> > my controller:
> > my $writer = new XML::LibXML::Document;
> > ... do some process and spit out into an xml document...
> > $c->response->content_type('text/xml');
> > $c->response->write($writer);
> >
> > When the xmlhttprequest is ready, I plan to parse the
> > req.responseXML object using XMLSerializer in my javascript
> > code.
>
> The code to send JSON looks pretty much identical.
>
>use JSON::XS;
>$c->res->content_type('application/json');
>$c->res->body(encode_json($c->stash));
>
> Regards,
> --
> Aristotle Pagaltzis //
