mirror of
https://github.com/github/codeql.git
synced 2025-12-17 01:03:14 +01:00
@@ -11,7 +11,7 @@ caused by an unhandled case.</p>
|
||||
|
||||
</overview>
|
||||
<recommendation>
|
||||
<p>Check that the unused static variable does not indicate a defect, for example, an unhandled case. If the static variable is genuinuely not needed,
|
||||
<p>Check that the unused static variable does not indicate a defect, for example, an unhandled case. If the static variable is genuinely not needed,
|
||||
then removing it will make code more readable. If the static variable is needed then you should update the code to fix the defect.</p>
|
||||
|
||||
</recommendation>
|
||||
|
||||
@@ -19,7 +19,7 @@ This can occur when an operation performed on the open descriptor fails, and the
|
||||
|
||||
<example>
|
||||
<p>In the example below, the <code>sockfd</code> socket may remain open if an error is triggered.
|
||||
The code should be updated to ensure that the socket is always closed when when the function ends.
|
||||
The code should be updated to ensure that the socket is always closed when the function ends.
|
||||
</p>
|
||||
<sample src="DescriptorMayNotBeClosed.cpp" />
|
||||
</example>
|
||||
|
||||
@@ -15,7 +15,7 @@ As an exception, because their purpose is usually obvious, it is not necessary t
|
||||
</overview>
|
||||
<recommendation>
|
||||
<p>
|
||||
Add comments to document the purpose of the function. In particular, ensure that the public API of the function is carefully documented. This reduces the chance that a future change to the function will introduce a defect by changing the API and breaking the expections of the calling functions.
|
||||
Add comments to document the purpose of the function. In particular, ensure that the public API of the function is carefully documented. This reduces the chance that a future change to the function will introduce a defect by changing the API and breaking the expectations of the calling functions.
|
||||
</p>
|
||||
|
||||
</recommendation>
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
<overview>
|
||||
<p>
|
||||
This rule finds comparison expressions that use 2 or more comparison operators and are not completely paranthesized.
|
||||
This rule finds comparison expressions that use 2 or more comparison operators and are not completely parenthesized.
|
||||
It is best to fully parenthesize complex comparison expressions to explicitly define the order of the comparison operators.
|
||||
</p>
|
||||
|
||||
|
||||
@@ -6,9 +6,9 @@
|
||||
<overview>
|
||||
<p>This rule finds logical-not operator usage as an operator for in a bit-wise operation.</p>
|
||||
|
||||
<p>Due to the nature of logical operation result value, only the lowest bit could possibly be set, and it is unlikely to be intent in bitwise opeartions. Violations are often indicative of a typo, using a logical-not (<code>!</code>) opeartor instead of the bit-wise not (<code>~</code>) operator. </p>
|
||||
<p>Due to the nature of logical operation result value, only the lowest bit could possibly be set, and it is unlikely to be intent in bitwise operations. Violations are often indicative of a typo, using a logical-not (<code>!</code>) operator instead of the bit-wise not (<code>~</code>) operator. </p>
|
||||
<p>This rule is restricted to analyze bit-wise and (<code>&</code>) and bit-wise or (<code>|</code>) operation in order to provide better precision.</p>
|
||||
<p>This rule ignores instances where a double negation (<code>!!</code>) is explicitly used as the opeartor of the bitwise operation, as this is a commonly used as a mechanism to normalize an integer value to either 1 or 0.</p>
|
||||
<p>This rule ignores instances where a double negation (<code>!!</code>) is explicitly used as the operator of the bitwise operation, as this is a commonly used as a mechanism to normalize an integer value to either 1 or 0.</p>
|
||||
<p>NOTE: It is not recommended to use this rule in kernel code or older C code as it will likely find several false positive instances.</p>
|
||||
|
||||
</overview>
|
||||
|
||||
@@ -49,7 +49,7 @@ pointer overflow.
|
||||
|
||||
<p>
|
||||
While it's not the subject of this query, the expression <code>ptr + i <
|
||||
ptr_end</code> is also an invalid range check. It's undefined behavor in
|
||||
ptr_end</code> is also an invalid range check. It's undefined behavior in
|
||||
C/C++ to create a pointer that points more than one past the end of an
|
||||
allocation.
|
||||
</p>
|
||||
|
||||
@@ -12,7 +12,7 @@ the third argument to the entire size of the destination buffer.
|
||||
Executing a call of this type may cause a buffer overflow unless the buffer is known to be empty.</p>
|
||||
|
||||
<p>Similarly, calls of the form <code>strncat(dest, src, sizeof (dest) - strlen (dest))</code> allow one
|
||||
byte to be written ouside the <code>dest</code> buffer.</p>
|
||||
byte to be written outside the <code>dest</code> buffer.</p>
|
||||
|
||||
<p>Buffer overflows can lead to anything from a segmentation fault to a security vulnerability.</p>
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
<p>
|
||||
This metric provides an indication of the lack of cohesion of a class,
|
||||
using a method proposed by Chidamber and Kemerer in 1994. The idea
|
||||
behind measuring a class's cohesion is that most funcions in well-designed
|
||||
behind measuring a class's cohesion is that most functions in well-designed
|
||||
classes will access the same fields. Types that exhibit a lack of cohesion
|
||||
are often trying to take on multiple responsibilities, and should be split
|
||||
into several smaller classes.
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
by changes to other packages. If this metric value is high, a package is easily
|
||||
influenced. If the values is low, the impact of changes to other packages is likely to be minimal. Instability
|
||||
is estimated as the number of outgoing dependencies relative to the total
|
||||
number of depencies.</p>
|
||||
number of dependencies.</p>
|
||||
</overview>
|
||||
|
||||
<references>
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
by changes to other packages. If this metric value is high, a package is easily
|
||||
influenced. If the values is low, the impact of changes to other packages is likely to be minimal. Instability
|
||||
is estimated as the number of outgoing dependencies relative to the total
|
||||
number of depencies.</p>
|
||||
number of dependencies.</p>
|
||||
</overview>
|
||||
|
||||
<references>
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
|
||||
<overview>
|
||||
<p>This query indicates that a call is setting the DACL field in a <code>SECURITY_DESCRIPTOR</code> to null.</p>
|
||||
<p>When using <code>SetSecurityDescriptorDacl</code> to set a discretionary access control (DACL), setting the <code>bDaclPresent</code> argument to <code>TRUE</code> indicates the prescence of a DACL in the security description in the argument <code>pDacl</code>.</p>
|
||||
<p>When using <code>SetSecurityDescriptorDacl</code> to set a discretionary access control (DACL), setting the <code>bDaclPresent</code> argument to <code>TRUE</code> indicates the presence of a DACL in the security description in the argument <code>pDacl</code>.</p>
|
||||
<p>When the <code>pDacl</code> parameter does not point to a DACL (i.e. it is <code>NULL</code>) and the <code>bDaclPresent</code> flag is <code>TRUE</code>, a <code>NULL DACL</code> is specified.</p>
|
||||
<p>A <code>NULL DACL</code> grants full access to any user who requests it; normal security checking is not performed with respect to the object.</p>
|
||||
</overview>
|
||||
|
||||
@@ -12,7 +12,7 @@ The user should check the return value of `scanf` and related functions and chec
|
||||
</p>
|
||||
</recommendation>
|
||||
<example>
|
||||
<p>The first first example below is correct, as value of `i` is only read once it is checked that `scanf` has read one item. The second example is incorrect, as the return value of `scanf` is not checked, and as `scanf` might have failed to read any item before returning.</p>
|
||||
<p>The first example below is correct, as value of `i` is only read once it is checked that `scanf` has read one item. The second example is incorrect, as the return value of `scanf` is not checked, and as `scanf` might have failed to read any item before returning.</p>
|
||||
<sample src="ImproperCheckReturnValueScanf.cpp" />
|
||||
|
||||
</example>
|
||||
|
||||
@@ -5,12 +5,12 @@
|
||||
<overview>
|
||||
<p>
|
||||
Some header files, such as those which define structures or classes, cannot be included more than once within a translation unit, as doing so would
|
||||
cause a redefinition error. Such headers must be guarded to prevent ill-effects from multiple inclusion. Simlarly, if header files include other
|
||||
cause a redefinition error. Such headers must be guarded to prevent ill-effects from multiple inclusion. Similarly, if header files include other
|
||||
header files, and this inclusion graph contains a cycle, then at least one file within the cycle must contain header guards in order to break the
|
||||
cycle. Because of cases like these, all headers should be guarded as a matter of good practice, even if they do not strictly need to be.
|
||||
</p>
|
||||
<p>
|
||||
Furthermore, most modern compilers contain optimisations which are triggered by header guards. If the header guard strictly conforms to the pattern
|
||||
Furthermore, most modern compilers contain optimizations which are triggered by header guards. If the header guard strictly conforms to the pattern
|
||||
that compilers expect, then inclusions of that header other than the first have absolutely no effect: the file isn't re-read from disk, nor is it
|
||||
re-tokenised or re-preprocessed. This can result in a noticeable, albeit minor, improvement to compilation time.
|
||||
</p>
|
||||
|
||||
@@ -18,7 +18,7 @@ more difficult to change which implementation you are using at a later date.</p>
|
||||
</example>
|
||||
<references>
|
||||
|
||||
<li>C# Corner, <a href="http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_interrfaces03052006095933AM/csharp_interrfaces.aspx">C# Interface Based Development</a>.</li>
|
||||
<li>C# Corner, <a href="https://www.c-sharpcorner.com/article/C-Sharp-interface-based-development/">C# Interface Based Development</a>.</li>
|
||||
|
||||
</references>
|
||||
</qhelp>
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
<overview>
|
||||
<p>
|
||||
Comparisons which always yield the same result are unnecessary and may indicate a bug in the
|
||||
logic. This can can happen when the data type of one of the operands has a limited range of values.
|
||||
logic. This can happen when the data type of one of the operands has a limited range of values.
|
||||
For example unsigned integers are always greater than or equal to zero, and <code>byte</code>
|
||||
values are always less than 256.
|
||||
</p>
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
</p>
|
||||
</overview>
|
||||
<recommendation>
|
||||
<p>Use speific era when creating DateTime and DateTimeOffset structs from previously stored date in Japanese calendar</p>
|
||||
<p>Use specific era when creating DateTime and DateTimeOffset structs from previously stored date in Japanese calendar</p>
|
||||
<p>Don't store dates in Japanese format</p>
|
||||
<p>Don't use hard-coded era start date for date calculations converting dates from Japanese date format</p>
|
||||
<p>Use <code>JapaneseCalendar</code> class for date formatting only</p>
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
<include src="ThreadUnsafeICryptoTransformOverview.inc.qhelp" />
|
||||
</overview>
|
||||
<recommendation>
|
||||
<p>Create new instances of the object that implements or has a field of type <code>System.Security.Cryptography.ICryptoTransform</code> to avoid sharing it accross multiple threads.</p>
|
||||
<p>Create new instances of the object that implements or has a field of type <code>System.Security.Cryptography.ICryptoTransform</code> to avoid sharing it across multiple threads.</p>
|
||||
|
||||
</recommendation>
|
||||
<example>
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
<qhelp>
|
||||
<overview>
|
||||
<p>ECB should not be used as a mode for encryption. It has dangerous weaknesses. Data is encrypted the same way every time
|
||||
meaning the same plaintext input will always produce the same cyphertext. This makes encrypted messages vulnerable
|
||||
meaning the same plaintext input will always produce the same ciphertext. This makes encrypted messages vulnerable
|
||||
to replay attacks.</p>
|
||||
|
||||
</overview>
|
||||
|
||||
@@ -30,7 +30,7 @@ When the allow list contains only a single host key then the function <code>Fixe
|
||||
</recommendation>
|
||||
|
||||
<example>
|
||||
<p>The following example shows the use of <code>InsecureIgnoreHostKey</code> and an insecure host key callback implemention commonly used in non-production code.</p>
|
||||
<p>The following example shows the use of <code>InsecureIgnoreHostKey</code> and an insecure host key callback implementation commonly used in non-production code.</p>
|
||||
|
||||
<sample src="InsecureHostKeyCallbackExample.go" />
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@
|
||||
<recommendation>
|
||||
|
||||
<p>
|
||||
Generating a cryptograhically secure secret key during application initialization and using this generated key for future JWT signing requests can prevent this vulnerability.
|
||||
Generating a cryptographically secure secret key during application initialization and using this generated key for future JWT signing requests can prevent this vulnerability.
|
||||
</p>
|
||||
|
||||
</recommendation>
|
||||
|
||||
@@ -18,7 +18,7 @@ possibly causing a divide-by-zero panic.
|
||||
</p>
|
||||
<sample src="DivideByZeroBad.go" />
|
||||
<p>
|
||||
This can be fixed by testing the divisor against against zero:
|
||||
This can be fixed by testing the divisor against zero:
|
||||
</p>
|
||||
<sample src="DivideByZeroGood.go" />
|
||||
</example>
|
||||
|
||||
@@ -14,7 +14,7 @@ server side request forgery attacks, where the attacker controls the request tar
|
||||
<p>
|
||||
To guard against server side request forgery, it is advisable to avoid putting user input directly into a
|
||||
network request. If using user input is necessary, then it must be validated. It is recommended to only allow
|
||||
user input consisting of alphanumeric characters. Simply URL-encoding other chracters is not always a solution,
|
||||
user input consisting of alphanumeric characters. Simply URL-encoding other characters is not always a solution,
|
||||
for example because a downstream entity that is itself vulnerable may decode again before forwarding the request.
|
||||
</p>
|
||||
</recommendation>
|
||||
|
||||
@@ -120,7 +120,7 @@ func main() {
|
||||
}
|
||||
})
|
||||
http.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
|
||||
// OK-ish: the input origin header is validated agains a whitelist.
|
||||
// OK-ish: the input origin header is validated against a whitelist.
|
||||
responseHeader := w.Header()
|
||||
{
|
||||
origin := req.Header.Get("origin")
|
||||
@@ -137,7 +137,7 @@ func main() {
|
||||
})
|
||||
http.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
|
||||
originSuffix := ".example.com"
|
||||
// OK-ish: the input origin header is validated agains a suffix.
|
||||
// OK-ish: the input origin header is validated against a suffix.
|
||||
origin := req.Header.Get("Origin")
|
||||
if origin != "" && (originSuffix == "" || strings.HasSuffix(origin, originSuffix)) {
|
||||
w.Header().Set("Access-Control-Allow-Origin", origin)
|
||||
@@ -152,7 +152,7 @@ func main() {
|
||||
})
|
||||
http.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
|
||||
originSuffix := ".example.com"
|
||||
// OK-ish: the input origin header is validated agains a whitelist.
|
||||
// OK-ish: the input origin header is validated against a whitelist.
|
||||
origin := req.Header.Get("Origin")
|
||||
if origin != "" && (originSuffix == "" || AccessControlAllowOrigins[origin]) {
|
||||
w.Header().Set("Access-Control-Allow-Origin", origin)
|
||||
@@ -166,7 +166,7 @@ func main() {
|
||||
}
|
||||
})
|
||||
http.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
|
||||
// OK-ish: the input origin header is validated agains a whitelist.
|
||||
// OK-ish: the input origin header is validated against a whitelist.
|
||||
origin := req.Header.Get("origin")
|
||||
if origin != "" && origin != "null" {
|
||||
if len(AccessControlAllowOrigins) == 0 || AccessControlAllowOrigins[origin] {
|
||||
@@ -178,7 +178,7 @@ func main() {
|
||||
}
|
||||
})
|
||||
// http.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
|
||||
// // OK-ish: the input origin header is validated agains a whitelist.
|
||||
// // OK-ish: the input origin header is validated against a whitelist.
|
||||
// origin := req.Header.Get("origin")
|
||||
// if origin != "" && origin != "null" {
|
||||
// if _, ok := AccessControlAllowOrigins[origin]; ok {
|
||||
@@ -190,7 +190,7 @@ func main() {
|
||||
// }
|
||||
// })
|
||||
http.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
|
||||
// OK-ish: the input origin header is validated agains a whitelist.
|
||||
// OK-ish: the input origin header is validated against a whitelist.
|
||||
if origin := req.Header.Get("Origin"); cors[origin] {
|
||||
w.Header().Set("Access-Control-Allow-Origin", origin)
|
||||
} else if len(origin) > 0 && cors["*"] {
|
||||
@@ -202,7 +202,7 @@ func main() {
|
||||
w.Header().Set("Access-Control-Allow-Credentials", "true")
|
||||
})
|
||||
http.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
|
||||
// OK-ish: the input origin header is validated agains a whitelist.
|
||||
// OK-ish: the input origin header is validated against a whitelist.
|
||||
origin := req.Header.Get("origin")
|
||||
for _, v := range GetAllowOrigin() {
|
||||
if v == origin {
|
||||
|
||||
@@ -96,7 +96,7 @@ func test() {
|
||||
http.HandleFunc("/ex5", func(w http.ResponseWriter, r *http.Request) {
|
||||
untrustedInput := r.Referer()
|
||||
|
||||
// good as input is tested againt regex
|
||||
// good as input is tested against regex
|
||||
if m, _ := regexp.MatchString("ws://localhost:12345/*", untrustedInput); m {
|
||||
nhooyr.Dial(context.TODO(), untrustedInput, nil)
|
||||
}
|
||||
|
||||
@@ -16,7 +16,7 @@ A bean definition is considered to be used if one or more of the following is tr
|
||||
<li>The bean is injected in to a constructor or method of a live bean due to autowiring. This includes
|
||||
autowiring by annotation (<code>@Autowired</code> or <code>@Inject</code>), and autowiring configured
|
||||
by the autowired attribute within bean configuration files.</li>
|
||||
<li>The bean is explictly loaded from a factory bean. It is not always possible to determine when
|
||||
<li>The bean is explicitly loaded from a factory bean. It is not always possible to determine when
|
||||
this occurs, because factory beans are loaded using a <code>String</code> value, which may contain
|
||||
arbitrary values.</li>
|
||||
<li>The bean is called reflectively by the Spring framework. For example, if the class is a Spring
|
||||
|
||||
@@ -62,7 +62,7 @@ runtime.
|
||||
<p>
|
||||
The code above should be rewritten to both use <code>volatile</code> and finish
|
||||
all initialization before <code>f</code> is updated. Additionally, a local
|
||||
variable can be used to avoid reading the field more times than neccessary.
|
||||
variable can be used to avoid reading the field more times than necessary.
|
||||
</p>
|
||||
<sample src="DoubleCheckedLockingGood.java"/>
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ For example: <code>PosixFilePermissions.asFileAttribute(EnumSet.of(PosixFilePerm
|
||||
</example>
|
||||
|
||||
<references>
|
||||
<li>OSWAP: <a href="https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File">Insecure Temporary File</a>.</li>
|
||||
<li>OWASP: <a href="https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File">Insecure Temporary File</a>.</li>
|
||||
<li>CERT: <a href="https://wiki.sei.cmu.edu/confluence/display/java/FIO00-J.+Do+not+operate+on+files+in+shared+directories">FIO00-J. Do not operate on files in shared directories</a>.</li>
|
||||
</references>
|
||||
</qhelp>
|
||||
@@ -26,7 +26,7 @@ Otherwise, a third-party application could impersonate the system this way to ca
|
||||
|
||||
<recommendation>
|
||||
<p>
|
||||
In the <code>onReceive</code> method of a <code>BroadcastReciever</code>, the action of the received Intent should be checked. The following code demonstrates this.
|
||||
In the <code>onReceive</code> method of a <code>BroadcastReceiver</code>, the action of the received Intent should be checked. The following code demonstrates this.
|
||||
</p>
|
||||
<sample src="Good.java" />
|
||||
</recommendation>
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
including invocation of methods available in the JVM.
|
||||
</p>
|
||||
<p>
|
||||
An unrestricted view name manipulation vulnerability in Spring Framework could lead to attacker-controlled arbitary SpEL expressions being evaluated using attacker-controlled data, which may in turn allow an attacker to run arbitrary code.
|
||||
An unrestricted view name manipulation vulnerability in Spring Framework could lead to attacker-controlled arbitrary SpEL expressions being evaluated using attacker-controlled data, which may in turn allow an attacker to run arbitrary code.
|
||||
</p>
|
||||
<p>
|
||||
Note: two related variants of this problem are detected by different queries, `java/spring-view-manipulation` and `java/spring-view-manipulation-implicit`. The first detects taint flow problems where the return types is always <code>String</code>. While the latter, `java/spring-view-manipulation-implicit` detects cases where the request mapping method has a non-string return type such as <code>void</code>.
|
||||
@@ -19,7 +19,7 @@
|
||||
<p>
|
||||
In general, using user input to determine Spring view name should be avoided.
|
||||
If user input must be included in the expression, the controller can be annotated by
|
||||
a <code>@ReponseBody</code> annotation. In this case, Spring Framework does not interpret
|
||||
a <code>@ResponseBody</code> annotation. In this case, Spring Framework does not interpret
|
||||
it as a view name, but just returns this string in HTTP Response. The same applies to using
|
||||
a <code>@RestController</code> annotation on a class, as internally it inherits <code>@ResponseBody</code>.
|
||||
</p>
|
||||
@@ -31,7 +31,7 @@
|
||||
</p>
|
||||
<sample src="SpringViewBad.java" />
|
||||
<p>
|
||||
This can be easily prevented by using the <code>ResponseBody</code> annotation which marks the reponse is already processed preventing exploitation of Spring View Manipulation vulnerabilities. Alternatively, this can also be fixed by adding a <code>HttpServletResponse</code> parameter to the method definition as shown in the example below.
|
||||
This can be easily prevented by using the <code>ResponseBody</code> annotation which marks the response is already processed preventing exploitation of Spring View Manipulation vulnerabilities. Alternatively, this can also be fixed by adding a <code>HttpServletResponse</code> parameter to the method definition as shown in the example below.
|
||||
</p>
|
||||
<sample src="SpringViewGood.java" />
|
||||
</example>
|
||||
|
||||
@@ -23,7 +23,7 @@ then revocation checking is not going to happen.</p>
|
||||
</overview>
|
||||
<recommendation>
|
||||
|
||||
<p>An application should not disable the default revocationg checking mechanism
|
||||
<p>An application should not disable the default revocation checking mechanism
|
||||
unless it provides a custom revocation checker.</p>
|
||||
|
||||
</recommendation>
|
||||
|
||||
@@ -3,14 +3,14 @@
|
||||
|
||||
<overview>
|
||||
<p>Transport Layer Security (TLS) provides a number of security features such as
|
||||
confidentiality, integrity, replay prevention and authenticatin.
|
||||
confidentiality, integrity, replay prevention and authentication.
|
||||
There are several versions of TLS protocols. The latest is TLS 1.3.
|
||||
Unfortunately, older versions were found to be vulnerable to a number of attacks.</p>
|
||||
|
||||
</overview>
|
||||
<recommendation>
|
||||
|
||||
<p>An application should use TLS 1.3. Currenlty, TLS 1.2 is also considered acceptable.</p>
|
||||
<p>An application should use TLS 1.3. Currently, TLS 1.2 is also considered acceptable.</p>
|
||||
|
||||
</recommendation>
|
||||
<example>
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
|
||||
<overview>
|
||||
<p>
|
||||
Allowing users to freely choose the name of a class to instantiate could provide means to attack a vulnerable appplication.
|
||||
Allowing users to freely choose the name of a class to instantiate could provide means to attack a vulnerable application.
|
||||
</p>
|
||||
</overview>
|
||||
|
||||
|
||||
@@ -50,7 +50,7 @@ whose methods use only primitive types and strings:
|
||||
<sample src="RmiSafeRemoteObject.java" />
|
||||
|
||||
<p>
|
||||
The next example shows how to set a deserilization filter for a remote object:
|
||||
The next example shows how to set a deserialization filter for a remote object:
|
||||
</p>
|
||||
<sample src="RmiRemoteObjectWithFilter.java" />
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
<overview>
|
||||
<p>For special use cases some applications may implement a custom service which handles JMX-RMI connections.</p>
|
||||
|
||||
<p>When creating such a custom service, a developer should pass a certain environment configuration to the JMX-RMI server initalisation,
|
||||
<p>When creating such a custom service, a developer should pass a certain environment configuration to the JMX-RMI server initialization,
|
||||
as otherwise the JMX-RMI service is susceptible to an unsafe deserialization vulnerability.</p>
|
||||
|
||||
<p>This is because the JMX-RMI service allows attackers to supply arbitrary objects to the service authentication
|
||||
@@ -41,11 +41,11 @@ For this reason an initialization with a <code>null</code> environment is also v
|
||||
|
||||
<p>The first example shows how an JMX server is initialized securely with the <code>JMXConnectorServerFactory.newJMXConnectorServer()</code> call.</p>
|
||||
|
||||
<sample src="CorrectJMXConnectorServerFactoryEnvironmentInitialisation.java" />
|
||||
<sample src="CorrectJMXConnectorServerFactoryEnvironmentInitialization.java" />
|
||||
|
||||
<p>The second example shows how a JMX Server is initialized securely if the <code>RMIConnectorServer</code> class is used.</p>
|
||||
|
||||
<sample src="CorrectRMIConnectorServerEnvironmentInitalisation.java" />
|
||||
<sample src="CorrectRMIConnectorServerEnvironmentInitialization.java" />
|
||||
|
||||
</example>
|
||||
|
||||
|
||||
@@ -46,7 +46,7 @@ public class UnsafeHostnameVerification {
|
||||
private void functionThatActuallyDisablesVerification() {
|
||||
HttpsURLConnection.setDefaultHostnameVerifier((name, s) -> true); // GOOD [but detected as BAD], because we only
|
||||
// check guards inside a function
|
||||
// and not accross function calls. This is considerer GOOD because the call to
|
||||
// and not across function calls. This is considerer GOOD because the call to
|
||||
// `functionThatActuallyDisablesVerification` is guarded by a feature flag in
|
||||
// `testGuardedByFlagAccrossCalls`.
|
||||
// Although this is not ideal as another function could directly call
|
||||
|
||||
@@ -161,7 +161,7 @@ private module PrintJavaScript {
|
||||
/**
|
||||
* A print node representing an `ASTNode`.
|
||||
*
|
||||
* Provides a default implemention that works for some (but not all) ASTNode's.
|
||||
* Provides a default implementation that works for some (but not all) ASTNode's.
|
||||
* More specific subclasses can override this class to get more specific behavior.
|
||||
*
|
||||
* The more specific subclasses are mostly used aggregate the children of the `ASTNode`.
|
||||
|
||||
@@ -671,7 +671,7 @@ module ClientRequest {
|
||||
}
|
||||
|
||||
/**
|
||||
* Gets the response type corresponding to `getReponse()` but not
|
||||
* Gets the response type corresponding to `getResponse()` but not
|
||||
* for explicitly typed calls like `getResponseJson()`.
|
||||
*/
|
||||
string getAssignedResponseType() {
|
||||
|
||||
@@ -7,7 +7,7 @@ import javascript
|
||||
/**
|
||||
* Provides classes implementing data-flow for Immutable.
|
||||
*
|
||||
* The implemention rely on the flowsteps implemented in `Collections.qll`.
|
||||
* The implementation rely on the flowsteps implemented in `Collections.qll`.
|
||||
*/
|
||||
private module Immutable {
|
||||
/**
|
||||
|
||||
@@ -123,7 +123,7 @@ No user-facing changes.
|
||||
|
||||
### New Queries
|
||||
|
||||
* A new query, `js/unsafe-code-construction`, has been added to the query suite, highlighting libraries that may leave clients vulnerable to arbitary code execution.
|
||||
* A new query, `js/unsafe-code-construction`, has been added to the query suite, highlighting libraries that may leave clients vulnerable to arbitrary code execution.
|
||||
The query is not run by default.
|
||||
* A new query `js/file-system-race` has been added. The query detects when there is time between a file being checked and used. The query is not run by default.
|
||||
* A new query `js/jwt-missing-verification` has been added. The query detects applications that don't verify JWT tokens.
|
||||
|
||||
@@ -40,7 +40,7 @@ From context, it appears that the second binding should have been for variable <
|
||||
<sample src="examples/NonLinearPatternGood.js" />
|
||||
|
||||
<p>
|
||||
This can sometimes happen in TypeScript, due to the apparant similarity between property patterns
|
||||
This can sometimes happen in TypeScript, due to the apparent similarity between property patterns
|
||||
and type annotations. In the following example, the function uses a pattern parameter with properties <code>x</code>
|
||||
and <code>y</code>. These appear to have type <code>number</code>, but are in fact untyped properties both stored in a variable named <code>number</code>.
|
||||
</p>
|
||||
|
||||
@@ -33,7 +33,7 @@ selector to determine which element should be manipulated.
|
||||
<p>
|
||||
However, if an attacker can control the <code>data-target</code> attribute,
|
||||
then the value of <code>target</code> can be used to cause the <code>$</code> function
|
||||
to execute arbitary JavaScript.
|
||||
to execute arbitrary JavaScript.
|
||||
</p>
|
||||
<p>
|
||||
The above vulnerability can be fixed by using <code>$.find</code> instead of <code>$</code>.
|
||||
|
||||
@@ -23,7 +23,7 @@
|
||||
</p>
|
||||
<p>
|
||||
It is also recommended to limit the permissions of any tokens used
|
||||
by a workflow such as the the GITHUB_TOKEN.
|
||||
by a workflow such as the GITHUB_TOKEN.
|
||||
</p>
|
||||
</recommendation>
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
<qhelp>
|
||||
<overview>
|
||||
<p>
|
||||
Downloading executeables or other sensitive files over an unencrypted connection
|
||||
Downloading executables or other sensitive files over an unencrypted connection
|
||||
can leave a server open to man-in-the-middle attacks (MITM).
|
||||
Such an attack can allow an attacker to insert arbitrary content
|
||||
into the downloaded file, and in the worst case, allow the attacker to execute
|
||||
|
||||
@@ -17,7 +17,7 @@ longer needed, remove it.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If the check is needed to guard against <code>NaN</code> values, insert a comment explaning the possibility of <code>NaN</code>.
|
||||
If the check is needed to guard against <code>NaN</code> values, insert a comment explaining the possibility of <code>NaN</code>.
|
||||
</p>
|
||||
|
||||
</recommendation>
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
### New Queries
|
||||
|
||||
* A new query, `js/unsafe-code-construction`, has been added to the query suite, highlighting libraries that may leave clients vulnerable to arbitary code execution.
|
||||
* A new query, `js/unsafe-code-construction`, has been added to the query suite, highlighting libraries that may leave clients vulnerable to arbitrary code execution.
|
||||
The query is not run by default.
|
||||
* A new query `js/file-system-race` has been added. The query detects when there is time between a file being checked and used. The query is not run by default.
|
||||
* A new query `js/jwt-missing-verification` has been added. The query detects applications that don't verify JWT tokens.
|
||||
|
||||
@@ -38,7 +38,7 @@ default parser</a> from <code>lxml.etree</code> allows local external entities t
|
||||
<p>
|
||||
To guard against XXE attacks with the <code>lxml</code> library, you should create a
|
||||
parser with <code>resolve_entities</code> set to <code>false</code>. This means that no
|
||||
entity expansion is undertaken, althuogh standard predefined entities such as
|
||||
entity expansion is undertaken, although standard predefined entities such as
|
||||
<code>&gt;</code>, for writing <code>></code> inside the text of an XML element,
|
||||
are still allowed.
|
||||
</p>
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
<recommendation>
|
||||
<p>
|
||||
This vulnerability can be prevented by not allowing untrusted user input to be passed as an XSL stylesheet.
|
||||
If the application logic necessiates processing untrusted XSL stylesheets, the input should be properly filtered and sanitized before use.
|
||||
If the application logic necessitates processing untrusted XSL stylesheets, the input should be properly filtered and sanitized before use.
|
||||
</p>
|
||||
</recommendation>
|
||||
<example>
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
import sys
|
||||
import random
|
||||
|
||||
# hmm, annoying that you have to keep names unique accross files :|
|
||||
# hmm, annoying that you have to keep names unique across files :|
|
||||
# since I like to use foo and bar ALL the time :D
|
||||
|
||||
# name:rd_foo
|
||||
|
||||
@@ -30,7 +30,7 @@ subpaths
|
||||
#select
|
||||
| test.py:22:10:22:24 | ControlFlowNode for Attribute() | test.py:21:11:21:18 | ControlFlowNode for source() | test.py:22:10:22:24 | ControlFlowNode for Attribute() | test flow (naive): test_simple |
|
||||
| test.py:33:10:33:12 | ControlFlowNode for val | test.py:29:11:29:18 | ControlFlowNode for source() | test.py:33:10:33:12 | ControlFlowNode for val | test flow (naive): test_alias |
|
||||
| test.py:41:10:41:12 | ControlFlowNode for val | test.py:45:11:45:18 | ControlFlowNode for source() | test.py:41:10:41:12 | ControlFlowNode for val | test flow (naive): test_accross_functions |
|
||||
| test.py:41:10:41:12 | ControlFlowNode for val | test.py:45:11:45:18 | ControlFlowNode for source() | test.py:41:10:41:12 | ControlFlowNode for val | test flow (naive): test_across_functions |
|
||||
| test.py:54:10:54:12 | ControlFlowNode for val | test.py:70:11:70:18 | ControlFlowNode for source() | test.py:54:10:54:12 | ControlFlowNode for val | test flow (naive): test_deeply_nested |
|
||||
| test.py:79:10:79:12 | ControlFlowNode for val | test.py:83:11:83:18 | ControlFlowNode for source() | test.py:79:10:79:12 | ControlFlowNode for val | test flow (naive): test_pass_bound_method |
|
||||
| test.py:91:10:91:12 | ControlFlowNode for val | test.py:107:11:107:18 | ControlFlowNode for source() | test.py:91:10:91:12 | ControlFlowNode for val | test flow (naive): test_deeply_nested_bound_method |
|
||||
|
||||
@@ -70,7 +70,7 @@ subpaths
|
||||
#select
|
||||
| test.py:22:10:22:24 | ControlFlowNode for Attribute() | test.py:21:11:21:18 | ControlFlowNode for source() | test.py:22:10:22:24 | ControlFlowNode for Attribute() | test flow (proper): test_simple |
|
||||
| test.py:33:10:33:12 | ControlFlowNode for val | test.py:29:11:29:18 | ControlFlowNode for source() | test.py:33:10:33:12 | ControlFlowNode for val | test flow (proper): test_alias |
|
||||
| test.py:41:10:41:12 | ControlFlowNode for val | test.py:45:11:45:18 | ControlFlowNode for source() | test.py:41:10:41:12 | ControlFlowNode for val | test flow (proper): test_accross_functions |
|
||||
| test.py:41:10:41:12 | ControlFlowNode for val | test.py:45:11:45:18 | ControlFlowNode for source() | test.py:41:10:41:12 | ControlFlowNode for val | test flow (proper): test_across_functions |
|
||||
| test.py:54:10:54:12 | ControlFlowNode for val | test.py:70:11:70:18 | ControlFlowNode for source() | test.py:54:10:54:12 | ControlFlowNode for val | test flow (proper): test_deeply_nested |
|
||||
| test.py:79:10:79:12 | ControlFlowNode for val | test.py:83:11:83:18 | ControlFlowNode for source() | test.py:79:10:79:12 | ControlFlowNode for val | test flow (proper): test_pass_bound_method |
|
||||
| test.py:91:10:91:12 | ControlFlowNode for val | test.py:107:11:107:18 | ControlFlowNode for source() | test.py:91:10:91:12 | ControlFlowNode for val | test flow (proper): test_deeply_nested_bound_method |
|
||||
|
||||
@@ -41,7 +41,7 @@ def sink_func(arg):
|
||||
sink(val)
|
||||
|
||||
|
||||
def test_accross_functions():
|
||||
def test_across_functions():
|
||||
src = source()
|
||||
sink_func(src)
|
||||
|
||||
|
||||
@@ -119,7 +119,7 @@
|
||||
### New Queries
|
||||
|
||||
* A new query (`rb/request-forgery`) has been added. The query finds HTTP requests made with user-controlled URLs.
|
||||
* A new query (`rb/csrf-protection-disabled`) has been added. The query finds cases where cross-site forgery protection is explictly disabled.
|
||||
* A new query (`rb/csrf-protection-disabled`) has been added. The query finds cases where cross-site forgery protection is explicitly disabled.
|
||||
|
||||
### Query Metadata Changes
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
### New Queries
|
||||
|
||||
* A new query (`rb/request-forgery`) has been added. The query finds HTTP requests made with user-controlled URLs.
|
||||
* A new query (`rb/csrf-protection-disabled`) has been added. The query finds cases where cross-site forgery protection is explictly disabled.
|
||||
* A new query (`rb/csrf-protection-disabled`) has been added. The query finds cases where cross-site forgery protection is explicitly disabled.
|
||||
|
||||
### Query Metadata Changes
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ to execute arbitrary code.
|
||||
<recommendation>
|
||||
<p>
|
||||
Avoid deserialization of untrusted data if possible. If the architecture permits
|
||||
it, use serialization formats that cannot represent arbitarary objects. For
|
||||
it, use serialization formats that cannot represent arbitrary objects. For
|
||||
libraries that support it, such as the Ruby standard library's <code>JSON</code>
|
||||
module, ensure that the parser is configured to disable
|
||||
deserialization of arbitrary objects.
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
<qhelp>
|
||||
<overview>
|
||||
<p>
|
||||
Downloading executeables or other sensitive files over an unencrypted connection
|
||||
Downloading executables or other sensitive files over an unencrypted connection
|
||||
can leave a server open to man-in-the-middle attacks (MITM).
|
||||
Such an attack can allow an attacker to insert arbitrary content
|
||||
into the downloaded file, and in the worst case, allow the attacker to execute
|
||||
|
||||
Reference in New Issue
Block a user