denial of service security problems with SERVICE

[pfps]

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.

[HolgerKnublauch]

I have added a sentence.

Please close this and other issues when satisfied.

[pfps]

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.

[swickr]

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?

[pfps]

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.

[pfps]

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.

[HolgerKnublauch]

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.

[irenetq]

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.

[pfps]

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.

[pfps]

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.

[HolgerKnublauch]

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.