Query Structure

When CxSAST or CxAudit scans source code, it first builds a graph of the code's elements and their logical flows through the code. Then it queries this internal code graph, using its list of built-in per-language queries, and also your custom queries.

Most queries check where the code allows information to go from source to sink without being properly sanitized. This means that most queries have the following structure, or something similar to it:

1. Find a certain type of input in the source code
2. Find a certain type of effect on database, operating system, or other output in the source code
3. Find places where the source code sanitizes input
4. As the final result for this query, define paths from input source (1) to sink (2) that do not pass through sanitation (3)

For example, the Java SQL_Injection query is:

CxList inputs = Find_Interactive_Inputs();
CxList db = Find_DB();
CxList sanitized = Find_Sanitize(); 
result = All.FindSQLInjections(inputs, db, sanitized);

Notice how each of the above four lines calls a function. Each of those four functions is actually another Cx query. Most such building-block queries are listed under Cx > General (see the The Query List).

Many of these building-block queries are used by multiple higher-level queries. So, for example, if you add a custom code element to a building-block query that performs sanitation, then that code element will be recognized as sanitation by all queries that use this building-block query.

Similarly, if you add a custom code element to a building-block query that checks for inputs or database commands, it will be recognized across queries as input or a database command. CxAudit provides tools for adding code elements directly from the source code into building-block queries.