Re: Security issue in SPARQL string escaping in SPARQL grammar

Hi Steve (and all),

This is a personal reply, and isn't an official response....

On Tue, Dec 6, 2011 at 5:27 AM, Steve Harris <steve.harris@garlik.com> wrote:
> On 2011-12-05, at 21:42, Paul Gearon wrote:
>
>> On Mon, Aug 15, 2011 at 6:24 AM, Richard Cyganiak <richard@cyganiak.de> wrote:

<snip>

>>> 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.
>
> [this is Garlik's view, not an official response]
>
> This is a common, but extremely dangerous misconception.
>
> Security considerations aren't just about changing the contents of the database, it's also an issue with being able to make the SPARQL endpoint perform requests on behalf of the attacker.
>
> SERVICE makes this obvious/easy in SPARQL 1.1, but even 1.0's FROM is a possible source of attacks.

<snip>

> Will cause some SPARQL endpoints to issue 6 HTTP requests *from inside the host's security zone* - this is both an escalation attack (1 request triggers 6), and also an indirection attack.

I completely agree with you here Steve. I believe that this is
addressed in the SPARQL Update Appendix A (Security Considerations -
Informative):

"SPARQL Update incurs all of the security concerns of SPARQL Query. In
particular, stores which treat IRIs as dereferenceable need to protect
against dereferenced IRIs from being used to invoke cross-site
scripting attacks."

I could update this to mention escalations.

Outside of Richard's question (an official response to that will be
forthcoming shortly), and the need for authentication and
authorization, I think that most of the security concerns for Update
are also concerns for Query. Can you think of other issues?

Regards,
Paul Gearon

Received on Wednesday, 7 December 2011 18:41:13 UTC