W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2011

Re: Followup to RC-4

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Thu, 29 Sep 2011 14:02:40 +0100
Message-ID: <4E846C70.3020503@epimorphics.com>
To: public-rdf-dawg@w3.org


On 27/09/11 23:09, Paul Gearon wrote:
> On Tue, Sep 27, 2011 at 4:58 PM, Steve Harris<steve.harris@garlik.com>  wrote:
>> On 27 Sep 2011, at 19:25, Paul Gearon wrote:
>>
>>> I don't know the process for modifying a document after Last Call, so
>>> I'm asking the list here.
>>>
>>> In Richard's email of RC-4 [1], he expresses concern that a harmful
>>> update operation may be embedded in a query:
>>>
>>>> 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.
>>>
>>> Andy has adequately addressed this concern by pointing out that Query
>>> and Update are two separate languages. However, since it is possible
>>> for an implementation to offer both services at one endpoint, I think
>>> it would be worthwhile explaining the risk in the "Security
>>> Considerations (Informative)" section of SPARQL Update.
>>>
>>> My proposed text is:
>>> ---
>>> While SPARQL Update and SPARQL Query are separate languages, some
>>> implementations may choose to offer both at the same SPARQL endpoint.
>>> In this case, it is important to consider that an Update operation may
>>> be obscured to masquerade as a query. For instance, a string of
>>> unicode escapes in a PREFIX clause could be used to hide an Update
>>> Operation. Therefore, simple syntactic tests are inadequate to
>>> determine if a string describes a query or an update.
>>> ---
>>
>> If the protocol is being used I believe it would be harder than that to exploit, if I'm reading it correctly that the parameter name is different
>> http://www.w3.org/TR/sparql11-protocol/#update-operation
>>
>> Doesn't that mean that an update request looks like
>>    http://host.example/?update=
>> as opposed to
>>    http://host.example/?query=
>>
>> - Steve
>
> That's a good point.
>
> The only case it might apply then would be for something like an HTML
> form which has a query/update field. This is much less likely to be an
> issue, and probably doesn't deserve special mention like I suggested.

All true - it's still worth adding that text in the security section as
?update=&query= may happen (even if that's not what the spec says) and 
it may come from a file.

The file extension is different (.rq, .ru)


-----
While SPARQL Update and SPARQL Query are separate languages, some
implementations may choose to offer *a combined service* at the same 
SPARQL endpoint.
In this case, it is important to consider that an Update operation may
be obscured to masquerade as a query. For instance, a string of
unicode escapes in a PREFIX clause could be used to hide an Update
Operation. Therefore, simple syntactic tests are inadequate to
determine if a string describes a query or an update.
----

but if you don't think the text is necessary, then that is also fine by 
me as well.

	Andy

>
> Paul
>
Received on Thursday, 29 September 2011 13:03:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:46 GMT