hohn/codeql
1
0
Fork 0
mirror of https://github.com/github/codeql.git synced 2026-01-29 14:23:03 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #247 from shati-patel/docs

Browse Source 
Docs: Editorial changes to library modeling topic
This commit is contained in:
Max Schaefer
2020-07-07 13:37:51 +01:00
committed by GitHub
parent b4c56928c4 5ddcf92859
commit 3a897a9dd0
1 changed files with 11 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
docs/language/learn-ql/go/library-modeling-go.rst
View File

@@ -2,7 +2,7 @@ Modeling data flow in Go libraries
==================================
When analyzing a Go program, CodeQL does not examine the source code for
external packages. To track the flow of untrusted data through a library you
external packages. To track the flow of untrusted data through a library, you
can create a model of the library.
You can find existing models in the ``ql/src/semmle/go/frameworks/`` folder of the
@@ -20,9 +20,9 @@ example from ``Mux.qll``.
.. code-block:: ql
class RequestVars extends DataFlow::UntrustedFlowSource::Range, DataFlow::CallNode {
RequestVars() { this.getTarget().hasQualifiedName("github.com/gorilla/mux", "Vars") }
}
class RequestVars extends DataFlow::UntrustedFlowSource::Range, DataFlow::CallNode {
RequestVars() { this.getTarget().hasQualifiedName("github.com/gorilla/mux", "Vars") }
}
This has the effect that all calls to `the function Vars from the
package mux <http://www.gorillatoolkit.org/pkg/mux#Vars>`__ are
@@ -68,7 +68,7 @@ outputs to a function. The options are:
* one of the parameters (``outp.isParameter(i)``)
* one of the results (``outp.isResult(i)``, or ``outp.isResult`` if there is only one result)
Here is an example from ``Gin.qll``, slightly modified for brevity.
Here is an example from ``Gin.qll``, which has been slightly simplified.
.. code-block:: ql
@@ -89,8 +89,8 @@ the receiver to the first result. In other words, if ``p`` has type
Sanitizers
----------
It is not necessary to indicate that library functions are sanitizers -
because their bodies are not analyzed it is assumed that data does not
It is not necessary to indicate that library functions are sanitizers.
Their bodies are not analyzed, so it is assumed that data does not
flow through them.
Sinks
@@ -101,13 +101,12 @@ However, you can use library models to indicate when functions belong to
special categories. Queries can then use these categories when specifying
sinks. Classes representing these special categories are contained in
``ql/src/semmle/go/Concepts.qll`` in the `CodeQL for Go repository
<https://github.com/github/codeql-go/blob/main/ql/src/semmle/go/Concepts.qll>`__,
including classes for logger mechanisms,
<https://github.com/github/codeql-go/blob/main/ql/src/semmle/go/Concepts.qll>`__.
``Concepts.qll`` includes classes for logger mechanisms,
HTTP response writers, HTTP redirects, and marshaling and unmarshaling
functions.
Here is a short example from ``Stdlib.qll``, slightly modified for
brevity.
Here is a short example from ``Stdlib.qll``, which has been slightly simplified.
.. code-block:: ql
@@ -120,4 +119,4 @@ brevity.
This has the effect that any call to ``Print``, ``Printf``, or
``Println`` in the package ``fmt`` is recognized as a logger call.
Any query that uses logger calls as a sink will then identify when tainted data
has been passed as an argument to ``Print``, ``Printf``, or ``Println``.
has been passed as an argument to ``Print``, ``Printf``, or ``Println``.