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/