- From: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
- Date: Wed, 16 Nov 2005 09:25:05 +0000
- To: dawg mailing list <public-rdf-dawg@w3.org>
On Tue, Nov 15, 2005 at 04:43:42PM -0500, Kendall Clark wrote: > I'd like to propose adding that back to the protocol design. > Basically we're talking about adding another parameter (in HTTP), > "query-uri", the value of which would be a URI which, when > dereferenced, would return a representation of a SPARQL query > resource. That would add a third way to "convey a query" to a SPARQL > query service: Sounds good to me. > a. POSTing a urlencoded query in the body of an HTTP request > b. serializing a query in a URI (in the 'query' parameter) > c. 'pointing' at a query on the Web and asking the service to deref > and execute it > > I don't believe this opens any additional security or implementation > burdens since: > > - we already allow arbitrary URIs to be deref'd to load data > > - 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. 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). 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. - Steve (also *not* a security expert)
Received on Wednesday, 16 November 2005 09:25:21 UTC