Re: Security Concerns section added to Query_by_reference

On 8 Apr 2009, at 19:11, Axel Polleres wrote:
> 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?

Perhaps, I can see the argument for using it to restrict the dataset  
used to answer queries, from a predefined set, but we have GRAPH too.

I can also see the argument for services that want to dynamically  
query graphs they've just dereferenced, it's just that you have to be  
aware that there are serious security concerns. In that situation you  
have no real choice, but this feature feels more like a band-aid to  
get round the fact that we don't have stored procedures, so not worth  
the pain IMHO.

If anyone had a use-case that it better served by QbR than stored  
procedures, then I would be more motivated.

> 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.

That makes no real difference, infact in many ways it's worse than the  
inverse filter. That's the point of the above example. The key problem  
is that the SPARQL endpoint is inside the hosting network, and the  
client is outside. When you have that situation all kinds of bad  
things can happen. It's exactly like having a tunnel from outside the  
firewall to inside. Security people tend to get nervous about things  
like that, and rightly so.

In a situation where everyone involved in the security architecture,  
firewall configuration and deployment has a clear understanding of the  
side effects of hosting a particular SPARQL store then it can be OK.  
However that's rarely the case in my experience.

- Steve

-- 
Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD

Received on Thursday, 9 April 2009 08:58:50 UTC