Severity Levels Update to Include Critical
With the addition of the Critical Severity, the entire set of SAST queries were reviewed for re-classification. As consequence, it means not only queries moving from High to Critical were reviewed, but also queries having lower severity were affected, while many queries had more meaningful severity changes.
Critical Severity Shift
By expanding the severity spectrum from 3 to 4 levels of severity, all queries had to be reviewed to ensure their classification remained appropriate.
As a result, for example, a query in the Low category that is more impactful than most others could be reassigned to a higher severity level.
Most affected by these are high-effort medium-impact vulnerabilities, exploitability of which is quite low, but not entirely negligible.
For example, the Secure flag could allow an attacker on the same network to steal user tokens by downgrading a connection to an insecure one. This depends on various factors such as HSTS and the HTTP client’s tolerance for downgrades, which is why queries related to the Secure flag have been raised from Low to Medium severity. Conversely, leaking code information via a stack trace may enable attackers to fingerprint a server's technology, but it doesn't pose a significant security risk and will remain classified as Low.
This added granularity provides a more nuanced approach to assessing risk within a less rigid severity system.
Most Significant Severity Changes
Severity changes can reflect various factors, such as shifting perceptions in the application security landscape, the expansion of exploitation techniques, and the evolution of technologies, all of which can alter overall risk over time. Another key reason is that SAST queries are designed to identify code weaknesses and classify them without context. Additional engines that provide context and risk calculations relieve SAST queries from the task of 'assuming context,' enabling them to focus on representing the inherent severity of the weakness, rather than attempting to infer and project a severity based on factors that are unknowable in a static context.
The following table represents the larger shifts, where severity was changed by more than one level:
Language | Query Name | Old Severity | New Severity | Reason |
|---|---|---|---|---|
Java | CGI_Stored_XSS | Medium | Critical | Consistency. All Stored XSS has a baseline severity of Critical, as it could allow attackers to poach high permission users without social engineering; this follows an improvement in CGI detection to raise confidence that the result is in code that relies on CGI in the first place. |
Groovy | CGI_Stored_XSS | Medium | Critical | |
PHP | SSTI_Twig | SSTI_Twig | Critical | Updated during reevaluation of impact as this would lead to the same result as PHP code injection, which is also Critical. |
Java | Stored_Code_Injection | Low | Critical | Historically, stored variants have had different severity compared to regular queries. We have reconsidered this approach. Stored variants are often as dangerous (if not more, in the case of Stored XSS), and stored inputs must be validated to ensure they cannot be tainted by malicious actors. What changes between variants of queries derived from a stored source, instead of user input, is a level of confidence and context that are not handled by the SAST engine itself. Where a functionality for a stored source is used as intended, it must be validated. For example a design requiring evaluating code from a file, loading a SQL statement from a database, or dynamically executing a local program. These are still potential weaknesses, and must be validated during an audit rather than at the scan phase. |
Java | Stored_Command_Injection | Medium | Critical | |
Java | Stored_Mongo_NoSQL_Injection | Low | Critical | |
CPP | Second_Order_SQL_Injection | Medium | Critical | |
CPP | Stored_Buffer_Overflow_boundcpy | Medium | Critical | |
CPP | Stored_Buffer_Overflow_cpycat | Medium | Critical | |
CPP | Stored_Buffer_Overflow_fgets | Medium | Critical | |
CPP | Stored_Buffer_Overflow_fscanf | Medium | Critical | |
ASP | Stored_Code_Injection | Medium | Critical | |
CSharp | Stored_Code_Injection | Low | Critical | |
Groovy | Stored_Code_Injection | Low | Critical | |
JavaScript | Stored_Code_Injection | Medium | Critical | |
Perl | Stored_Code_Injection | Medium | Critical | |
PHP | Stored_Code_Injection | Medium | Critical | |
Python | Stored_Code_Injection | Low | Critical | |
Ruby | Stored_Code_Injection | Medium | Critical | |
Scala | Stored_Code_Injection | Low | Critical | |
VB6 | Stored_Code_Injection | Low | Critical | |
VbNet | Stored_Code_Injection | Low | Critical | |
CPP | Stored_Command_Injection | Medium | Critical | |
CSharp | Stored_Command_Injection | Medium | Critical | |
Groovy | Stored_Command_Injection | Medium | Critical | |
Kotlin | Stored_Command_Injection | Medium | Critical | |
Perl | Stored_Command_Injection | Medium | Critical | |
PHP | Stored_Command_Injection | Medium | Critical | |
Python | Stored_Command_Injection | Medium | Critical | |
Scala | Stored_Command_Injection | Medium | Critical | |
VbNet | Stored_Command_Injection | Medium | Critical | |
Java | JWT_Use_Of_None_Algorithm | Low | High | A JWT token with None validation is very likely to allow complete horizontal and vertical hijacking of all user accounts. |
JavaScript | JWT_Use_Of_None_Algorithm | Low | High | |
Kotlin | JWT_Use_Of_None_Algorithm | Low | High | |
Scala | JWT_Use_Of_None_Algorithm | Low | High | |
PHP | Comparison_Timing_Attack | Low | High | This query has been improved to identify cryptographic or authentication contexts, which would allow detection of timing attacks specifically to disclose sensitive authentication information. |
Ruby | Connection_String_Injection | Low | High | Parity with other languages. |
Python | Debug_Enabled | Low | High | Debug mode for the Python servers as caught by this query isn’t limited to just debug information; it may also allow code execution with proper credentials, which could expose the server to significant risk when in production. |
Java | Improper_Build_Of_Sql_Mapping | Low | High | SQL Injection variant, so severity changed to match SQL Injection. |
Groovy | Improper_Build_Of_Sql_Mapping | Low | High | |
Go | Plain_Text_Transport_Layer_in_Server | Low | High | Parity |
Objc | Use_of_Hardcoded_Cryptographic_Key | Low | High | Parity. Other queries of this query set changed from Medium to High in mobile only. |
Swift | Use_of_Hardcoded_Cryptographic_Key | Low | High | |
Java | Spring_Missing_Object_Level_Authorization | Information | Medium | Parity. The original “Information” severity was incorrect, and has been fixed. |
Swift | Third_Party_Keyboard_Enabled | Information | Medium | Parity. Other queries of this query set were changed from Low to Medium. |
Dart | WebView_Cache_Information_Leak | Medium | Information | This issue is highly unlikely to be exploited and is more of a coding practice concern. |
Java | WebView_Cache_Information_Leak | Medium | Information | |
Kotlin | WebView_Cache_Information_Leak | Medium | Information |