This space contains one page for each of the C++ built-in queries for the most recent release of the QL tools. Each page contains: The queries built into the QL tools include queries that: The heatmap below shows the labels for C++ built-in queries, click a label to view all queries with that tag or query type.
About the queries
Exploring the queries
This space contains one page for each of the C++ built-in queries for the most recent release of the QL tools. Each page contains:
The queries built into the QL tools include queries that:
The heatmap below shows the labels for C++ built-in queries, click a label to view all queries with that tag or query type.
About the security queries
There are two query suites for C security analysis:
all. For most projects we recommend that you run queries from the
default suite. The
all suite contains a few additional rules which perform points-to analysis and may timeout on some projects. These rules test for the following CWEs:
Many queries rely on tracking the flow of data from sources that cannot be guaranteed to be safe. Where possible, the source of the potentially unsafe data is reported in the query violation message, indicating why that particular use of the data was considered dangerous. We describe here how some common sources of data are classified, in order to make it clear why these are considered to be potentially dangerous.
A common data source is data that comes from a user. This must be treated as untrusted unless it is validated, as a malicious user can send unexpected data that can have undesirable effects, such as allowing them to perform a SQL injection attack.
The sources that we consider user input are listed below:
Getting the value of a system environment variable
The environment in which a program is run is often under the control of the user who runs the program.
Getting a parameter from an HttpServletRequest
Spoofing a request can give the user control even over parameters which are not usually set by the user.
Getting the query string from an HttpServletRequest
The query string comes from the URL, which is under the control of the user.
Getting the header from an HttpServletRequest
Spoofing a request can give the user control over the header.
Getting the value of a property from a Properties object
Properties objects are commonly written to and read from disk, which may be under the control of the user.
Getting the output of a ResultSet
Databases may contain user input that has been stored, and as such must be treated as untrusted.
Getting the value of a cookie
Cookies are controlled by the client, and so their values must be treated as untrusted.
Getting the hostname of a request using reverse DNS
If the user controls their DNS server, then they can return whatever result they wish for a reverse DNS lookup.
Security analysis testing
Summary of results
The following table summarizes the results for the latest release of the C/C++ security queries run against the SAMATE Juliet 1.3 tests. In the table, each row represents a weakness, and the columns show the following information:
- TP – count of all true positive results: the code has a known security weakness, and Semmle’s analyses correctly identify this defect.
- FP – count of all false positive results: the code has no known security weakness, but Semmle’s analyses are over cautious and suggest a potential problem.
- TN – count of true negative results: the code has no known security weakness, and Semmle's analyses correctly pass the code as secure.
- FN – count of all false negative results: the code has a known security weakness, but Semmle’s analyses fail to identify this defect.
In an ideal implementation of the analyses, the number of false positives (FP) and false negatives (FN) would be zero, but that is impossible to achieve by static analysis. The figures for FP and FN show where there are limitations in the present implementation.
Interpreting the results
The report CAS Static Analysis Tool Study – Methodology, by the Center for Assured Software of the National Security Agency of the USA defines four different ways to measure success:
- Precision = TP/ (FP+TP)
- Recall = TP/(TP+FN)
- F-Score = 2*(Precision*Recall)/(Precision+Recall)
- Discrimination rate = #discriminated tests / #tests
For each of these metrics, a higher score is better. There is clearly a trade-off between the precision and recall metrics: increasing the level of precision or recall for any analysis reduces the level of the other metric. The F-score is therefore an attempt to quantify the balance of decision between these two metrics.
The following table shows the results of calculating these metrics for the results shown above. These scores compare very favorably with the sample tools tested by the Center for Assured Software.
The tests suggest that Semmle has made judicious choices balancing the number of false positive results (an incorrect warning is issued) and false negative results (a true defect was not identified). Where comparative results are available for other tools, the Semmle analyses stand out for their exceptional accuracy.