Clarify the use of $PATH, or string interpolation of SHACL paths

[VladimirAlexiev]

Sec 5.2 Syntax of SPARQL-based Constraints:

SELECT queries used in the context of property shapes use a special variable named PATH as a placeholder for the path used by the shape.

The only legal use of the variable PATH in the SPARQL queries of SPARQL-based constraints and SELECT-based validators is in the predicate position of a triple pattern.

But if sh:path is complex (not a predicate), it cannot be used in this way.

So I suggest adding two clarifications:

• "(spelled in UPPERCASE)" because SPARQL var names are case-sensitive
• "This can only be used with simple sh:path that consists of a single predicate. For complex sh:path, write the property path in SPARQL syntax in the query."

[afs]

If the sh:path is complex, and $PATH is correctly used (predicate position of a triple pattern), then converting a SHACL path to SPARQL string syntax, and then doing string substitution should work.

That said, such string substitution can be an injection attack vector and that would be a principled reason to not allow complex paths. (Value injection is a safe mechanism for injecting into a query.)

[VladimirAlexiev]

I agree that converting a SHACL path to SPARQL string syntax would be a very useful feature, and it would enable the use of a lot more general SPARQL templates.
Changed the title of this issue accordingly.

I'm not very worried about SPARQL injection because we're not talking random strings here. An engine should check that sh:path corresponds to the syntax for SHACL paths and if not, then it can emit eg "BAD-PATH" or something similar.

So what do others think, should the new spec require it from engines? https://www.w3.org/TR/shacl/#dfn-path-mapping is already defined, what we're talking about is taking the mapping result and interpolating it in sh:select

[VladimirAlexiev]

A bit related: #165

[HolgerKnublauch]

@VladimirAlexiev I don't understand where the problem remains. As Andy has clarified this can be used to insert any path, and well-formed SHACL shapes graph will only contain valid path expressions, which have a well-defined mapping to SPARQL syntax.

Can this be closed?

[VladimirAlexiev]

@afs can you give an example how such interpolation can be an attack vector?

@HolgerKnublauch So do you agree with interpolating complex paths in sh:select?
Then the spec needs an addition.

[HolgerKnublauch]

Yes complex paths can be used in sh:select and the spec already allows this. Please re-read and make a PR on what exactly you mean.

[afs]

string substitution can be an injection attack vector

:s $PATH :o and a string PATH=":p :o . ?x ?y ?z . ?a ?b ?c . :s :p"

[VladimirAlexiev]

@afs The mis-user cannot assign to $PATH. That is formed by the engine from a SHACL prop path.

@HolgerKnublauch I see it at https://www.w3.org/TR/shacl12-sparql/#dfn-substituted
and https://www.w3.org/TR/shacl/#dfn-substitute: sorry I missed it !!!

prior to execution substitute the variable PATH where it appears in the predicate position of a triple pattern with a valid SPARQL surface syntax string

There are 2 places that say:

The only legal use of the variable PATH in the SPARQL queries of SPARQL-based constraints and SELECT-based validators is in the predicate position of a triple pattern.

Do you agree for me to add in these 2 places a reference to #dfn-substituted?

[HolgerKnublauch]

@VladimirAlexiev if you have a PR I'd be happy to review. This is probably the most precise way of making progress here.

[HolgerKnublauch]

@VladimirAlexiev if you still want to see progress on this, I would appreciate a PR before the end of the month so that we can try to freeze the SPARQL document.