Although the new restrictions on pre-binding eliminates the SERVICE construct, the potential denial-of-service aspects of SERVICE should be mentioned in Appendix E. These denial-of-service aspects can still exist when using trusted information because the SERVICE may be invoked a very large number of times.

I have added a sentence.

Please close this and other issues when satisfied.

Someone who has experience in writing these sections should be involved.
The problem is not the same as the one inherited from SPARQL. Because SHACL-SPARQL can evaluate SPARQL queries very many times it introduces a new source of denial-of-service attacks.

I don't think that this issue can be labelled as editorial. Although it does not affect implementations it does affect something important to W3C.

What other SPARQL constructs (in addition to SERVICE) would push the computational impact out of the SHACL-SPARQL engine to some other processor? Would a malformed constraint component (whether intentionally malicious or not) only have such an impact using SERVICE?

If the SHACL implementation uses a separate service to handle part of its work, for example a separate SPARQL service possibly modified to support SHACL, processing a single SHACL validation request can result in very many requests to the other service without having the SHACL implementation do much work. The SHACL implementation then can serve as a sanitizer and force multiplier for attacks.

Note that I am by no means a security expert. I only noticed these security problems by accident. There may be other security problems that are unique to SHACL.

SHACL-SPARQL also includes all the security problems of SPARQL. These include issues with FROM, FROM NAMED, or GRAPH and from similar-looking IRIs. The force-multipler aspect of SHACL-SPARQL is a force multiplier for many of these problems.

I have made an attempt to incorporate these suggestions. Indeed, having a reference to the SPARQL security section is something I should have done earlier.

61b12f4

If someone has further input on this, please (in the interest of time) make specific suggestions/patches. I am by no means a security expert either.

Note this section is informative, and SERVICE is explicitly not supported by SHACL-SPARQL.

We will consider an issue addressed unless we hear back from the submitter within 5 days of the last WG response comment. Last WG response comment on this issue was 6 days ago. With this, we will give extra 2 days to respond - before we will consider it to be addressed and submitter assumed to be satisfied.

I am not a security expert. All I have done is point out that SHACL appears to me to be a new powerful source of indirection attacks (sanitization) and a very efficient force multiplier. A security expert needs to be consulted to determine what should be said about the security issues with respect to SHACL.

Ill-formed shapes pose another security problem for SHACL, in my opinion, because the behaviour of SHACL implementations is undefined on ill-formed shapes and SHACL implementations are not required to signal the presence of ill-formed shapes. This means that the security problems built into SHACL can differ between different implementations of SHACL.

With today's update (decided in the WG meeting), SERVICE is now strictly prohibited and causes a failure, making this whole point redundant. I have deleted the paragraph from the security considerations.

I think this basically closes the ticket.