[erlang-questions] Two beautiful programs - or web programming made easy

[Frédéric Trottier-Hébert]

Replies are still in between bits of text.
On 2011-02-13, at 15:43 PM, Edmond Begumisa wrote:

> On Mon, 14 Feb 2011 05:59:19 +1100, Frédéric Trottier-Hébert <fred.hebert@REDACTED> wrote:
> 
>> 
>> On 2011-02-12, at 06:33 AM, Joe Armstrong wrote:
>> 
>>> 
>>> The Javascript equivalent is:
>>> 
>>>  function onMessage(evt) {
>>>     eval(evt.data);
>>>  }
>>> 
>>> Where the data comes from a websocket.
>>> 
>> This is rather risky. Eval will take any code whatsoever and run it for you.
> 
> Likewise the browser will take any static js (<script> tags) whatsoever from your server and run it for you.

Right. This is why ideally you want to pass in very precise function and do something RPC-like (despite Joe not liking it) or have your own parser (as it is the case with JSON). It's not that it's impossible to make the other ways safe, but I wouldn't trust most people (including myself) to get it right most of the time. 
> 
>> If you have dynamic content, without proper escaping and being very careful, users could run arbitrary code in your page, including stuff to steal session data and send it over to either some other site, or perform actions for the user which they do not necessarily approve on (making their profile public, closing their account, worms, etc.)
>> 
> 
> Likewise if you have any dynamic content in js code on your server without proper escaping and not being very careful, users could...

Exactly. You're always as safe as your weakest link. Some frameworks (like JQuery on some methods) handle it for you, but usually there is no such thing for 'eval'.

> ... Don't the "same source" XXS rule for non-evaled code apply to evaled code? Doesn't the same duty of care to end-users for protecting privacy, properly escaping data, etc, apply in both cases? Don't you have to be careful either way?
> 

Yes. But some ways to do things are safer than others by default. The problem with 'doing things right' is how much trust you put in yourself and your team of developers. I'm of the opinion that most people who feel good enough to handle security actually overlook a lot of it. Have you always checked everything for XSS in all encodings? CSRF? Ever used something like MD5 or SHA to hash passwords? Sent such passwords over e-mail, etc? Those are very basic options and I can tell you that most developers to have worked on the web had a problem with at least one of these at some point or another one. Hell, even gmail had sever CSRF holes at some point that let people randomly inject themselves into your forwarded email adresses.

Security is hard, and stepping clear of the risky line is often a good option if you're not 100% sure of what you're doing. A cook skilled enough can likely prepare a meal while juggling with knives safely, but it's often not necessary to do so, and often not appropriate for everyone to follow that line either.

>> In fact, this is a reason why people like Douglas Crockford prefered to write JSON parsers rather than just evaluating them. It's just not safe enough.
>> 
> 
> Indeed you are correct, but...
> 
> From http://www.json.org/js.html ...
> 
> "...The use of eval is indicated when the source is *trusted* and *competent*..."

The *competent* part is the one that worries me. I think most developers (myself included) tend to overestimate their competence when it comes to security. 
> 
> "...In web applications over XMLHttpRequest, communication is permitted only to the same origin that provide that page, so it is *trusted*. But it *might not be competent*. If the server is not rigorous in its JSON encoding, or if it does not scrupulously validate all of its inputs, then it could deliver invalid JSON text that could be carrying dangerous script..."
> 
> So it boils down to the competence of the code on the server. You have to be careful how you construct your pages and javascript. But then, this should *always* be the case.

Yes, agreed. Again, I'm supporting the position of 'why risk it?' not the line of 'it's impossible to be safe!'

>> Plus you have to call the javascript parser and whatnot, which is usually rather slow.
> 
> One could send core of the app logic in a static js file then have the eval only making simple calls like "appui.getInvoinces()". That will perform fairly well.

Yes, if the invoices do contain fairly limited and well-defined data that you know can *never* cause a problem. 
> 
>> The whole idea is pretty bad on the web, where you have to assume that people will actively try to break your stuff and steal data from other users (or you).
>> 
> 
> That assumption is a bit dramatic. Questions on security cannot be viewed in isolation of application. One of my favorite quotes from Bruce Schneier is applicable here. He was once asked about the possibility of chaos ensuing due to internet security breaches...
> 
> "No. Chaos is hard to create, even on the Internet. Here's an example. Go to Amazon.com. Buy a book without using SSL. Watch the total lack of chaos."

The idea is fairly dramatic, but the concept is basically that once someone's got an axe to grind against you or your applications, then someone actively trying to break your stuff is *actually* going to happen. A lax attitude is what made one of our products (at some previous job) vulnerable to Russian hackers who ended up emailing customers with addresses stolen straight out of our databases. When it happens, it's already too late to react.
> 
> I don't see how you can canvas the "whole idea" as being bad. It may require adjustments here and there. e.g For particular pages where paranoid security is needed, nothing stops you from doing it differently there. You could crypto what's sent. You could even serve those pages the standard way with static files and SSL if it makes you feel safer.

SSL is protecting you against things like man-in-the-middle attacks. Encryption helps you on other points. There is nothing there regarding problems with application-level security. The whole idea is not bad, but I would certainly want a serious specialist to look over my application if I were to use that trick in many places.


> 
>>> 
>>> This technique is amazingly powerful.
>>> 
>>> So now I only need one generic web page. Think of that.
>>> 
>>> Only one page is needed - forever.
>>> 
>> This is a problem when it comes to bookmarks, sharing the link with a friend, searchability, browser history, etc. The web wasn't exactly intended to be a stateful thing and you'll have to resort to hacks such as hash-bangs to get around it. I suggest reading  Tim Bray's Broken Links to see why that isn't a good solution anyway.
>> 
> 
> True. But this problem is an age-old general AJAX/dynamic-markup problem. I agree it might be very visible in this case.
> 
> However, I've written XULRunner apps with no back buttons -- no need for them with easy-to-navigate UIs. Most Adobe AIR apps I've seen have no browser history. It's made me question: How badly do end-users really need those things? If they do, couldn't we give them better application-specific versions inside our web-app UI?

If I'm using a browser, I'd enjoy being able to use the web. What constitutes a 'very easy to use' application to you might  not be the same for everyone. I do remember many flash pages falling pray to the same problem. I think this is mostly a deeply rooted problem in the web where you're piggy-back riding sessions on a protocol that was absolutely not made for that. It sometimes works well enough (I'm thinking of chat applications or even grooveshark here), so it's certainly not black and white, but I figure you know what I mean.
> 
>> Plus I'd argue that javascript and Erlang should be kept separate and you shouldn't try to generate one with the other,
> 
> Good point. I thought about sending the js in static files and reducing the calls from Erlang to simple one-liners. But also note that the more powerful aspect of this (IMO) is not just sending js, but sending UI elements. Sending blocks of UI to an empty page! How can anyone not like that?
> 
Separation of concerns. JS is about behaviours on the page, dynamic content. UI is both HTML (structure) and CSS (presentation). One very simple question I like to ask to sort this out is "would I be able to hire a designer to work on my site without guiding them around too much?" "Could I hire someone to just work on my javascript and HTML without them needing to know anything else?"

If you say no to these, you might have some overlapping domains in what you're doing.

Then again, I'm a fan of really well-separated components in my applications, which is why I like Erlang's processes and OTP applications in the first place :)

Another advantage of keeping things separate is caching -- this is however pretty application and audience specific in terms of needs and requirements.

> - Edmond -
> 
>> but at this point, I figure it's more of a matter of who wants to give himself the trouble than anything.
>> 
>> 
>> --
>> Fred Hébert
>> http://www.erlang-solutions.com
>> 
>> 
> 
> 
> -- 
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


--
Fred Hébert
http://www.erlang-solutions.com