CommentResponse:RC-4

In http://www.w3.org/TR/2011/WD-sparql11-query-20110512/#grammar it says that the SPARQL WG considers the following change:

> • The escape processing model for \u escapes changes to be an additional escape for like \" or \t, not a replacement done before grammar parsing.

I strongly support this change.

Thank you for saying this. Positive and negative feedback are both useful.

With the addition of SPARQL UPDATE, the current design becomes a serious security risk.

Consider the following query, which deletes the contents of a store:

  PREFIX : <> DELETE { ?s ?p ?o } #> SELECT { ?s ?p ?o }

This potentially harmful query can be obfuscated using string escapes, resulting in a harmless-looking query:

  PREFIX : <\u003E\u0020\u0044\u0045\u004C\u0045\u0054\u0045\u0020\u007B\u0020\u003F\u0073\u0020\u003F\u0070\u0020\u003F\u006F\u0020\u007D\u0020\u0023> SELECT { ?s ?p ?o }#

The risk is that a) users can be tricked into running harmful queries, and b) software that uses
heuristics to detect queries with potential security impact will be less likely to work.

This may have been ok in SPARQL 1.0, but with the addition of SPARQL UPDATE this is an unacceptable risk.

I am surprised that the security issues arising from obfuscation through string escaping are not
stated in the Security Considerations sections of SPARQL Query and SPARQL Update.

The SPARQL query language and SPARQL update language are separate languages. While they share a lot, the top level productions for query does not include update commands and the top level production for update does not include query.

Therefore it is not a security consideration for SPARQL Query because DELETE, INSERT etc are not part of the language at all.

Security is one reason for making this distinction. A complete and compliant implementation of SPARQL Query offered at an endpoint will reject updates (whether this escape change is made or not) because they do not parse as queries. A service is free to offer both at the same endpoint but it is the service's responsibility and having two languages makes that clear. Common practice is to have different endpoints for query and update, which can have different security setups.

SPARQL Update does not return any results except the HTTP status code.

The WG also considers the following change:

> • As part of the changes to the escape processing model for \u escapes, additional characters (e.g. "=", ",") would be allowed, in \u escaped form, in prefixed names.

The RDF-WG has resolved to add character escapes to prefix names for characters that are allowed in IRs but not currently in the local part of a prefix name.

http://www.w3.org/2011/rdf-wg/meeting/2011-11-30#resolution_1

The set of character is ~.-!$&'()*+,;=:/?#@%_

The SPARQL-WG has decided to also add this (as an "at-risk" feature) to SPARQL 1.1, also to have unescaped %-endoced sequences, and to leave the unicode escape processing model as it is in SPARQL 1.0. While the use of unicode escape sequences is still possible, the WG believes it will not be commonly used. Authors do not need to use unicode escape sequences to get characters into the local part of a prefix name.

I oppose this change, as there is no use case for it. Prefixed names are a convenience for authors to make long IRIs easier to write and read. Escapes like \u003D and \u002C are neither easy to write nor easy to read, so they defeat the purpose of prefixed names. IRIs that include such characters just have to be written as absolute or relative IRIs.

Best,
Richard

We would be grateful if you would acknowledge that your comment has been answered by sending a reply to this mailing list.

Andy and Paul (on behalf of the SPARQL WG)