W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2005

Re: query by reference

From: Kendall Clark <kendall@monkeyfist.com>
Date: Wed, 16 Nov 2005 09:06:31 -0500
Message-Id: <82DEA723-FEEE-446F-B242-D609FD77ADDD@monkeyfist.com>
Cc: dawg mailing list <public-rdf-dawg@w3.org>
To: Steve Harris <S.W.Harris@ecs.soton.ac.uk>


>> - whatever sanity checks one would implement (or specify) re:
>> executing an arbitrary SPARQL query conveyed via (a) or (b) also
>> apply to (c), and I don't believe (c) adds any additional constraints
>> or holes (but I'm *not* a security expert)...
>
> I agree, but its not that simple. My understanding is that is OK by  
> the
> spec. for services not to treat FROM etc. as an instruction to  
> load, and I
> hope that publically accessible sites will, whereas a complaint impl.
> would have to dereference the query-uri to find what it had to run.

These seem completely isomorphic to me; any query service can refuse  
to load a URI in a FROM, and any query service can just as well (and  
for some of the same reasons) refuse to load a query-uri URI too.

In both cases I assume -- per the specs -- that a query service could  
return QueryRequestRefused.

> However, if there is a limit of one query-uri paramter then there  
> is a 1:1
> trade in requests, which is not too much of a security issue (the  
> attacker
> may as well have issued the request to the third party itsself, it  
> just
> adds a bit of obfuscation).

Yes, it does make the tracing a bit harder. Granted.

> PS incase anyone wonders why I'm so bothered about this, I have a  
> vision
>    of the future where SPARQL's FROM becomes the most popular  
> vector for
>    denial of service attacks... people'd really love us then.

Yay! :>

Cheers,
Kendall
Received on Wednesday, 16 November 2005 14:06:49 GMT

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