Re: Update security issues

On 12/14/2010 1:36 PM, Paul Gearon wrote:
> As per ACTION-285, I have compiled a list of security issues for SPARQL Update:

Great.

> * Write access to data makes it inherently vulnerable to malicious
> access. Standard access and authentication techniques should be used
> in any networked environment. In particular, HTTPS should be used,
> especially when implementing the SPARQL HTTP-based protocols. (ie.
> encryption with challenge/response based password presentation,
> encrypted session tokens, etc). Some of the weak points addressed by
> HTTPS are: authentication, active session integrity between client and
> server, preventing replays, preventing continuation of defunct
> sessions.
>
> * SPARQL Update incurs all of the security concerns of SPARQL Query.
> In particular, stores which treat URIs as dereferencable need to
> protect against dereferenced URIs from being used to invoke cross-site
> scripting attacks.

These two look good to me.

> * Some stores may have different permissions on various graphs. Update
> operations that legally modify one graph may try to use those access
> permissions to escalate permissions on another graph referenced in the
> operation or an embedded query. Isolating access will be important in
> this scenario.

I think the general point (implementations should make sure to enforce 
their store's standard permissions scheme) is good, but I might reword 
this a bit.

> * Ensure correct escaping of literal strings to avoid injection
> attacks. This is more of a user issue though a poor parser can
> exacerbate the problem. Also many stores include a web front end,
> which may act as a client vulnerable to this problem.

I don't think this one belongs in the update document as it's more of a 
client issue.

> * URIs in queries can contain escaped payloads using %HH. This
> interacts with the other security concerns surrounding URIs, as it can
> be difficult to detect malicious operations encoded within URIs.

I'm not sure what this one means.

> * Update operations must not be accessible with GET requests. Other
> than breaking HTTP semantics and being outside of the SPARQL protocol
> specification, this permits embedding an Update into a URI that is
> accessed inside another operation.

Should this go in the protocol document?


> This list is not complete, nor do I believe it to be possible to
> create a complete list. I would appreciate comments on the above
> points, plus any additions that should be included.

Yup. I think you ought to go and incorporate these (with any changes) 
into the document.

Lee

>
> Regards,
> Paul Gearon
>
>

Received on Tuesday, 21 December 2010 09:59:26 UTC