This paper describes security vulnerabilities when using SHACL for data validation in knowledge graphs (KGs) and enhance security awareness in SHACL and KG technologies. We employ a KG developed in a prior study in the social security domain to illustrate potential security issues. The vulnerability identified is SHACL's inability to distinguish user input from historical information in the KG, resulting in two potential exploits: validation bypass and data leakage. This study improves our understanding of security risks in SHACL and KG technologies, providing insights in this underexplored area in literature.
CEUR
ceur-ws.org Bypass in SHACL
Knowledge Graphs (KG) have emerged as versatile tools for representing and organizing complex
relationships between entities in various domains [
Despite the increase in popularity of KGs, there is limited research on related security issues.
In 2023, [
Motivated by this gap in the literature, this paper presents a case study to uncover security
vulnerabilities inherent to KG, focusing on SHACL utilization for data validation. SHACL is
often used as a simple data validation tool, either internally or for users to check the structure
of their documents. However, it is flexible enough to be considered in more complex contexts
where multiple stakeholders might interact with the KG. We employ a KG developed in a prior
study to validate social security declarations and illustrate potential security issues, showcasing
how this flexibility, while beneficial, also introduces risks.
Netherlands
The Shapes Constraint Language (SHACL) [
The validation process works as follows. For each shape, the focus nodes are selected based on their target among the nodes of the data graph. Then, these focus nodes are validated against the shape’s constraints. Depending on the validation results, the validation report indicates either that the data graph conforms when all nodes conform or that the graph does not conform if at least one node fails. In the latter case, the cause of the failing node is reported.
The types of constraints that can be expressed include value type constraints, cardinality constraints, value range constraints and logical operators, among others. These constraints, along with the general workings of the validation, form SHACL-CORE. In addition to SHACLCORE, SHACL-SPARQL extends its capabilities by enabling the creation of custom constraints using SPARQL queries. This component allows one to define more complex validation rules that may not be expressible using standard SHACL constraints alone.
In a prior study [
The constraints in the shapes graph were developed by translating constraints from an XSD schema and a well-documented glossary into SHACL. The kind of constraints that were expressed include simple constraints expressed with SHACL-CORE constraints such as datatype, value range, cardinality constraints, regular expressions, and complex constraints expressed with SHACL-SPARQL such as checksums, value part of an enumeration, and value unicity2. Listing 1 shows an example of a shape. This shape constrains a field to be a two-digit integer (lines 5), occur at most once (end of line 4), and be part of an enumeration (lines 6-11).
For the enumeration constraint, the user input must be complemented with additional data for the data graph, e.g., to check whether the provided values are valid w.r.t. rules documented elsewhere. We will refer to these data as public data as it concerns information that is publicly available in the glossary’s annexes. It describes the values allowed for some specific fields and their meaning. For instance, the position code in Listing 13 specifies the code for a person’s job: 1e.g., SHACL allows arithmetic computation, rules between diferent graphs and recursion 2Value unicity refers to ensuring that each value following a specific path in the KG does not occur more than once. 3More detailed examples are available at https://github.com/Ikeragnell/shaclExploits e.g., 58–barman, 61–hunter, 62–valet. As not all values are allowed and allowed values can vary over time, the public data contains an enumeration of the currently allowed values.
Similarly, some rules may require additional data to be included in the data graph, but that should be private. This information concerns user data relevant to social security, such as the number of working hours, amount of contributions, and amount of social rights. For example, Listing 2 states that one cannot be employed and have unemployment benefits simultaneously. ont:NaturalPersonShape a sh:NodeShape ; sh:targetClass ont:NaturalPerson ; sh:sparql [ sh:prefixes <> ; sh:select """SELECT $this WHERE { $this ont:INSS ?nbr; ont:R_90017_90012 ?workerRecord. ?workerRecord a ont:WorkerRecord. ?person ont:INSS ?nbr; ?person ont:R_90017_901234 ?unemploymentBenefit. ?unemploymentBenefit a ont:UnemploymentBenefit.}"""] .
In the previous section, we explained that the data graph included not only the transformed user input but also public and private data. Despite these components being distinguished before they are provided to the SHACL processor, it is critical to note that the SHACL processor treats the data graph as a whole. This aspect becomes a potential source of vulnerability, as SHACL cannot diferentiate user input from historical and trusted information.
This lack of distinction between user input and historical data potentially enables attackers to manipulate the validation process or extract sensitive information from the KG. The following sections present two exploits leveraging this vulnerability: validation bypass and data leakage.
While some access control mechanisms might help mitigate these risks, current access control
solutions for KGs are not yet mature [
Validation bypass occurs when a declaration that should be erroneous is reported as conforming to the shapes. This exploit capitalizes on SHACL’s inability to diferentiate between userprovided data and historical information within the KG. Essentially, attackers add additional triples that do not concern the declaration being evaluated4. This additional data pretends to be trusted data and masks the underlying inaccuracies in the provided data.
To illustrate this exploit, we will now describe how to bypass the shape in Listing 1, specifically the constraint of being part of an enumeration. For example, the value 31 is not part of the enumeration allowed for a position code. In normal circumstances, when a declaration containing this value is validated, the validation report generated states the node does not conform as it has a position code that does not exist.
An attacker can make value 31 valid by creating a position code with this value and adding it to the original declaration. Listing 3 shows the poisonous triples to be added. This kind of data should only be in the public data. However, as there is no distinction between the user input and the public data in the data graph, the SHACL validation process considered all asserted data as true.
In this case, the vulnerable constraint is a SPARQL constraint. SPARQL constraint component can utilize any paths to express complex rules even those beyond closed SHACL shapes. Thus, closing shape does not solve the problem. Moreover, this SPARQL constraint can be expressed with SHACL-CORE which shows that this exploit does not depend on SHACL-SPARQL. 1 <http://maliciousInput.be/PositionCode31> a an9:PositionCode ; an9:Code 31.
Data leakage occurs when sensitive information stored within the KG is exposed during validation. Users only interact with the SHACL processor and do not have direct access to private data. However, some rules require private data to be included in the data graph. Thus, an attacker could forge declarations and deduce sensitive data based on their validity.
To illustrate this exploit, we will now describe how the shape in Listing 2 can leak some sensitive information. Suppose that the data in Listing 4 is some private data, this data states that someone with the social security number 77101500172 is unemployed. We will refer to this person as Bob. In normal circumstances, no employer would declare Bob as an employee. 1 ont:UnempPers0 ont:INSS 77101500172. 2 ont:UnempPers0 ont:R_90017_901234 ont:UnempBen0. 3 ont:UnempBen0 a ont:UnemploymentBenefit. 1 ont:NatPers0 a ont:NaturalPerson. 2 ont:NatPers0 ont:INSS 77101500172. 3 ont:NatPers0 ont:R_90017_90012 ont:WorkRec0.
4 ont:WorkRec0 a ont:WorkerRecord.
4Note that poisoned data should not concern the declaration; otherwise, only fraud would occur instead of an exploit. For instance, if a declaration is erroneous due to a missing field, adding some fake data can make it pass the validation. This would be equivalent to fraudulently filling out a declaration.
An attacker can forge a declaration stating that he employs Bob. The relevant data from the forged declaration can be seen in Listing 4. The attacker can determine whether Bob is employed depending on the validation result. Bob is unemployed if the validation report states that the declaration does not conform (which is the case with this forged declaration). On the other hand, if the declaration conforms, then Bob is employed.
This paper marks a first step in understanding the vulnerabilities present in SHACL by describing exploits such as validation bypass and data leakage. We highlight the risks stemming from SHACL’s inability to diferentiate triples coming from diferent graphs. Moving forward, we will develop and implement efective strategies to address these security concerns. In the social security domain, where personal or sensitive data is used, convoluted approaches can be conceived in which validation reports are not communicated to users or where humans are kept in the loop in the validation process. Such solutions delegate all responsibilities to the applications built on the KG. Ideally, approaches are embedded into and part of the KG. Our goal is to address these declaratively using KG technologies. One potential venue is to use SHACL extensions5. This study is important to understand the vulnerabilities inherent in KGs. Through these endeavors, we aim to enhance the overall understanding of security issues of KG technologies and fortify them against potential exploits.