Thursday, January 31st, 2008

Secure String Interpolation in JavaScript

Category: JavaScript, Library, Security

<p>Mike Samuel of the Google Caja team (and much more) has a fantastically detailed document on the choices for secure String interpolation in JavaScript.

He spends a lot of time discussing:

There are a large number of examples a long the way:

javascript
< view plain text >
  1. var ids = [1, 2, 3, 4];
  2. var column = 'value';
  3. var foo = 'foo';
  4.  
  5. open(Template("SELECT $column FROM Table WHERE id IN $ids AND foo LIKE $foo"))
  6. // === "SELECT `value` FROM Table WHERE id IN (1, 2, 3, 4) AND foo LIKE 'foo'"

Posted by Dion Almaer at 10:46 am
5 Comments

+++--
3.7 rating from 25 votes

5 Comments »

Comments feed TrackBack URI

Wow, very cool.

Comment by kriszyp — January 31, 2008

I love this php style string concatenation. nice work.

Comment by phpcs — January 31, 2008

While this article is very interesting i’d mention just one sentence that stroke me:

“…and requires the programmer to know a lot about the language”

If anyone hopes to manipulate anything without KNOWING the apropriate language, then he/she is heading toward big problems. The best security is being conscious about what you’re doing. RTFM & test & anticipate -> this seems pretty obvious, isnt’it?

Comment by sam — January 31, 2008

“SELECT x, y, z FROM Table WHERE id IN ($set_of_ids)”
The author states that :
“If a programmer wants to specify multiple ids, they are out of luck. The system is incomplete, and so the programmer falls back on – string interpolation or outright hackery.”

While the following is not perfect, and it would obviously better if you could bind an array to an IN clause, it doesn’t qualify as “outright hackery”:
SELECT x, y, z FROM Table WHERE id IN (?, ?, ?).
Of course you’ve got to create the SQL statement with the appropriate number of ?’s.

Comment by Jonathan Leech — February 1, 2008

Sam said
If anyone hopes to manipulate anything without KNOWING
the apropriate language, then he/she is heading toward
big problems. The best security is being conscious about
what you’re doing. RTFM & test & anticipate -> this
seems pretty obvious, isnt’it?

I agree. Most languages have quirks and little-understood corners.

You can either try and prevent people from using those poorly defined/understood parts (Doug Crockford makes a strong case for this in “Javascript: The Good Parts”) but that requires educating users about the good parts.

Or you can change the language to behave the way user’s expect as this article attempts to do.

Both approaches are valid in some circumstances, but I think that for large languages (like HTML and CSS) the latter approach is better. I think requiring every user to have an exhaustive knowledge of the whole schema before they can use any part of the language hurts adoption, so taking a hard line will not help you replace existing insecure languages with a more secure alternative.

Comment by MikeSamuel — August 6, 2008

Leave a comment

You must be logged in to post a comment.