Re: Security Concerns section added to Query_by_reference

Steve Harris wrote:
> On 7 Apr 2009, at 14:35, Gregory Williams wrote:
> 
>> On Apr 7, 2009, at 8:01 AM, Steve Harris wrote:
>>
>>> OK, here's one example:
>>>
>>> Imagine a corporate system, inside a firewall, hosting a number of 
>>> services, and a SPARQL endpoint. There's a hole/bridge through the 
>>> firewall to allow outside people to connect to the SPARQL store and 
>>> issue approved queries by reference.
>>>
>>> The systems inside the firewall are all in secure.example, eg. 
>>> sparql.secure.example, and services1.secure.example.
>>>
>>> The SPARQL store is configured to only accept references from 
>>> services1.secure.example, a machine that uses SPARQL to provide 
>>> services.
>>>
>>> An attacker issues a request like 
>>> ?query-ref=http://services1.secure.example/service/delete-all
>>>
>>> As far as the SPARQL endpoint is concerned, that's legitimate, so it 
>>> might reasonably try and dereference that URI (which is obviously a 
>>> bad idea to a human).
>>
>> I'm still not getting how this is different from using a "FROM 
>> <http://services1.secure.example/service/delete-all>" clause in the 
>> SPARQL query? The underlying problem here seems to me to be the 
>> existence of a HTTP GET operation that is deleting data, and which 
>> could be triggered by a FROM clause, a query-ref URI, or even a 
>> malicious webpage loaded from inside the firewall. Surely any security 
>> measures you take with regard to FROM clauses can be applied to 
>> query-ref URIs?
> 
> I never thought FROM was a good idea either :) I had the same concerns 
> in the previous working group. I wouldn't find the "well, we've already 
> let the genie out of the bottle" argument very convincing with regard to 
> repeating the mistake.

Hmmmm, not sure whether understand you right here:

Don't make FROM/FROM NAMED also make sense when asking graph specific 
queries to a quad store, i.e. if the FROM/FROM NAMED clauses refer to 
graphs in that store rather than Web dereferenceable graphs?

And second, wouldn't restricting the allowed URIs to certain namespaces 
  that the provider of an endpoint controls -- which every endpoint can 
do, be enough to cover the dangerous effects you are mentioning? I (and 
it appears to me the current spec as well) rather consider an 
implementation issue that is left open by design, to be honest.

Thanks for clarification,
Axel

> Also, The wording of FROM makes it clear that you're not required to go 
> an dereference anything. query-ref could do the same, but I'd rather we 
> addressed these problems.



> I would rather see something more like stored procedures, where clients 
> supply the canned query directly.
> 
> - Steve
> 


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/

Received on Wednesday, 8 April 2009 18:12:01 UTC