- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Wed, 16 Nov 2005 09:06:31 -0500
- To: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
- Cc: dawg mailing list <public-rdf-dawg@w3.org>
>> - whatever sanity checks one would implement (or specify) re: >> executing an arbitrary SPARQL query conveyed via (a) or (b) also >> apply to (c), and I don't believe (c) adds any additional constraints >> or holes (but I'm *not* a security expert)... > > I agree, but its not that simple. My understanding is that is OK by > the > spec. for services not to treat FROM etc. as an instruction to > load, and I > hope that publically accessible sites will, whereas a complaint impl. > would have to dereference the query-uri to find what it had to run. These seem completely isomorphic to me; any query service can refuse to load a URI in a FROM, and any query service can just as well (and for some of the same reasons) refuse to load a query-uri URI too. In both cases I assume -- per the specs -- that a query service could return QueryRequestRefused. > However, if there is a limit of one query-uri paramter then there > is a 1:1 > trade in requests, which is not too much of a security issue (the > attacker > may as well have issued the request to the third party itsself, it > just > adds a bit of obfuscation). Yes, it does make the tracing a bit harder. Granted. > PS incase anyone wonders why I'm so bothered about this, I have a > vision > of the future where SPARQL's FROM becomes the most popular > vector for > denial of service attacks... people'd really love us then. Yay! :> Cheers, Kendall
Received on Wednesday, 16 November 2005 14:06:49 UTC