Excellent post, Hattesen. It's a general best practice that any user input be escaped and encoded as appropriate and according to the syntax in which it will appear before it's processed or used in any part of the community. This includes all untrusted input such as any part of the URL, any input fields, any HTTP headers, search terms, etc. This gets a bit tricky with labels and tags allowing single or double quotes as you have already pointed out.
Re: your SQL injection concern - LiQL's syntax is very similar to a SQL statement. You are absolutely right again that tainted user input could definitely influence a LiQL query statement in freemarker templates. However, a major difference being that influencing the LiQL query will not give you access to the underlying SQL tables/db schema. That's because the LiQL query (REST API V2) is an abstraction layer which essentially maps to predefined objects and not SQL tables, for instances messages, authors, boards, etc. For every query we look at each of the fields to ensure that they match the object definition for the provided collection name. Influencing the syntax of the query will only allow an attacker to maneuver within the confines of prepackaged objects restricted through the lens of permissions assigned to the session.
Back to your question about the query syntax. This syntax will result in an error message.
SELECT id, body FROM messages WHERE labels.text = 'don't_do_this'
However, this syntax will *NOT* result is an error.
SELECT id, body FROM messages WHERE labels.text = "don't_do_this"
With regards to your comment about "the LiQL query will not give you access to the underlying SQL tables/db schema". Wouldn't you be able to construct a query that would add this to a WHERE term:
... OR true=true
... wouldn't that make the query return the entire content of the table, thereby possibly revealing too much information?
In other words: Can you categorically say, that an injection attack on a WHERE term can never result in additional information being returned in the result of the API 2.0 REST call?
