app data escaping and escapeString

[Brian Eaton]

Is some brave soul willing to brave shark-infested waters and document
a "consensus" version of the app data escaping and
gadgets.util.escapeString proposals? I've read over the threads, I
think we may be able to agree on something, but I don't feel
comfortable writing up the proposals myself.

Cheers,
Brian

[Zhen Wang]

I don't think we've reached a consensus yet :)
Anyway, here's my proposal for gadgets.util.(un)escapeString.

/**
* Escapes '"', '&', '<', and '>' so that a string can be safely
included in innerHTML or an HTML
* tag attribute value within double quotes.
* @param {string} str String to escape.
* @returns {string} HTML-escaped string.
*/
gadgets.util.escapeString = function(str) {
return str.replace(/&/g, '&amp;').replace(/</g,
'&lt;').replace(/>/g, '&gt;').replace(/"/g, '&quot;');
};

/**
* Unescapes an HTML-escaped string.
* This is a reverse function of gadgets.util.escapeString.
* @param {string} str String to unescape.
* @param {string} HTML-unescaped string.
*/
gadgets.util.unescapeString = function(str) {
return str.replace(/&([^;]+);/g, function(s, entity) {
switch (entity) {
case 'amp':
return '&';
case 'lt':
return '<';
case 'gt':
return '>';
case 'quot':
return '"';
default:
// Do not process other entities
return s;
}
});
};

[Reinoud Elhorst]

+1 -- it seems we need to wrap this up before tomorrow night, I like this very much, and still volunteer for the deep-dive (into the shark-infested waters : ) ) for escaping in 0.9 -- somewhere next week.

[Brian Eaton]

[+pvalchev directly]

Let me see if I read your proposal correctly.

- the return value of escapeString will be safe to use as innerHTML.
- it is not safe as an HTML attribute of any type, href or otherwise.
- it is not safe as a javascript string.
- it is not idempotent.
- escapeString and unescapeString are functional inverses.

Have I understood it properly?

Cheers,
Brian

[Peter Valchev]

On Tue, Apr 29, 2008 at 2:12 PM, Brian Eaton <bea...@google.com> wrote:
> [+pvalchev directly]
>
> Let me see if I read your proposal correctly.
>
> - the return value of escapeString will be safe to use as innerHTML.
> - it is not safe as an HTML attribute of any type, href or otherwise.
> - it is not safe as a javascript string.
> - it is not idempotent.
> - escapeString and unescapeString are functional inverses.
>
> Have I understood it properly?

The only change I think is to escape '&' to '&amp;' and same for
unescape. This has nothing to do w/ security anymore and only to do
with double escaping producing incorrect results (&amp;amp;). Again,
we discussed this a few months ago, and it was decided to NOT escape
'&' for that reason. From security standpoint this is irrelevant, I
personally suggested to escape '&' as it is weird otherwise, but it
was argued that gadget developers will be confused. If it is now
commonly believed that this is OK, go for it (Kevin, didn't I talk to
you about this?)

[Kevin Brown]

I agree with just adding ampersand escaping to the mix, but, again -- we can *only* do it if auto escaping can be bypassed everywhere that it was turned on.

This means:

- most getField calls
- app data in general
- user prefs
- view parameters

[Cassie]

Alright, let's continue this discussion and get this all into 0.9
This is closed for 0.8

Thanks.
- Cassie