On 10/04/13 00:28, Rob Vesse wrote:
Ok I've now had time to look at this some more and managed to turn all the
previously identified injection attacks into detectable attacks
I took your suggestions and did some delimiter detection on the strings,
we have to track all relevant delimiters <>.,;{}()[]\n\r because we are
interested in the closest delimiters to the position we want to inject at.
I don't understand that - if injection is RDF terms only, it's only the
term delimiter of literals, IRIs
I also added the code to escape ' within literals which closes off that
vulnerability as well
I haven't yet looked at the other potential vulnerabilities you identified
e.g injecting things inside of <> so there may still be as yet
unidentified vulnerabilities which still need tests and fixing
Rob
I have one (more!) case - nothing to do in this situation, can just
leave it as an illegal query:
SELECT ?x { .. }
and ?x -> 1
The only possible thing to do that I can think of is a rewrite to
"SELECT (1 AS ?x) { .. }" but that needs much more parsing to detect the
situation and isn't worth it.
Similarly
SELECT ?x (count(*) AS ?c) { .. } GROUP ?x
==>
SELECT ?x (count(*) AS ?c) { .. } GROUP (1 as ?x)
and now it's got really complicated because the SELECT expression isn't
touched.
As far as I can see, ORDER BY simply can't be done.
All these are technical and don't really increase the value of
parametrized queries in anyway.
Andy
Unrelated: I get two warnings for two @SuppressWarnings("unused")
because I don't have unused method detection turned on.
We may need to agree the compiler warning settings for the code base.
