From cdbd55017d988a6a6db7b18c3f86e09eb4d92f2b Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan Date: Sat, 21 Feb 2026 22:34:28 +0000 Subject: [PATCH 01/11] (Trivial) Remove trailing spaces in some docs --- .../customizing-library-models-for-go.rst | 6 +++--- .../customizing-library-models-for-python.rst | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst index c5b74ccd73ae..946ee1937b45 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst @@ -171,7 +171,7 @@ We need to add a tuple to the ``summaryModel``\(package, type, subtypes, name, s pack: codeql/go-all extensible: summaryModel data: - - ["slices", "", False, "Max", "", "", "Argument[0].ArrayElement", "ReturnValue", "value", "manual"] + - ["slices", "", False, "Max", "", "", "Argument[0].ArrayElement", "ReturnValue", "value", "manual"] Since we are adding flow through a method, we need to add tuples to the ``summaryModel`` extensible predicate. The first row defines flow from the first argument (``a`` in the example) to the return value (``max`` in the example). @@ -307,7 +307,7 @@ This example shows how the Go query pack models flow through a method for a simp host := u.Hostname() // There is taint flow from u to host. ... } - + We need to add a tuple to the ``summaryModel``\(package, type, subtypes, name, signature, ext, input, output, kind, provenance) extensible predicate by updating a data extension file: .. code-block:: yaml @@ -387,7 +387,7 @@ Note that packages hosted at ``gopkg.in`` use a slightly different syntax: the m To write models that only apply to ``github.com/couchbase/gocb/v2``, it is sufficient to include the major version suffix (``/v2``) in the package column. To write models that only apply to ``github.com/couchbase/gocb``, you may prefix the package column with ``fixed-version:``. For example, here are two models for a method that has changed name from v1 to v2. .. code-block:: yaml - + extensions: - addsTo: pack: codeql/go-all diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst index 30888f7b6092..69e6355e2096 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst @@ -9,7 +9,7 @@ Python analysis can be customized by adding library models in data extension fil A data extension for Python is a YAML file of the form: -.. code-block:: yaml +.. code-block:: yaml extensions: - addsTo: @@ -177,7 +177,7 @@ Note that this source is already known by the CodeQL Python analysis, but for th The **!** at the end of the type name indicates that we are looking for the class itself rather than instances of this class. - The second column is an access path that is evaluated from left to right, starting at the values that were identified by the first column. - + - **Call** selects calls to the class. That is, constructor calls. - **Argument[0,upload_to:]** selects the first positional argument, or the named argument named **upload_to**. Note that the colon at the end of the argument name indicates that we are looking for a named argument. - **Parameter[1]** selects the second parameter of the callback function, which is the parameter receiving the filename. From 8ab0a5b4dfaa120328220e7d05e485f989d6c460 Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan Date: Fri, 20 Mar 2026 14:59:38 +0000 Subject: [PATCH 02/11] (Formatting) Remove erroneous bullet point in ruby docs --- .../customizing-library-models-for-ruby.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst index 23a6bd419f5d..246f77db8434 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst @@ -182,7 +182,7 @@ We can model this using the following data extension: - Since we're adding flow through a method call, we add a tuple to the **summaryModel** extensible predicate. - The first column, **"URI!"**, begins the search for relevant calls at references to the **URI** class. -- The **!** suffix indicates that we are looking for the class itself, rather than instances of the class. + The **!** suffix indicates that we are looking for the class itself, rather than instances of the class. - The second column, **Method[decode_uri_component]**, is a path leading to the method calls we wish to model. In this case, we select references to the **decode_uri_component** method from the **URI** class. - The third column, **Argument[0]**, indicates the input of the flow. In this case, the first argument to the method call. From 7fab0b6693447868226c5be3ce184ee782e35edb Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan Date: Sat, 21 Feb 2026 23:12:21 +0000 Subject: [PATCH 03/11] List extensible predicates for barriers and barrier guards --- .../customizing-library-models-for-cpp.rst | 2 ++ .../customizing-library-models-for-csharp.rst | 2 ++ .../customizing-library-models-for-go.rst | 2 ++ .../customizing-library-models-for-java-and-kotlin.rst | 2 ++ .../customizing-library-models-for-javascript.rst | 2 ++ .../customizing-library-models-for-python.rst | 2 ++ .../customizing-library-models-for-ruby.rst | 2 ++ 7 files changed, 14 insertions(+) diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst index 29e8be5a4ae4..1fd14d9d6f87 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst @@ -58,6 +58,8 @@ The CodeQL library for CPP analysis exposes the following extensible predicates: - ``sourceModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model sources of potentially tainted data. The ``kind`` of the sources defined using this predicate determine which threat model they are associated with. Different threat models can be used to customize the sources used in an analysis. For more information, see ":ref:`Threat models `." - ``sinkModel(namespace, type, subtypes, name, signature, ext, input, kind, provenance)``. This is used to model sinks where tainted data may be used in a way that makes the code vulnerable. - ``summaryModel(namespace, type, subtypes, name, signature, ext, input, output, kind, provenance)``. This is used to model flow through elements. +- ``barrierModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model barriers, which are elements that stop the flow of taint. +- ``barrierGuardModel(namespace, type, boolean subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. The extensible predicates are populated using the models defined in data extension files. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst index 39b5ee30ee47..355a521e9109 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst @@ -58,6 +58,8 @@ The CodeQL library for C# analysis exposes the following extensible predicates: - ``sourceModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model sources of potentially tainted data. The ``kind`` of the sources defined using this predicate determine which threat model they are associated with. Different threat models can be used to customize the sources used in an analysis. For more information, see ":ref:`Threat models `." - ``sinkModel(namespace, type, subtypes, name, signature, ext, input, kind, provenance)``. This is used to model sinks where tainted data may be used in a way that makes the code vulnerable. - ``summaryModel(namespace, type, subtypes, name, signature, ext, input, output, kind, provenance)``. This is used to model flow through elements. +- ``barrierModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model barriers, which are elements that stop the flow of taint. +- ``barrierGuardModel(namespace, type, boolean subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. - ``neutralModel(namespace, type, name, signature, kind, provenance)``. This is similar to a summary model but used to model the flow of values that have only a minor impact on the dataflow analysis. Manual neutral models (those with a provenance such as ``manual`` or ``ai-manual``) can be used to override generated summary models (those with a provenance such as ``df-generated``), so that the summary model will be ignored. Other than that, neutral models have no effect. The extensible predicates are populated using the models defined in data extension files. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst index 946ee1937b45..8bee130ddc27 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst @@ -58,6 +58,8 @@ The CodeQL library for Go analysis exposes the following extensible predicates: - ``sourceModel(package, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model sources of potentially tainted data. The ``kind`` of the sources defined using this predicate determine which threat model they are associated with. Different threat models can be used to customize the sources used in an analysis. For more information, see ":ref:`Threat models `." - ``sinkModel(package, type, subtypes, name, signature, ext, input, kind, provenance)``. This is used to model sinks where tainted data may be used in a way that makes the code vulnerable. - ``summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)``. This is used to model flow through elements. +- ``barrierModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model barriers, which are elements that stop the flow of taint. +- ``barrierGuardModel(namespace, type, boolean subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. - ``neutralModel(package, type, name, signature, kind, provenance)``. This is similar to a summary model but used to model the flow of values that have only a minor impact on the dataflow analysis. Manual neutral models (those with a provenance such as ``manual`` or ``ai-manual``) can be used to override generated summary models (those with a provenance such as ``df-generated``), so that the summary model will be ignored. Other than that, neutral models have no effect. The extensible predicates are populated using the models defined in data extension files. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst index 7f0a41b3040e..dafd0213b872 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst @@ -63,6 +63,8 @@ The CodeQL library for Java and Kotlin analysis exposes the following extensible - ``sourceModel(package, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model sources of potentially tainted data. The ``kind`` of the sources defined using this predicate determine which threat model they are associated with. Different threat models can be used to customize the sources used in an analysis. For more information, see ":ref:`Threat models `." - ``sinkModel(package, type, subtypes, name, signature, ext, input, kind, provenance)``. This is used to model sinks where tainted data maybe used in a way that makes the code vulnerable. - ``summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)``. This is used to model flow through elements. +- ``barrierModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model barriers, which are elements that stop the flow of taint. +- ``barrierGuardModel(namespace, type, boolean subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. - ``neutralModel(package, type, name, signature, kind, provenance)``. This is similar to a summary model but used to model the flow of values that have only a minor impact on the dataflow analysis. Manual neutral models (those with a provenance such as ``manual`` or ``ai-manual``) override generated summary models (those with a provenance such as ``df-generated``) so that the summary will be ignored. Other than that, neutral models have a slight impact on the dataflow dispatch logic, which is out of scope for this documentation. The extensible predicates are populated using the models defined in data extension files. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst index b8f064c75747..7fea38b05c20 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst @@ -26,6 +26,8 @@ The CodeQL library for JavaScript exposes the following extensible predicates: - **sinkModel**\(type, path, kind) - **typeModel**\(type1, type2, path) - **summaryModel**\(type, path, input, output, kind) +- **barrierModel**\(type, path, kind) +- **barrierGuardModel**\(type, path, branch, kind) We'll explain how to use these using a few examples, and provide some reference material at the end of this article. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst index 69e6355e2096..9fdefa696b84 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst @@ -26,6 +26,8 @@ The CodeQL library for Python exposes the following extensible predicates: - **sinkModel**\(type, path, kind) - **typeModel**\(type1, type2, path) - **summaryModel**\(type, path, input, output, kind) +- **barrierModel**\(type, path, kind) +- **barrierGuardModel**\(type, path, branch, kind) We'll explain how to use these using a few examples, and provide some reference material at the end of this article. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst index 246f77db8434..227a178bf8e9 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst @@ -27,6 +27,8 @@ The CodeQL library for Ruby exposes the following extensible predicates: - **sinkModel**\(type, path, kind) - **typeModel**\(type1, type2, path) - **summaryModel**\(type, path, input, output, kind) +- **barrierModel**\(type, path, kind) +- **barrierGuardModel**\(type, path, branch, kind) We'll explain how to use these using a few examples, and provide some reference material at the end of this article. From d12eaff9ef71f6e544a9404d1eda28fd51d8ba82 Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan Date: Tue, 20 Jan 2026 14:40:44 +0000 Subject: [PATCH 04/11] Update docs for barriers and barrier guards --- .../customizing-library-models-for-cpp.rst | 82 ++++++++++++++++++ .../customizing-library-models-for-csharp.rst | 84 ++++++++++++++++++ .../customizing-library-models-for-go.rst | 82 ++++++++++++++++++ ...ing-library-models-for-java-and-kotlin.rst | 85 +++++++++++++++++++ ...tomizing-library-models-for-javascript.rst | 55 ++++++++++++ .../customizing-library-models-for-python.rst | 60 +++++++++++++ .../customizing-library-models-for-ruby.rst | 59 +++++++++++++ 7 files changed, 507 insertions(+) diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst index 1fd14d9d6f87..a96fd6ea352f 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst @@ -178,6 +178,88 @@ The remaining values are used to define the input and output specifications, the - The ninth value ``"taint"`` is the kind of the flow. ``taint`` means that taint is propagated through the call. - The tenth value ``"manual"`` is the provenance of the summary, which is used to identify the origin of the summary model. +Example: Taint barrier using the ``mysql_real_escape_string`` function +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This example shows how the CPP query pack models the ``mysql_real_escape_string`` function as a barrier for SQL injection. +This function escapes special characters in a string for use in an SQL statement, which prevents SQL injection attacks. + +.. code-block:: cpp + + char *query = "SELECT * FROM users WHERE name = '%s'"; + char *name = get_untrusted_input(); + char *escaped_name = new char[2 * strlen(name) + 1]; + mysql_real_escape_string(mysql, escaped_name, name, strlen(name)); // The escaped_name is safe for SQL injection. + sprintf(query_buffer, query, escaped_name); + +We need to add a tuple to the ``barrierModel``\(namespace, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/cpp-all + extensible: barrierModel + data: + - ["", "", False, "mysql_real_escape_string", "", "", "Argument[*1]", "sql-injection", "manual"] + +Since we are adding a barrier, we need to add a tuple to the ``barrierModel`` extensible predicate. +The first five values identify the callable (in this case a free function) to be modeled as a barrier. + +- The first value ``""`` is the namespace name. +- The second value ``""`` is the name of the type (class) that contains the method. Because we're modelling a free function, the type is left blank. +- The third value ``False`` is a flag that indicates whether or not the barrier also applies to all overrides of the method. For a free function, this should be ``False``. +- The fourth value ``"mysql_real_escape_string"`` is the function name. +- The fifth value is the function input type signature, which can be used to narrow down between functions that have the same name. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the output specification, the ``kind``, and the ``provenance`` (origin) of the barrier. + +- The seventh value ``"Argument[*1]"`` is the output specification, which means in this case that the barrier is the first indirection (or pointed-to value, ``*``) of the second argument (``Argument[1]``) passed to the function. +- The eighth value ``"sql-injection"`` is the kind of the barrier. The barrier kind is used to define the queries where the barrier is in scope. +- The ninth value ``"manual"`` is the provenance of the barrier, which is used to identify the origin of the barrier model. + +Example: Add a barrier guard +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This example shows how to model a barrier guard that stops the flow of taint when a conditional check is performed on data. +A barrier guard model is used when a function returns a boolean that indicates whether the data is safe to use. +Consider a function called ``is_safe`` which returns ``true`` when the data is considered safe. + +.. code-block:: cpp + + if (is_safe(user_input)) { // The check guards the use, so the input is safe. + mysql_query(user_input); // This is safe. + } + +We need to add a tuple to the ``barrierGuardModel``\(namespace, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/cpp-all + extensible: barrierGuardModel + data: + - ["", "", False, "is_safe", "", "", "Argument[*0]", "true", "sql-injection", "manual"] + +Since we are adding a barrier guard, we need to add a tuple to the ``barrierGuardModel`` extensible predicate. +The first five values identify the callable (in this case a free function) to be modeled as a barrier guard. + +- The first value ``""`` is the namespace name. +- The second value ``""`` is the name of the type (class) that contains the method. Because we're modelling a free function, the type is left blank. +- The third value ``False`` is a flag that indicates whether or not the barrier guard also applies to all overrides of the method. For a free function, this should be ``False``. +- The fourth value ``"is_safe"`` is the function name. +- The fifth value is the function input type signature, which can be used to narrow down between functions that have the same name. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the input specification, the ``accepting value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. + +- The seventh value ``Argument[*0]`` is the input specification (the value being validated). In this case, the first indirection (or pointed-to value, ``*``) of the first argument (``Argument[0]``) passed to the function. +- The eighth value ``true`` is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. +- The ninth value ``sql-injection`` is the kind of the barrier guard. The barrier guard kind is used to define the queries where the barrier guard is in scope. +- The tenth value ``manual`` is the provenance of the barrier guard, which is used to identify the origin of the barrier guard. + .. _threat-models-cpp: Threat models diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst index 355a521e9109..bec5d55e95c5 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst @@ -309,6 +309,90 @@ For the remaining values for both rows: That is, the first row specifies that values can flow from the elements of the qualifier enumerable into the first argument of the function provided to ``Select``. The second row specifies that values can flow from the return value of the function to the elements of the enumerable returned from ``Select``. +Example: Add a barrier for the ``RawUrl`` property +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This example shows how we can model a property as a barrier for a specific kind of query. +A barrier model is used to define that the flow of taint stops at the modeled element for the specified kind of query. +Here we model the getter of the ``RawUrl`` property of the ``HttpRequest`` class as a barrier for URL redirection queries. +The ``RawUrl`` property returns the raw URL of the current request, which is considered safe for URL redirects because it is the URL of the current request and cannot be manipulated by an attacker. + +.. code-block:: csharp + + public static void TaintBarrier(HttpRequest request) { + string url = request.RawUrl; // The return value of this property is considered safe for URL redirects. + Response.Redirect(url); // This is not a URL redirection vulnerability. + } + +We need to add a tuple to the ``barrierModel``\(namespace, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/csharp-all + extensible: barrierModel + data: + - ["System.Web", "HttpRequest", False, "get_RawUrl", "()", "", "ReturnValue", "url-redirection", "manual"] + +Since we are adding a barrier, we need to add a tuple to the ``barrierModel`` extensible predicate. +The first five values identify the callable (in this case the getter of a property) to be modeled as a barrier. + +- The first value ``System.Web`` is the namespace name. +- The second value ``HttpRequest`` is the class (type) name. +- The third value ``False`` is a flag that indicates whether or not the barrier also applies to all overrides of the method. +- The fourth value ``get_RawUrl`` is the method name. Getter and setter methods are named ``get_`` and ``set_`` respectively. +- The fifth value ``()`` is the method input type signature. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the barrier. + +- The seventh value ``ReturnValue`` is the access path to the return value of the property getter, which means that the return value is considered safe. +- The eighth value ``url-redirection`` is the kind of the barrier. The barrier kind is used to define the queries where the barrier is in scope. In this case - the URL redirection queries. +- The ninth value ``manual`` is the provenance of the barrier, which is used to identify the origin of the barrier. + +Example: Add a barrier guard for the ``IsAbsoluteUri`` property +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This example shows how we can model a property as a barrier guard for a specific kind of query. +A barrier guard model is used to stop the flow of taint when a conditional check is performed on data. +Here we model the getter of the ``IsAbsoluteUri`` property of the ``Uri`` class as a barrier guard for URL redirection queries. +When the ``IsAbsoluteUri`` property returns ``false``, the URL is relative and therefore safe for URL redirects because it cannot redirect to an external site controlled by an attacker. + +.. code-block:: csharp + + public static void TaintBarrierGuard(Uri uri) { + if (!uri.IsAbsoluteUri) { // The check guards the redirect, so the URL is safe. + Response.Redirect(uri.ToString()); // This is not a URL redirection vulnerability. + } + } + +We need to add a tuple to the ``barrierGuardModel``\(namespace, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/csharp-all + extensible: barrierGuardModel + data: + - ["System", "Uri", False, "get_IsAbsoluteUri", "()", "", "Argument[this]", "false", "url-redirection", "manual"] + +Since we are adding a barrier guard, we need to add a tuple to the ``barrierGuardModel`` extensible predicate. +The first five values identify the callable (in this case the getter of a property) to be modeled as a barrier guard. + +- The first value ``System`` is the namespace name. +- The second value ``Uri`` is the class (type) name. +- The third value ``False`` is a flag that indicates whether or not the barrier guard also applies to all overrides of the method. +- The fourth value ``get_IsAbsoluteUri`` is the method name. Getter and setter methods are named ``get_`` and ``set_`` respectively. +- The fifth value ``()`` is the method input type signature. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the ``access path``, the ``accepting value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. + +- The seventh value ``Argument[this]`` is the access path to the input whose flow is blocked. In this case, the qualifier of the property access (``uri`` in the example). +- The eighth value ``false`` is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. In this case, when ``IsAbsoluteUri`` is ``false``, the URL is relative and considered safe. +- The ninth value ``url-redirection`` is the kind of the barrier guard. The barrier guard kind is used to define the queries where the barrier guard is in scope. In this case - the URL redirection queries. +- The tenth value ``manual`` is the provenance of the barrier guard, which is used to identify the origin of the barrier guard. + Example: Add a ``neutral`` method ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This example shows how we can model a method as being neutral with respect to flow. We will also cover how to model a property by modeling the getter of the ``Now`` property of the ``DateTime`` class as neutral. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst index 8bee130ddc27..cfa87f2f7366 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst @@ -341,6 +341,88 @@ The remaining values are used to define the ``access path``, the ``kind``, and t - The ninth value ``taint`` is the kind of the flow. ``taint`` means that taint is propagated through the call. - The tenth value ``manual`` is the provenance of the summary, which is used to identify the origin of the summary. +Example: Add a barrier using the ``Htmlquote`` function +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This example shows how the Go query pack models a barrier that stops the flow of taint. +The ``Htmlquote`` function from the beego framework HTML-escapes a string, which prevents HTML injection attacks. + +.. code-block:: go + + func Render(w http.ResponseWriter, r *http.Request) { + name := r.FormValue("name") + safe := beego.Htmlquote(name) // The return value of this function is safe to use in HTML. + ... + } + +We need to add a tuple to the ``barrierModel``\(package, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/go-all + extensible: barrierModel + data: + - ["group:beego", "", True, "Htmlquote", "", "", "ReturnValue", "html-injection", "manual"] + +Since we are adding a barrier, we need to add a tuple to the ``barrierModel`` extensible predicate. +The first five values identify the function to be modeled as a barrier. + +- The first value ``group:beego`` is the package group name. The ``group:`` prefix indicates that this is a package group, which is used to match multiple package paths that refer to the same package. +- The second value ``""`` is left blank since the function is not a method of a type. +- The third value ``True`` is a flag that indicates whether or not the barrier also applies to subtypes. This has no effect for non-method functions. +- The fourth value ``Htmlquote`` is the function name. +- The fifth value ``""`` is the input type signature. For Go it should always be an empty string. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the barrier. + +- The seventh value ``ReturnValue`` is the access path to the output of the barrier, which means that the return value is considered sanitized. +- The eighth value ``html-injection`` is the kind of the barrier. The barrier kind must match the kind used in the query where the barrier should take effect. In this case, it matches the ``html-injection`` sink kind used by XSS queries. +- The ninth value ``manual`` is the provenance of the barrier, which is used to identify the origin of the barrier. + +Example: Add a barrier guard +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This example shows how to model a barrier guard that stops the flow of taint when a conditional check is performed on data. +A barrier guard model is used when a function returns a boolean that indicates whether the data is safe to use. +Consider a function called ``IsSafe`` which returns ``true`` when the data is considered safe for SQL injection. + +.. code-block:: go + + func Query(db *sql.DB, input string) { + if example.IsSafe(input) { // The check guards the query, so the input is safe. + db.Query(input) // This is not a SQL injection vulnerability. + } + } + +We need to add a tuple to the ``barrierGuardModel``\(package, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/go-all + extensible: barrierGuardModel + data: + - ["example.com/example", "", False, "IsSafe", "", "", "Argument[0]", "true", "sql-injection", "manual"] + +Since we are adding a barrier guard, we need to add a tuple to the ``barrierGuardModel`` extensible predicate. +The first five values identify the function to be modeled as a barrier guard. + +- The first value ``example.com/example`` is the package name. +- The second value ``""`` is left blank since the function is not a method of a type. +- The third value ``False`` is a flag that indicates whether or not the barrier guard also applies to subtypes. This has no effect for non-method functions. +- The fourth value ``IsSafe`` is the function name. +- The fifth value ``""`` is the input type signature. For Go it should always be an empty string. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the ``access path``, the ``accepting value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. + +- The seventh value ``Argument[0]`` is the access path to the input whose flow is blocked. In this case, the first argument to the function (``input`` in the example). +- The eighth value ``true`` is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. In this case, when ``IsSafe`` returns ``true``, the input is considered safe. +- The ninth value ``sql-injection`` is the kind of the barrier guard. The barrier guard kind is used to define the queries where the barrier guard is in scope. In this case - the SQL injection queries. +- The tenth value ``manual`` is the provenance of the barrier guard, which is used to identify the origin of the barrier guard. + Example: Accessing the ``Body`` field of an HTTP request ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This example shows how we can model a field read as a source of tainted data. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst index dafd0213b872..3cd67022a822 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst @@ -259,6 +259,91 @@ For the remaining values for both rows: That is, the first row specifies that values can flow from the elements of the qualifier stream into the first argument of the function provided to ``map``. The second row specifies that values can flow from the return value of the function to the elements of the stream returned from ``map``. +Example: Taint barrier in the ``java.io`` package +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This example shows how the Java query pack models the return value from the ``getName`` method as a barrier for path injection. +This is the ``getName`` method in the ``File`` class, which is located in the ``java.io`` package. The method returns only the final component of a path, which means that it protects against path injection vulnerabilities. + +.. code-block:: java + + public static void barrier(File file) { + String name = file.getName(); // The return value of this method is a barrier for path injection. + ... + } + +We need to add a tuple to the ``barrierModel``\(package, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/java-all + extensible: barrierModel + data: + - ["java.io", "File", True, "getName", "()", "", "ReturnValue", "path-injection", "manual"] + + +Since we are adding a new barrier, we need to add a tuple to the ``barrierModel`` extensible predicate. +The first five values identify the callable (in this case a method) to be modeled as a barrier. + +- The first value ``java.io`` is the package name. +- The second value ``File`` is the name of the class (type) that contains the method. +- The third value ``True`` is a flag that indicates whether or not the barrier also applies to all overrides of the method. +- The fourth value ``getName`` is the method name. +- The fifth value ``()`` is the method input type signature. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the barrier. + +- The seventh value ``ReturnValue`` is the access path to the return of the method, which means that it is the return value that should be considered a barrier. +- The eighth value ``path-injection`` is the kind of the barrier. The barrier kind is used to define the queries where the barrier is in scope. In this case - the path injection queries. +- The ninth value ``manual`` is the provenance of the barrier, which is used to identify the origin of the barrier. + +Example: Taint barrier guard in the ``java.net`` package +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This example shows how the Java query pack models the ``isAbsolute`` method as a barrier guard for request forgery. +This is the ``isAbsolute`` method in the ``URI`` class, which is located in the ``java.net`` package. +A barrier guard model is used to stop the flow of taint when a conditional check is performed on data. +When the ``isAbsolute`` method returns ``false``, the URI is relative and therefore safe for request forgery because it cannot redirect to an external server controlled by an attacker. + +.. code-block:: java + + public static void barrierguard(URI uri) throws IOException { + if (!uri.isAbsolute()) { // The check guards the request, so the URI is safe. + URL url = uri.toURL(); + url.openConnection(); // This is not a request forgery vulnerability. + } + } + +We need to add a tuple to the ``barrierGuardModel``\(package, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/java-all + extensible: barrierGuardModel + data: + - ["java.net", "URI", True, "isAbsolute", "()", "", "Argument[this]", "false", "request-forgery", "manual"] + + +Since we are adding a barrier guard, we need to add a tuple to the ``barrierGuardModel`` extensible predicate. +The first five values identify the callable (in this case a method) to be modeled as a barrier guard. + +- The first value ``java.net`` is the package name. +- The second value ``URI`` is the name of the class (type) that contains the method. +- The third value ``True`` is a flag that indicates whether or not the barrier guard also applies to all overrides of the method. +- The fourth value ``isAbsolute`` is the method name. +- The fifth value ``()`` is the method input type signature. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the ``access path``, the ``accepting value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. + +- The seventh value ``Argument[this]`` is the access path to the input whose flow is blocked. In this case, the qualifier of the method call (``uri`` in the example). +- The eighth value ``false`` is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. In this case, when ``isAbsolute`` is ``false``, the URI is relative and considered safe. +- The ninth value ``request-forgery`` is the kind of the barrier guard. The barrier guard kind is used to define the queries where the barrier guard is in scope. In this case - the request forgery queries. +- The tenth value ``manual`` is the provenance of the barrier guard, which is used to identify the origin of the barrier guard. + Example: Add a ``neutral`` method ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This example shows how the Java query pack models the ``now`` method as being neutral with respect to flow. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst index 7fea38b05c20..95119d117456 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst @@ -393,6 +393,61 @@ This can be achieved with the following data extension: - **Member[data]** selects accesses to the **data** property of the **req** object. - Finally, the kind **remote** indicates that this is considered a source of remote flow. +Example: Taint barrier using the 'encodeURIComponent' function +-------------------------------------------------------------- + +In this example, we'll show how to add the return value of **encodeURIComponent** as a barrier for XSS. + +.. code-block:: js + + let escaped = encodeURIComponent(input); // The return value of this method is safe for XSS. + document.body.innerHTML = escaped; + +We can model this using the following data extension: + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/javascript-all + extensible: barrierModel + data: + - ["global", "Member[encodeURIComponent].ReturnValue", "html-injection"] + +- Since we are adding a barrier, we need to add a tuple to the **barrierModel** extensible predicate. +- The first column, **"global"**, begins the search for relevant calls at references to the global object. +- The second column, **Member[encodeURIComponent].ReturnValue**, selects the return value of the **encodeURIComponent** function. +- The third column, **"html-injection"**, is the kind of the barrier. + +Example: Add a barrier guard +---------------------------- + +This example shows how to model a barrier guard that stops the flow of taint when a conditional check is performed on data. +Consider a function called `isValid` which returns `true` when the data is considered safe. + +.. code-block:: js + + if (isValid(userInput)) { // The check guards the use, so the input is safe. + db.query(userInput); // This is safe. + } + +We can model this using the following data extension: + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/javascript-all + extensible: barrierGuardModel + data: + - ["my-package", "Member[isValid].Argument[0]", "true", "sql-injection"] + +- Since we are adding a barrier guard, we need to add a tuple to the **barrierGuardModel** extensible predicate. +- The first column, **"my-package"**, begins the search at imports of the hypothetical NPM package **my-package**. +- The second column, **Member[isValid].Argument[0]**, selects the first argument of the `isValid` function. This is the value being validated. +- The third column, **"true"**, is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. +- The fourth column, **"sql-injection"**, is the kind of the barrier guard. + Reference material ------------------ diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst index 9fdefa696b84..54b1023c7d09 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst @@ -281,6 +281,66 @@ We might also provide a summary stating that the elements of the input list are The tracking of list elements is imprecise in that the analysis does not know where in the list the tracked value is found. So this summary simply states that if the value is found somewhere in the input list, it will also be found somewhere in the output list, unchanged. +Example: Taint barrier using the 'escape' function +-------------------------------------------------- + +In this example, we'll show how to add the return value of **html.escape** as a barrier for XSS. + +.. code-block:: python + + import html + escaped = html.escape(unknown) # The return value of this function is safe for XSS. + +We can model this using the following data extension: + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/python-all + extensible: barrierModel + data: + - ["html", "Member[escape].ReturnValue", "html-injection"] + +- Since we are adding a barrier, we need to add a tuple to the **barrierModel** extensible predicate. +- The first column, **"html"**, begins the search at places where the **html** module is imported. +- The second column, **Member[escape].ReturnValue**, selects the return value of the **escape** function from the **html** module. +- The third column, **"html-injection"**, is the kind of the barrier. + +Example: Add a barrier guard +---------------------------- + +This example shows how to model a barrier guard that stops the flow of taint when a conditional check is performed on data. +A barrier guard model is used when a function returns a boolean that indicates whether the data is safe to use. +Consider the function ``url_has_allowed_host_and_scheme`` from the ``django.utils.http`` package which returns ``true`` when the URL is in a safe domain. + +.. code-block:: python + + if url_has_allowed_host_and_scheme(url, allowed_hosts=...): # The check guards the use of 'url', so it is safe. + redirect(url) # This is safe. + +We need to add a tuple to the ``barrierGuardModel``\(type, path, branch, kind, madId) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/python-all + extensible: barrierGuardModel + data: + - [ + "django", + "Member[utils].Member[http].Member[url_has_allowed_host_and_scheme].Argument[0,url:]", + "true", + "url-redirection", + ] + +- Since we are adding a barrier guard, we need to add a tuple to the **barrierGuardModel** extensible predicate. +- The first column, **"django"**, begins the search at places where the **django** package is imported. +- The second column, **Member[utils].Member[http].Member[url_has_allowed_host_and_scheme].Argument[0,url:]**, selects the first argument (or the keyword argument ``url``) of the ``url_has_allowed_host_and_scheme`` function in the ``django.utils.http`` module. This is the value being validated. +- The third column, **"true"**, is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. +- The fourth column, **"url-redirection"**, is the kind of the barrier guard. The barrier guard kind is used to define the queries where the barrier guard is in scope. + Reference material ------------------ diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst index 227a178bf8e9..37636960fe85 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst @@ -232,6 +232,65 @@ We can model this using the following data extension: - The last column, **taint**, indicates the kind of flow to add. +Example: Taint barrier using the 'escape' method +------------------------------------------------ + +In this example, we'll show how to add the return value of **Mysql2::Client#escape** as a barrier for SQL injection. + +.. code-block:: ruby + + client = Mysql2::Client.new + escaped = client.escape(input) # The return value of this method is safe for SQL injection. + client.query("SELECT * FROM users WHERE name = '#{escaped}'") + +We can model this using the following data extension: + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/ruby-all + extensible: barrierModel + data: + - ["Mysql2::Client!", "Method[escape].ReturnValue", "sql-injection"] + +- Since we are adding a barrier, we need to add a tuple to the **barrierModel** extensible predicate. +- The first column, **"Mysql2::Client!"**, begins the search for relevant calls at references to the **Mysql2::Client** class. + The **!** suffix indicates that we want to search for references to the class itself, rather than instances of the class. +- The second column, **"Method[escape].ReturnValue"**, selects the return value of the **escape** method. +- The third column, **"sql-injection"**, is the kind of the barrier. + +Example: Add a barrier guard +---------------------------- + +This example shows how to model a barrier guard that stops the flow of taint when a conditional check is performed on data. +Consider a validation method ``Validator.is_safe`` which returns ``true`` when the data is considered safe. + +.. code-block:: ruby + + if Validator.is_safe(user_input) + # The check guards the use, so the input is safe. + client.query("SELECT * FROM users WHERE name = '#{user_input}'") + end + +We can model this using the following data extension: + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/ruby-all + extensible: barrierGuardModel + data: + - ["Validator!", "Method[is_safe].Argument[0]", "true", "sql-injection"] + +- Since we are adding a barrier guard, we need to add a tuple to the **barrierGuardModel** extensible predicate. +- The first column, **"Validator!"**, begins the search at references to the **Validator** class. + The **!** suffix indicates that we want to search for references to the class itself, rather than instances of the class. +- The second column, **"Method[is_safe].Argument[0]"**, selects the first argument of the **is_safe** method. This is the value being validated. +- The third column, **"true"**, is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. +- The fourth column, **"sql-injection"**, is the kind of the barrier guard. + Reference material ------------------ From 0eb69f3afeb20c81e3388d063c6231ecd4d9cb31 Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan Date: Fri, 20 Mar 2026 15:22:29 +0000 Subject: [PATCH 05/11] Add change notes --- .../lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ .../lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ go/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ .../lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ .../lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ .../lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ .../lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ .../lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ 8 files changed, 32 insertions(+) create mode 100644 cpp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md create mode 100644 csharp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md create mode 100644 go/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md create mode 100644 java/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md create mode 100644 javascript/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md create mode 100644 python/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md create mode 100644 ruby/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md create mode 100644 rust/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md diff --git a/cpp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/cpp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..281008e46971 --- /dev/null +++ b/cpp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for C and C++ `__. diff --git a/csharp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/csharp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..4d5cc0c0d0d4 --- /dev/null +++ b/csharp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for C# `__. diff --git a/go/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/go/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..1e86b59d5b57 --- /dev/null +++ b/go/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for Go `__. diff --git a/java/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/java/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..d4ae1f8711d4 --- /dev/null +++ b/java/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for Java and Kotlin `__. diff --git a/javascript/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/javascript/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..e8bacba89b14 --- /dev/null +++ b/javascript/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for JavaScript `__. diff --git a/python/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/python/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..b33a89ba7765 --- /dev/null +++ b/python/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for Python `__. diff --git a/ruby/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/ruby/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..fecf79a0de78 --- /dev/null +++ b/ruby/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for Ruby `__. diff --git a/rust/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/rust/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..5e97a1533a9e --- /dev/null +++ b/rust/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions. From 77c1c4d7a1301537cc65e7e1e95c3fc0b0e4f6e6 Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan <62447351+owen-mc@users.noreply.github.com> Date: Tue, 24 Mar 2026 11:02:07 +0000 Subject: [PATCH 06/11] Remove incorrect parameter of extensible predicate Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- .../customizing-library-models-for-python.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst index 54b1023c7d09..942bb2d1220d 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst @@ -319,7 +319,7 @@ Consider the function ``url_has_allowed_host_and_scheme`` from the ``django.util if url_has_allowed_host_and_scheme(url, allowed_hosts=...): # The check guards the use of 'url', so it is safe. redirect(url) # This is safe. -We need to add a tuple to the ``barrierGuardModel``\(type, path, branch, kind, madId) extensible predicate by updating a data extension file. +We need to add a tuple ``(type, path, branch, kind)`` to the ``barrierGuardModel`` extensible predicate by updating a data extension file (the extension ID is implicit and auto-assigned). .. code-block:: yaml From 8396d2f23f134c416f689049fd9a4ebf2bf79afc Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan <62447351+owen-mc@users.noreply.github.com> Date: Tue, 24 Mar 2026 11:03:53 +0000 Subject: [PATCH 07/11] Correct extensible predicate signatures in docs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- .../customizing-library-models-for-cpp.rst | 2 +- .../customizing-library-models-for-csharp.rst | 2 +- .../customizing-library-models-for-go.rst | 4 ++-- .../customizing-library-models-for-java-and-kotlin.rst | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst index a96fd6ea352f..a567a4939562 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst @@ -59,7 +59,7 @@ The CodeQL library for CPP analysis exposes the following extensible predicates: - ``sinkModel(namespace, type, subtypes, name, signature, ext, input, kind, provenance)``. This is used to model sinks where tainted data may be used in a way that makes the code vulnerable. - ``summaryModel(namespace, type, subtypes, name, signature, ext, input, output, kind, provenance)``. This is used to model flow through elements. - ``barrierModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model barriers, which are elements that stop the flow of taint. -- ``barrierGuardModel(namespace, type, boolean subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. +- ``barrierGuardModel(namespace, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. The extensible predicates are populated using the models defined in data extension files. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst index bec5d55e95c5..e8a029a595c9 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst @@ -59,7 +59,7 @@ The CodeQL library for C# analysis exposes the following extensible predicates: - ``sinkModel(namespace, type, subtypes, name, signature, ext, input, kind, provenance)``. This is used to model sinks where tainted data may be used in a way that makes the code vulnerable. - ``summaryModel(namespace, type, subtypes, name, signature, ext, input, output, kind, provenance)``. This is used to model flow through elements. - ``barrierModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model barriers, which are elements that stop the flow of taint. -- ``barrierGuardModel(namespace, type, boolean subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. +- ``barrierGuardModel(namespace, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. - ``neutralModel(namespace, type, name, signature, kind, provenance)``. This is similar to a summary model but used to model the flow of values that have only a minor impact on the dataflow analysis. Manual neutral models (those with a provenance such as ``manual`` or ``ai-manual``) can be used to override generated summary models (those with a provenance such as ``df-generated``), so that the summary model will be ignored. Other than that, neutral models have no effect. The extensible predicates are populated using the models defined in data extension files. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst index cfa87f2f7366..b26f0ad7e391 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst @@ -58,8 +58,8 @@ The CodeQL library for Go analysis exposes the following extensible predicates: - ``sourceModel(package, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model sources of potentially tainted data. The ``kind`` of the sources defined using this predicate determine which threat model they are associated with. Different threat models can be used to customize the sources used in an analysis. For more information, see ":ref:`Threat models `." - ``sinkModel(package, type, subtypes, name, signature, ext, input, kind, provenance)``. This is used to model sinks where tainted data may be used in a way that makes the code vulnerable. - ``summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)``. This is used to model flow through elements. -- ``barrierModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model barriers, which are elements that stop the flow of taint. -- ``barrierGuardModel(namespace, type, boolean subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. +- ``barrierModel(package, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model barriers, which are elements that stop the flow of taint. +- ``barrierGuardModel(package, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. - ``neutralModel(package, type, name, signature, kind, provenance)``. This is similar to a summary model but used to model the flow of values that have only a minor impact on the dataflow analysis. Manual neutral models (those with a provenance such as ``manual`` or ``ai-manual``) can be used to override generated summary models (those with a provenance such as ``df-generated``), so that the summary model will be ignored. Other than that, neutral models have no effect. The extensible predicates are populated using the models defined in data extension files. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst index 3cd67022a822..606cdf5c8df0 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst @@ -64,7 +64,7 @@ The CodeQL library for Java and Kotlin analysis exposes the following extensible - ``sinkModel(package, type, subtypes, name, signature, ext, input, kind, provenance)``. This is used to model sinks where tainted data maybe used in a way that makes the code vulnerable. - ``summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)``. This is used to model flow through elements. - ``barrierModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model barriers, which are elements that stop the flow of taint. -- ``barrierGuardModel(namespace, type, boolean subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. +- ``barrierGuardModel(namespace, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. - ``neutralModel(package, type, name, signature, kind, provenance)``. This is similar to a summary model but used to model the flow of values that have only a minor impact on the dataflow analysis. Manual neutral models (those with a provenance such as ``manual`` or ``ai-manual``) override generated summary models (those with a provenance such as ``df-generated``) so that the summary will be ignored. Other than that, neutral models have a slight impact on the dataflow dispatch logic, which is out of scope for this documentation. The extensible predicates are populated using the models defined in data extension files. From 052b41a04f826a49429d54ec000fa02528718c96 Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan Date: Tue, 24 Mar 2026 11:00:44 +0000 Subject: [PATCH 08/11] Fix link formatting in change notes --- cpp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md | 2 +- .../ql/lib/change-notes/2026-03-20-data-extensions-barriers.md | 2 +- go/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md | 2 +- java/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md | 2 +- .../ql/lib/change-notes/2026-03-20-data-extensions-barriers.md | 2 +- .../ql/lib/change-notes/2026-03-20-data-extensions-barriers.md | 2 +- ruby/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/cpp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/cpp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md index 281008e46971..30f0092a4e95 100644 --- a/cpp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md +++ b/cpp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -1,4 +1,4 @@ --- category: feature --- -* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for C and C++ `__. +* Data flow barriers and barrier guards can now be added using data extensions. For more information see [Customizing library models for C and C++](https://codeql.github.com/docs/codeql-language-guides/customizing-library-models-for-cpp/). diff --git a/csharp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/csharp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md index 4d5cc0c0d0d4..6408acc7dae8 100644 --- a/csharp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md +++ b/csharp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -1,4 +1,4 @@ --- category: feature --- -* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for C# `__. +* Data flow barriers and barrier guards can now be added using data extensions. For more information see [Customizing library models for C#](https://codeql.github.com/docs/codeql-language-guides/customizing-library-models-for-csharp/). diff --git a/go/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/go/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md index 1e86b59d5b57..ee1b51de861f 100644 --- a/go/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md +++ b/go/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -1,4 +1,4 @@ --- category: feature --- -* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for Go `__. +* Data flow barriers and barrier guards can now be added using data extensions. For more information see [Customizing library models for Go](https://codeql.github.com/docs/codeql-language-guides/customizing-library-models-for-go/). diff --git a/java/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/java/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md index d4ae1f8711d4..f8bcbb1fcb2a 100644 --- a/java/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md +++ b/java/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -1,4 +1,4 @@ --- category: feature --- -* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for Java and Kotlin `__. +* Data flow barriers and barrier guards can now be added using data extensions. For more information see [Customizing library models for Java and Kotlin](https://codeql.github.com/docs/codeql-language-guides/customizing-library-models-for-java-and-kotlin/). diff --git a/javascript/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/javascript/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md index e8bacba89b14..d849f4c0c698 100644 --- a/javascript/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md +++ b/javascript/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -1,4 +1,4 @@ --- category: feature --- -* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for JavaScript `__. +* Data flow barriers and barrier guards can now be added using data extensions. For more information see [Customizing library models for JavaScript](https://codeql.github.com/docs/codeql-language-guides/customizing-library-models-for-javascript/). diff --git a/python/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/python/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md index b33a89ba7765..522801a0e46d 100644 --- a/python/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md +++ b/python/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -1,4 +1,4 @@ --- category: feature --- -* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for Python `__. +* Data flow barriers and barrier guards can now be added using data extensions. For more information see [Customizing library models for Python](https://codeql.github.com/docs/codeql-language-guides/customizing-library-models-for-python/). diff --git a/ruby/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/ruby/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md index fecf79a0de78..da53d584e11d 100644 --- a/ruby/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md +++ b/ruby/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -1,4 +1,4 @@ --- category: feature --- -* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for Ruby `__. +* Data flow barriers and barrier guards can now be added using data extensions. For more information see [Customizing library models for Ruby](https://codeql.github.com/docs/codeql-language-guides/customizing-library-models-for-ruby/). From f38461148f9a19e79f66578c49d5096aff8f9d02 Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan Date: Tue, 31 Mar 2026 12:27:45 +0100 Subject: [PATCH 09/11] "modelling" -> "modeling" in docs --- .../customizing-library-models-for-cpp.rst | 10 +++++----- docs/ql-libraries/dataflow/dataflow.md | 2 +- ruby/ql/docs/flow_summaries.md | 4 ++-- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst index a567a4939562..e7aaf9b03e9b 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst @@ -92,7 +92,7 @@ Since we are adding a new source, we need to add a tuple to the ``sourceModel`` The first five values identify the callable (in this case a free function) to be modeled as a source. - The first value ``"boost::asio"`` is the namespace name. -- The second value ``""`` is the name of the type (class) that contains the method. Because we're modelling a free function, the type is left blank. +- The second value ``""`` is the name of the type (class) that contains the method. Because we're modeling a free function, the type is left blank. - The third value ``False`` is a flag that indicates whether or not the sink also applies to all overrides of the method. For a free function, this should be ``False``. - The fourth value ``"read_until"`` is the function name. - The fifth value is the function input type signature, which can be used to narrow down between functions that have the same name. In this case, we want the model to include all functions in ``boost::asio`` called ``read_until``. @@ -128,7 +128,7 @@ Since we want to add a new sink, we need to add a tuple to the ``sinkModel`` ext The first five values identify the callable (in this case a free function) to be modeled as a sink. - The first value ``"boost::asio"`` is the namespace name. -- The second value ``""`` is the name of the type (class) that contains the method. Because we're modelling a free function, the type is left blank. +- The second value ``""`` is the name of the type (class) that contains the method. Because we're modeling a free function, the type is left blank. - The third value ``False`` is a flag that indicates whether or not the sink also applies to all overrides of the method. For a free function, this should be ``False``. - The fourth value ``"write"`` is the function name. - The fifth value is the function input type signature, which can be used to narrow down between functions that have the same name. In this case, we want the model to include all functions in ``boost::asio`` called ``write``. @@ -165,7 +165,7 @@ Since we are adding flow through a function, we need to add tuples to the ``summ The first five values identify the callable (in this case free function) to be modeled as a summary. - The first value ``"boost::asio"`` is the namespace name. -- The second value ``""`` is the name of the type (class) that contains the method. Because we're modelling a free function, the type is left blank. +- The second value ``""`` is the name of the type (class) that contains the method. Because we're modeling a free function, the type is left blank. - The third value ``False`` is a flag that indicates whether or not the sink also applies to all overrides of the method. For a free function, this should be ``False``. - The fourth value ``"buffer"`` is the function name. - The fifth value is the function input type signature, which can be used to narrow down between functions that have the same name. In this case, we want the model to include all functions in ``boost::asio`` called ``buffer``. @@ -207,7 +207,7 @@ Since we are adding a barrier, we need to add a tuple to the ``barrierModel`` ex The first five values identify the callable (in this case a free function) to be modeled as a barrier. - The first value ``""`` is the namespace name. -- The second value ``""`` is the name of the type (class) that contains the method. Because we're modelling a free function, the type is left blank. +- The second value ``""`` is the name of the type (class) that contains the method. Because we're modeling a free function, the type is left blank. - The third value ``False`` is a flag that indicates whether or not the barrier also applies to all overrides of the method. For a free function, this should be ``False``. - The fourth value ``"mysql_real_escape_string"`` is the function name. - The fifth value is the function input type signature, which can be used to narrow down between functions that have the same name. @@ -247,7 +247,7 @@ Since we are adding a barrier guard, we need to add a tuple to the ``barrierGuar The first five values identify the callable (in this case a free function) to be modeled as a barrier guard. - The first value ``""`` is the namespace name. -- The second value ``""`` is the name of the type (class) that contains the method. Because we're modelling a free function, the type is left blank. +- The second value ``""`` is the name of the type (class) that contains the method. Because we're modeling a free function, the type is left blank. - The third value ``False`` is a flag that indicates whether or not the barrier guard also applies to all overrides of the method. For a free function, this should be ``False``. - The fourth value ``"is_safe"`` is the function name. - The fifth value is the function input type signature, which can be used to narrow down between functions that have the same name. diff --git a/docs/ql-libraries/dataflow/dataflow.md b/docs/ql-libraries/dataflow/dataflow.md index ff7c71abfaec..7227f7cfd0fd 100644 --- a/docs/ql-libraries/dataflow/dataflow.md +++ b/docs/ql-libraries/dataflow/dataflow.md @@ -279,7 +279,7 @@ Content ContentSet::getAReadContent(); which means that a `storeStep(n1, cs, n2)` will be interpreted as storing into _any_ of `cs.getAStoreContent()`, and dually that a `readStep(n1, cs, n2)` will be interpreted as reading from _any_ of `cs.getAReadContent()`. In most cases, there -will be a simple bijection between `ContentSet` and `Content`, but when modelling +will be a simple bijection between `ContentSet` and `Content`, but when modeling for example flow through arrays it can be more involved (see [Example 4](#example-4)). It generally makes sense for stores to target `PostUpdateNode`s, but this is not a strict diff --git a/ruby/ql/docs/flow_summaries.md b/ruby/ql/docs/flow_summaries.md index bb5fe5d71787..e588bdcaf26b 100644 --- a/ruby/ql/docs/flow_summaries.md +++ b/ruby/ql/docs/flow_summaries.md @@ -39,7 +39,7 @@ If `preservesValue = true` then value flow is propagated. If it is `false` then only taint flow is propagated. Any call to `chomp` in the database will be translated, in the dataflow graph, -to a call to this fake definition. +to a call to this fake definition. `input` and `output` define the "from" and "to" locations in the flow summary. They use a custom string-based syntax which is similar to that used in `path` @@ -232,7 +232,7 @@ preceding access path. It takes the same specifiers as `WithElement` and `Element`. It is only valid in an input path. This component has the effect of excluding the relevant elements when copying -from input to output. It is useful for modelling methods that remove elements +from input to output. It is useful for modeling methods that remove elements from a collection. For example to model a method that removes the first element from the receiver, we can do so like this: From ae66354b36807b3bad9dfae8091d0cc8cce4fcc8 Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan Date: Tue, 31 Mar 2026 14:59:59 +0100 Subject: [PATCH 10/11] Include parameters when quoting extensible predicate name --- .../customizing-library-models-for-cpp.rst | 10 +++++----- .../customizing-library-models-for-csharp.rst | 14 +++++++------- .../customizing-library-models-for-go.rst | 16 ++++++++-------- ...mizing-library-models-for-java-and-kotlin.rst | 14 +++++++------- 4 files changed, 27 insertions(+), 27 deletions(-) diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst index e7aaf9b03e9b..1a8e807c0694 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst @@ -77,7 +77,7 @@ This example shows how the CPP query pack models the return value from the ``rea boost::asio::read_until(socket, recv_buffer, '\0', error); -We need to add a tuple to the ``sourceModel``\(namespace, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``sourceModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml @@ -113,7 +113,7 @@ This example shows how the CPP query pack models the second argument of the ``bo boost::asio::write(socket, send_buffer, error); -We need to add a tuple to the ``sinkModel``\(namespace, type, subtypes, name, signature, ext, input, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``sinkModel(namespace, type, subtypes, name, signature, ext, input, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml @@ -149,7 +149,7 @@ This example shows how the CPP query pack models flow through a function for a s boost::asio::write(socket, boost::asio::buffer(send_str), error); -We need to add tuples to the ``summaryModel``\(namespace, type, subtypes, name, signature, ext, input, output, kind, provenance) extensible predicate by updating a data extension file: +We need to add tuples to the ``summaryModel(namespace, type, subtypes, name, signature, ext, input, output, kind, provenance)`` extensible predicate by updating a data extension file: .. code-block:: yaml @@ -192,7 +192,7 @@ This function escapes special characters in a string for use in an SQL statement mysql_real_escape_string(mysql, escaped_name, name, strlen(name)); // The escaped_name is safe for SQL injection. sprintf(query_buffer, query, escaped_name); -We need to add a tuple to the ``barrierModel``\(namespace, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``barrierModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml @@ -232,7 +232,7 @@ Consider a function called ``is_safe`` which returns ``true`` when the data is c mysql_query(user_input); // This is safe. } -We need to add a tuple to the ``barrierGuardModel``\(namespace, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``barrierGuardModel(namespace, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst index e8a029a595c9..da267da9f2e5 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst @@ -121,7 +121,7 @@ This is the ``GetStream`` method in the ``TcpClient`` class, which is located in ... } -We need to add a tuple to the ``sourceModel``\(namespace, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``sourceModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml @@ -161,7 +161,7 @@ This pattern covers many of the cases where we need to summarize flow through a ... } -We need to add tuples to the ``summaryModel``\(namespace, type, subtypes, name, signature, ext, input, output, kind, provenance) extensible predicate by updating a data extension file: +We need to add tuples to the ``summaryModel(namespace, type, subtypes, name, signature, ext, input, output, kind, provenance)`` extensible predicate by updating a data extension file: .. code-block:: yaml @@ -218,7 +218,7 @@ This example shows how the C# query pack models flow through a method for a simp ... } -We need to add a tuple to the ``summaryModel``\(namespace, type, subtypes, name, signature, ext, input, output, kind, provenance) extensible predicate by updating a data extension file: +We need to add a tuple to the ``summaryModel(namespace, type, subtypes, name, signature, ext, input, output, kind, provenance)`` extensible predicate by updating a data extension file: .. code-block:: yaml @@ -262,7 +262,7 @@ Here we model flow through higher order methods and collection types, as well as ... } -We need to add tuples to the ``summaryModel``\(namespace, type, subtypes, name, signature, ext, input, output, kind, provenance) extensible predicate by updating a data extension file: +We need to add tuples to the ``summaryModel(namespace, type, subtypes, name, signature, ext, input, output, kind, provenance)`` extensible predicate by updating a data extension file: .. code-block:: yaml @@ -323,7 +323,7 @@ The ``RawUrl`` property returns the raw URL of the current request, which is con Response.Redirect(url); // This is not a URL redirection vulnerability. } -We need to add a tuple to the ``barrierModel``\(namespace, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``barrierModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml @@ -365,7 +365,7 @@ When the ``IsAbsoluteUri`` property returns ``false``, the URL is relative and t } } -We need to add a tuple to the ``barrierGuardModel``\(namespace, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``barrierGuardModel(namespace, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml @@ -405,7 +405,7 @@ A neutral model is used to define that there is no flow through a method. ... } -We need to add a tuple to the ``neutralModel``\(namespace, type, name, signature, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``neutralModel(namespace, type, name, signature, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst index b26f0ad7e391..1d8abed14e20 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst @@ -122,7 +122,7 @@ This is the ``FormValue`` method of the ``Request`` type which is located in the } -We need to add a tuple to the ``sourceModel``\(package, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``sourceModel(package, type, subtypes, name, signature, ext, output, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml @@ -164,7 +164,7 @@ This pattern covers many of the cases where we need to summarize flow through a ... } -We need to add a tuple to the ``summaryModel``\(package, type, subtypes, name, signature, ext, input, output, kind, provenance) extensible predicate by updating a data extension file: +We need to add a tuple to the ``summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)`` extensible predicate by updating a data extension file: .. code-block:: yaml @@ -209,7 +209,7 @@ This pattern covers many of the cases where we need to summarize flow through a ... } -We need to add a tuple to the ``summaryModel``\(package, type, subtypes, name, signature, ext, input, output, kind, provenance) extensible predicate by updating a data extension file: +We need to add a tuple to the ``summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)`` extensible predicate by updating a data extension file: .. code-block:: yaml @@ -253,7 +253,7 @@ This pattern covers many of the cases where we need to summarize flow through a ... } -We need to add tuples to the ``summaryModel``\(package, type, subtypes, name, signature, ext, input, output, kind, provenance) extensible predicate by updating a data extension file: +We need to add tuples to the ``summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)`` extensible predicate by updating a data extension file: .. code-block:: yaml @@ -310,7 +310,7 @@ This example shows how the Go query pack models flow through a method for a simp ... } -We need to add a tuple to the ``summaryModel``\(package, type, subtypes, name, signature, ext, input, output, kind, provenance) extensible predicate by updating a data extension file: +We need to add a tuple to the ``summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)`` extensible predicate by updating a data extension file: .. code-block:: yaml @@ -354,7 +354,7 @@ The ``Htmlquote`` function from the beego framework HTML-escapes a string, which ... } -We need to add a tuple to the ``barrierModel``\(package, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``barrierModel(package, type, subtypes, name, signature, ext, output, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml @@ -395,7 +395,7 @@ Consider a function called ``IsSafe`` which returns ``true`` when the data is co } } -We need to add a tuple to the ``barrierGuardModel``\(package, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``barrierGuardModel(package, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml @@ -434,7 +434,7 @@ This example shows how we can model a field read as a source of tainted data. ... } -We need to add a tuple to the ``sourceModel``\(package, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``sourceModel(package, type, subtypes, name, signature, ext, output, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst index 606cdf5c8df0..7b329e450f55 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst @@ -87,7 +87,7 @@ This is the ``execute`` method in the ``Statement`` class, which is located in t stmt.execute(query); // The argument to this method is a SQL injection sink. } -We need to add a tuple to the ``sinkModel``\(package, type, subtypes, name, signature, ext, input, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``sinkModel(package, type, subtypes, name, signature, ext, input, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml @@ -127,7 +127,7 @@ This is the ``getInputStream`` method in the ``Socket`` class, which is located ... } -We need to add a tuple to the ``sourceModel``\(package, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``sourceModel(package, type, subtypes, name, signature, ext, output, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml @@ -167,7 +167,7 @@ This pattern covers many of the cases where we need to summarize flow through a ... } -We need to add tuples to the ``summaryModel``\(package, type, subtypes, name, signature, ext, input, output, kind, provenance) extensible predicate by updating a data extension file: +We need to add tuples to the ``summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)`` extensible predicate by updating a data extension file: .. code-block:: yaml @@ -212,7 +212,7 @@ Here we model flow through higher order methods and collection types. ... } -We need to add tuples to the ``summaryModel``\(package, type, subtypes, name, signature, ext, input, output, kind, provenance) extensible predicate by updating a data extension file: +We need to add tuples to the ``summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)`` extensible predicate by updating a data extension file: .. code-block:: yaml @@ -271,7 +271,7 @@ This is the ``getName`` method in the ``File`` class, which is located in the `` ... } -We need to add a tuple to the ``barrierModel``\(package, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``barrierModel(package, type, subtypes, name, signature, ext, output, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml @@ -315,7 +315,7 @@ When the ``isAbsolute`` method returns ``false``, the URI is relative and theref } } -We need to add a tuple to the ``barrierGuardModel``\(package, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``barrierGuardModel(package, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml @@ -356,7 +356,7 @@ A neutral model is used to define that there is no flow through a method. ... } -We need to add a tuple to the ``neutralModel``\(package, type, name, signature, kind, provenance) extensible predicate by updating a data extension file. +We need to add a tuple to the ``neutralModel(package, type, name, signature, kind, provenance)`` extensible predicate by updating a data extension file. .. code-block:: yaml From 260a1a0d281e4dc7a2c65a9e3b0cb1bf4187445c Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan Date: Tue, 31 Mar 2026 15:03:20 +0100 Subject: [PATCH 11/11] Use hyphens in column names: "access-path", "accepting-value" --- .../customizing-library-models-for-cpp.rst | 2 +- .../customizing-library-models-for-csharp.rst | 16 +++++++-------- .../customizing-library-models-for-go.rst | 20 +++++++++---------- ...ing-library-models-for-java-and-kotlin.rst | 14 ++++++------- 4 files changed, 26 insertions(+), 26 deletions(-) diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst index 1a8e807c0694..b45ec1b726f6 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst @@ -253,7 +253,7 @@ The first five values identify the callable (in this case a free function) to be - The fifth value is the function input type signature, which can be used to narrow down between functions that have the same name. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the input specification, the ``accepting value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. +The remaining values are used to define the input specification, the ``accepting-value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. - The seventh value ``Argument[*0]`` is the input specification (the value being validated). In this case, the first indirection (or pointed-to value, ``*``) of the first argument (``Argument[0]``) passed to the function. - The eighth value ``true`` is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst index da267da9f2e5..60b334ad50cb 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst @@ -103,9 +103,9 @@ The first five values identify the callable (in this case a method) to be modele - The fifth value ``(System.String,System.Data.SqlClient.SqlConnection)`` is the method input type signature. The type names must be fully qualified. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the sink. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the sink. -- The seventh value ``Argument[0]`` is the ``access path`` to the first argument passed to the method, which means that this is the location of the sink. +- The seventh value ``Argument[0]`` is the ``access-path`` to the first argument passed to the method, which means that this is the location of the sink. - The eighth value ``sql-injection`` is the kind of the sink. The sink kind is used to define the queries where the sink is in scope. In this case - the SQL injection queries. - The ninth value ``manual`` is the provenance of the sink, which is used to identify the origin of the sink. @@ -143,7 +143,7 @@ The first five values identify the callable (in this case a method) to be modele - The fifth value ``()`` is the method input type signature. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the source. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the source. - The seventh value ``ReturnValue`` is the access path to the return of the method, which means that it is the return value that should be considered a source of tainted input. - The eighth value ``remote`` is the kind of the source. The source kind is used to define the threat model where the source is in scope. ``remote`` applies to many of the security related queries as it means a remote source of untrusted data. As an example the SQL injection query uses ``remote`` sources. For more information, see ":ref:`Threat models `." @@ -187,7 +187,7 @@ These are the same for both of the rows above as we are adding two summaries for - The fifth value ``(System.Object,System.Object)`` is the method input type signature. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the summary. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the summary. - The seventh value is the access path to the input (where data flows from). ``Argument[0]`` is the access path to the first argument (``s1`` in the example) and ``Argument[1]`` is the access path to the second argument (``s2`` in the example). - The eighth value ``ReturnValue`` is the access path to the output (where data flows to), in this case ``ReturnValue``, which means that the input flows to the return value. @@ -243,7 +243,7 @@ These are the same for both of the rows above as we are adding two summaries for - The fifth value ``()`` is the method input type signature. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the summary. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the summary. - The seventh value is the access path to the input (where data flows from). ``Argument[this]`` is the access path to the qualifier (``s`` in the example). - The eighth value ``ReturnValue`` is the access path to the output (where data flows to), in this case ``ReturnValue``, which means that the input flows to the return value. @@ -287,7 +287,7 @@ These are the same for both of the rows above as we are adding two summaries for - The fifth value ``(System.Collections.Generic.IEnumerable,System.Func)`` is the method input type signature. The generics in the signature must match the generics in the method signature in the source code. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the summary definition. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the summary definition. - The seventh value is the access path to the ``input`` (where data flows from). - The eighth value is the access path to the ``output`` (where data flows to). @@ -344,7 +344,7 @@ The first five values identify the callable (in this case the getter of a proper - The fifth value ``()`` is the method input type signature. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the barrier. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the barrier. - The seventh value ``ReturnValue`` is the access path to the return value of the property getter, which means that the return value is considered safe. - The eighth value ``url-redirection`` is the kind of the barrier. The barrier kind is used to define the queries where the barrier is in scope. In this case - the URL redirection queries. @@ -386,7 +386,7 @@ The first five values identify the callable (in this case the getter of a proper - The fifth value ``()`` is the method input type signature. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``accepting value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. +The remaining values are used to define the ``access-path``, the ``accepting-value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. - The seventh value ``Argument[this]`` is the access path to the input whose flow is blocked. In this case, the qualifier of the property access (``uri`` in the example). - The eighth value ``false`` is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. In this case, when ``IsAbsoluteUri`` is ``false``, the URL is relative and considered safe. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst index 1d8abed14e20..0c7db5cd40fc 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst @@ -103,9 +103,9 @@ The first five values identify the function (in this case a method) to be modele - The fifth value ``""`` is the input type signature. For Go it should always be an empty string. It is needed for other languages where multiple functions may have the same name and they need to be distinguished by the number and types of the arguments. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the sink. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the sink. -- The seventh value ``Argument[0]`` is the ``access path`` to the first argument passed to the method, which means that this is the location of the sink. +- The seventh value ``Argument[0]`` is the ``access-path`` to the first argument passed to the method, which means that this is the location of the sink. - The eighth value ``sql-injection`` is the kind of the sink. The sink kind is used to define the queries where the sink is in scope. In this case - the SQL injection queries. - The ninth value ``manual`` is the provenance of the sink, which is used to identify the origin of the sink. @@ -144,7 +144,7 @@ The first five values identify the function to be modeled as a source. - The fifth value ``""`` is the input type signature. For Go it should always be an empty string. It is needed for other languages where multiple functions may have the same name and they need to be distinguished by the number and types of the arguments. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the source. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the source. - The seventh value ``ReturnValue`` is the access path to the return of the method, which means that it is the return value that should be considered a source of tainted input. - The eighth value ``remote`` is the kind of the source. The source kind is used to define the threat model where the source is in scope. ``remote`` applies to many of the security related queries as it means a remote source of untrusted data. As an example the SQL injection query uses ``remote`` sources. For more information, see ":ref:`Threat models `." @@ -187,7 +187,7 @@ The first five values identify the function to be modeled as a summary. - The fifth value ``""`` is the input type signature. For Go it should always be an empty string. It is needed for other languages where multiple functions may have the same name and they need to be distinguished by the number and types of the arguments. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the summary. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the summary. - The seventh value is the access path to the input (where data flows from). ``Argument[0].ArrayElement`` is the access path to the array elements of the first argument (the elements of the slice in the example). - The eighth value ``ReturnValue`` is the access path to the output (where data flows to), in this case ``ReturnValue``, which means that the input flows to the return value. @@ -232,7 +232,7 @@ The first five values identify the function to be modeled as a summary. - The fifth value ``""`` is the input type signature. For Go it should always be an empty string. It is needed for other languages where multiple functions may have the same name and they need to be distinguished by the number and types of the arguments. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the summary. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the summary. - The seventh value is the access path to the input (where data flows from). ``Argument[0].ArrayElement.ArrayElement`` is the access path to the array elements of the array elements of the first argument. Note that a variadic parameter of type `...T` is treated as if it has type `[]T` and arguments corresponding to the variadic parameter are accessed as elements of this slice. - The eighth value ``ReturnValue.ArrayElement`` is the access path to the output (where data flows to), in this case ``ReturnValue.ArrayElement``, which means that the input flows to the array elements of the return value. @@ -279,7 +279,7 @@ These are the same for both of the rows above as we are adding two summaries for - The fifth value ``""`` is the input type signature. For Go it should always be an empty string. It is needed for other languages where multiple functions may have the same name and they need to be distinguished by the number and types of the arguments. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the summary. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the summary. - The seventh value is the access path to the input (where data flows from). ``Argument[0]`` is the access path to the first argument (``elems`` in the example) and ``Argument[1]`` is the access path to the second argument (``sep`` in the example). - The eighth value ``ReturnValue`` is the access path to the output (where data flows to), in this case ``ReturnValue``, which means that the input flows to the return value. @@ -334,7 +334,7 @@ The first five values identify the function (in this case a method) to be modele - The fifth value ``""`` is the input type signature. For Go it should always be an empty string. It is needed for other languages where multiple functions may have the same name and they need to be distinguished by the number and types of the arguments. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the summary. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the summary. - The seventh value is the access path to the input (where data flows from). ``Argument[receiver]`` is the access path to the receiver (``u`` in the example). - The eighth value ``ReturnValue`` is the access path to the output (where data flows to), in this case ``ReturnValue``, which means that the input flows to the return value. When there are multiple return values, use ``ReturnValue[i]`` to refer to the ``i`` th return value (starting from 0). @@ -375,7 +375,7 @@ The first five values identify the function to be modeled as a barrier. - The fifth value ``""`` is the input type signature. For Go it should always be an empty string. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the barrier. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the barrier. - The seventh value ``ReturnValue`` is the access path to the output of the barrier, which means that the return value is considered sanitized. - The eighth value ``html-injection`` is the kind of the barrier. The barrier kind must match the kind used in the query where the barrier should take effect. In this case, it matches the ``html-injection`` sink kind used by XSS queries. @@ -416,7 +416,7 @@ The first five values identify the function to be modeled as a barrier guard. - The fifth value ``""`` is the input type signature. For Go it should always be an empty string. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``accepting value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. +The remaining values are used to define the ``access-path``, the ``accepting-value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. - The seventh value ``Argument[0]`` is the access path to the input whose flow is blocked. In this case, the first argument to the function (``input`` in the example). - The eighth value ``true`` is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. In this case, when ``IsSafe`` returns ``true``, the input is considered safe. @@ -455,7 +455,7 @@ The first five values identify the field to be modeled as a source. - The fifth value ``""`` is the input type signature. For Go it should always be an empty string. It is needed for other languages where multiple functions may have the same name and they need to be distinguished by the number and types of the arguments. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the source. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the source. - The seventh value ``""`` is left blank. Leaving the access path of a source model blank indicates that it is a field access. - The eighth value ``remote`` is the source kind. This indicates that the source is a remote source of untrusted data. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst index 7b329e450f55..1d32d196b07b 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst @@ -109,9 +109,9 @@ The first five values identify the callable (in this case a method) to be modele - The fifth value ``(String)`` is the method input type signature. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the sink. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the sink. -- The seventh value ``Argument[0]`` is the ``access path`` to the first argument passed to the method, which means that this is the location of the sink. +- The seventh value ``Argument[0]`` is the ``access-path`` to the first argument passed to the method, which means that this is the location of the sink. - The eighth value ``sql-injection`` is the kind of the sink. The sink kind is used to define the queries where the sink is in scope. In this case - the SQL injection queries. - The ninth value ``manual`` is the provenance of the sink, which is used to identify the origin of the sink. @@ -149,7 +149,7 @@ The first five values identify the callable (in this case a method) to be modele - The fifth value ``()`` is the method input type signature. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the source. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the source. - The seventh value ``ReturnValue`` is the access path to the return of the method, which means that it is the return value that should be considered a source of tainted input. - The eighth value ``remote`` is the kind of the source. The source kind is used to define the threat model where the source is in scope. ``remote`` applies to many of the security related queries as it means a remote source of untrusted data. As an example the SQL injection query uses ``remote`` sources. For more information, see ":ref:`Threat models `." @@ -193,7 +193,7 @@ These are the same for both of the rows above as we are adding two summaries for - The fifth value ``(String)`` is the method input type signature. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the summary. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the summary. - The seventh value is the access path to the input (where data flows from). ``Argument[this]`` is the access path to the qualifier (``s1`` in the example) and ``Argument[0]`` is the access path to the first argument (``s2`` in the example). - The eighth value ``ReturnValue`` is the access path to the output (where data flows to), in this case ``ReturnValue``, which means that the input flows to the return value. @@ -237,7 +237,7 @@ These are the same for both of the rows above as we are adding two summaries for - The fifth value ``Function`` is the method input type signature. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the summary definition. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the summary definition. - The seventh value is the access path to the ``input`` (where data flows from). - The eighth value is the access path to the ``output`` (where data flows to). @@ -293,7 +293,7 @@ The first five values identify the callable (in this case a method) to be modele - The fifth value ``()`` is the method input type signature. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the barrier. +The remaining values are used to define the ``access-path``, the ``kind``, and the ``provenance`` (origin) of the barrier. - The seventh value ``ReturnValue`` is the access path to the return of the method, which means that it is the return value that should be considered a barrier. - The eighth value ``path-injection`` is the kind of the barrier. The barrier kind is used to define the queries where the barrier is in scope. In this case - the path injection queries. @@ -337,7 +337,7 @@ The first five values identify the callable (in this case a method) to be modele - The fifth value ``()`` is the method input type signature. The sixth value should be left empty and is out of scope for this documentation. -The remaining values are used to define the ``access path``, the ``accepting value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. +The remaining values are used to define the ``access-path``, the ``accepting-value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. - The seventh value ``Argument[this]`` is the access path to the input whose flow is blocked. In this case, the qualifier of the method call (``uri`` in the example). - The eighth value ``false`` is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. In this case, when ``isAbsolute`` is ``false``, the URI is relative and considered safe.