Update security issues

As per ACTION-285, I have compiled a list of security issues for SPARQL Update:


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

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

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

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

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



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.

Regards,
Paul Gearon

Received on Tuesday, 14 December 2010 18:37:25 UTC