Kingdom: Code Quality

Poor code quality leads to unpredictable behavior. From a user's perspective that often manifests itself as poor usability. For an attacker it provides an opportunity to stress the system in unexpected ways.

96 items found
Weaknesses
Abstract
The application invokes internal or hidden APIs.
Explanation
It is not recommended that developers build their apps using undocumented, or hidden, APIs. There are no guarantees that Google will not remove or change those APIs in the future and therefore they should be avoided therefore using such methods or fields has a high risk of breaking your app.
References
[1] Google Restrictions on non-SDK interfaces
[2] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
desc.structural.cpp.android_bad_practices_use_of_internal_apis
Abstract
The application invokes internal or hidden APIs.
Explanation
It is not recommended that developers build their apps using undocumented, or hidden, APIs. There are no guarantees that Google will not remove or change those APIs in the future and therefore they should be avoided therefore using such methods or fields has a high risk of breaking your app.
References
[1] Google Restrictions on non-SDK interfaces
[2] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
desc.structural.java.android_bad_practices_use_of_internal_apis
Abstract
The code references the Camera object after it has already been released.
Explanation
The code attempts to use the Camera object after the it has already been released. Any further references to the Camera object without reacquiring the resource will throw an exception, and can cause the application to crash if the exception is not caught.

Example: The following code uses a toggle button to toggle the camera preview on and off. After the user taps the button once, the camera preview stops and the camera resource is released. However, if she taps the button again, startPreview() is called on the previously-released Camera object.


public class ReuseCameraActivity extends Activity {
private Camera cam;

...
private class CameraButtonListener implements OnClickListener {
public void onClick(View v) {
if (toggle) {
cam.stopPreview();
cam.release();
}
else {
cam.startPreview();
}
toggle = !toggle;
}
}
...
}
References
[1] Camera, Android Developers
[2] Standards Mapping - Common Weakness Enumeration CWE ID 416
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [7] CWE ID 416
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [8] CWE ID 416
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [7] CWE ID 416
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [7] CWE ID 416
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [4] CWE ID 416
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[13] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[45] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.android_bad_practices_use_of_released_camera_resource
Abstract
The code references the Android media object after it has already been released.
Explanation
The code attempts to use the media object after the it has already been released. Any further references to that media object without reacquiring the resource will throw an exception, and can cause the application to crash if the exception is not caught.

Example: The following code uses a pause button to toggle the media playback. After the user taps the button once, the current song or video is paused and the camera resource is released. However, if she taps the button again, start() is called on the previously-released media resource.


public class ReuseMediaPlayerActivity extends Activity {
private MediaPlayer mp;

...
private class PauseButtonListener implements OnClickListener {
public void onClick(View v) {
if (paused) {
mp.pause();
mp.release();
}
else {
mp.start();
}
paused = !paused;
}
}
...
}
References
[1] Media Player, Android Developers
[2] Audio Capture, Android Developers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 416
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [7] CWE ID 416
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [8] CWE ID 416
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [7] CWE ID 416
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [7] CWE ID 416
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [4] CWE ID 416
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[14] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[24] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[46] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.android_bad_practices_use_of_released_media_resource
Abstract
The code references the Android database handler after it has already been released.
Explanation
The code attempts to use the Android SQLite database handler after the it has already been closed. Any further references to the handler without re-establishing the database connection will throw an exception, and can cause the application to crash if the exception is not caught.

Example: The following code might be from a program that caches user values temporarily in memory, but can call flushUpdates() to commit the changes to disk. The method properly closes the database handler after writing updates to the database. However, when flushUpdates() is called again, the database object is referenced again before reinitializing it.


public class ReuseDBActivity extends Activity {
private myDBHelper dbHelper;
private SQLiteDatabase db;

@Override
public void onCreate(Bundle state) {
...
db = dbHelper.getWritableDatabase();
...
}
...

private void flushUpdates() {
db.insert(cached_data); // flush cached data
dbHelper.close();
}
...
}
References
[1] Data Storage, Android Developers
[2] Standards Mapping - Common Weakness Enumeration CWE ID 416
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [7] CWE ID 416
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [8] CWE ID 416
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [7] CWE ID 416
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [7] CWE ID 416
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [4] CWE ID 416
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[13] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[45] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.android_bad_practices_use_of_released_sqlite_resource
Abstract
Unminified JavaScript has been included in this file. Microsoft recommends that minified versions of JavaScript libraries should be included for performance reasons.
Explanation
Minification improves page load times for applications that include JavaScript files by reducing the file size. Minification refers to the process of removing unnecessary whitespace, comments, semicolons, braces, shortening the names of local variables and removing unreachable code.

Example 1: The following ASPX code includes the unminified version of Microsoft's jQuery library:


...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...
References
[1] Optimizations for Improving Load Times Microsoft
[2] Introduction to CSS Minification Microsoft
[3] Microsoft AJAX Minifier Microsoft
[4] Standards Mapping - FIPS200 SI
[5] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[6] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[7] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[8] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[9] Standards Mapping - OWASP Top 10 2010 A1 Injection
[10] Standards Mapping - OWASP Top 10 2013 A1 Injection
[11] Standards Mapping - OWASP Top 10 2017 A1 Injection
[12] Standards Mapping - OWASP Top 10 2021 A03 Injection
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[14] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 098
[15] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3600 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3600 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3600 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3600 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3600 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3600 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3600 CAT II
desc.semantic.dotnet.asp_net_bad_practices_unminified_code
Abstract
The program uses an arithmetic operator on a boolean value, which might not achieve what the programmer had in mind.
Explanation
Arithmetic operations will not act in the same way on boolean values as they would on integral values, which may lead to unexpected behavior.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 398
[2] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 13.4, Rule 14.4
[3] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 5-0-13, Rule 6-2-1
[4] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[5] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[9] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[10] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[11] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
desc.structural.cpp.code_correctness_arithmetic_operation_on_boolean
Abstract
Converting a byte array into a String may lead to data loss.
Explanation
When data from a byte array is converted into a String, it is unspecified what will happen to any data that is outside of the applicable character set. This can lead to data being lost, or a decrease in the level of security when binary data is needed to ensure proper security measures are followed.

Example 1: The following code converts data into a String in order to create a hash.


...
FileInputStream fis = new FileInputStream(myFile);
byte[] byteArr = byte[BUFSIZE];
...
int count = fis.read(byteArr);
...
String fileString = new String(byteArr);
String fileSHA256Hex = DigestUtils.sha256Hex(fileString);
// use fileSHA256Hex to validate file
...


Assuming the size of the file is less than BUFSIZE, this works fine as long as the information in myFile is encoded the same as the default character set, however if it's using a different encoding, or is a binary file, it will lose information. This in turn will cause the resulting SHA hash to be less reliable, and could mean it's far easier to cause collisions, especially if any data outside of the default character set is represented by the same value, such as a question mark.
References
[1] STR03-J. Do not encode noncharacter data as a string CERT
[2] When 'EFBFBD' and Friends Come Knocking: Observations of Byte Array to String Conversions GDS Security
[3] Standards Mapping - Common Weakness Enumeration CWE ID 486
desc.semantic.java.code_correctness_byte_array_to_string_conversion
Abstract
It is ambiguous which thread will wake up when notify() is called.
Explanation
There is no way to specify which thread will be awakened by calls to notify().

Example 1: In the following code, notifyJob() calls notify().

public synchronized notifyJob() {
flag = true;
notify();
}
...
public synchronized waitForSomething() {
while(!flag) {
try {
wait();
}
catch (InterruptedException e)
{
...
}
}
...
}

In this case, the developer intends to wake up the thread that calls wait(), but it is possible that notify() will notify a different thread than the intended one.
References
[1] Sun Microsystems, Inc. Java Sun Tutorial - Concurrency
[2] Sun Microsystems, Inc. Java Sun Tutorial - Concurrency
[3] THI02-J. Notify all waiting threads rather than a single thread CERT
[4] Standards Mapping - Common Weakness Enumeration CWE ID 373
desc.structural.java.code_correctness_call_to_notify
Abstract
The program calls a thread's run() method instead of calling start().
Explanation
In most cases a direct call to a Thread object's run() method is a bug. The programmer intended to begin a new thread of control, but accidentally called run() instead of start(), so the run() method will execute in the caller's thread of control.

Example 1: The following excerpt from a Java program mistakenly calls run() instead of start().


Thread thr = new Thread() {
public void run() {
...
}
};

thr.run();
References
[1] THI00-J. Do not invoke Thread.run() CERT
[2] Standards Mapping - Common Weakness Enumeration CWE ID 572
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[6] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[8] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[9] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[29] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[30] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.structural.java.code_correctness_call_to_thread_run
Abstract
The program calls a thread's stop() method, potentially leaking resources.
Explanation
In most cases a direct call to a Thread object's stop() method is a bug. The programmer intended to stop a thread from running, but was unaware that this is not a suitable way to stop a thread. The stop() function within Thread causes a ThreadDeath exception anywhere within the Thread object, likely leaving objects in an inconsistent state and potentially leaking resources. Due to this API being inherently unsafe, its use was deprecated long ago.

Example 1: The following excerpt from a Java program mistakenly calls Thread.stop().


...
public static void main(String[] args){
...
Thread thr = new Thread() {
public void run() {
...
}
};
...
thr.start();
...
thr.stop();
...
}
References
[1] THI05-J. Do not use Thread.stop() to terminate threads CERT
[2] Why are Thread.stop, Thread.suspend, Thread.resume and Runtime.runFinalizersOnExit Deprecated? Oracle
[3] Standards Mapping - Common Weakness Enumeration CWE ID 572
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[7] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[9] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[30] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[31] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.semantic.java.code_correctness_call_to_thread_stop
Abstract
This class implements a clone() method but does not implement the Cloneable interface.
Explanation
It appears that the programmer intended for this class to implement the Cloneable interface because it implements a method named clone(). However, the class does not implement the Cloneable interface and the clone() method will not behave correctly.

Example 1: Calling clone() for this class will result in a CloneNotSupportedException.

public class Kibitzer {
public Object clone() throws CloneNotSupportedException {
...
}
}

References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 498
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[5] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[7] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[8] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[9] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[28] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[29] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.structural.java.code_correctness_class_does_not_implement_cloneable
Abstract
The ICloneable interface specifies a weak contract for its Clone method and should be avoided.
Explanation
The ICloneable interface does not guarantee deep cloning, classes that implement it may not behave as expected when they are cloned. Classes that implement ICloneable and perform only shallow-cloning (copies only the object, which includes existing references to other objects) may result in unexpected behavior. Because deep-cloning (copies the object and all referenced objects) is typically the assumed behavior of a clone method, the use of the ICloneable interface is error prone and should be avoided.
References
[1] Krzysztof Cwalina, Brad Abrams Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries. Chapter 8: Usage Guidelines Addison-Wesley
[2] Standards Mapping - Common Weakness Enumeration CWE ID 398
desc.structural.dotnet.code_correctness_class_implements_icloneable
Abstract
The clone() method within the class calls a function that can be overridden.
Explanation
When a clone() function calls an overridable function, it may cause the clone to be left in a partially initialized state, or become corrupted.

Example 1: The following clone() function calls a method that can be overridden.


...
class User implements Cloneable {
private String username;
private boolean valid;
public Object clone() throws CloneNotSupportedException {
final User clone = (User) super.clone();
clone.doSomething();
return clone;
}
public void doSomething(){
...
}
}


Since the function doSomething() and its enclosing class are not final, it means that the function can be overridden, which may leave the cloned object clone in a partially initialized state, which may lead to errors, if not working around logic in an unexpected way.
References
[1] MET06-J. Do not invoke overridable methods in clone() CERT
[2] EXTEND-5: Limit the extensibility of classes and methods Oracle
desc.structural.java.code_correctness_clone_invokes_overridable_function
Abstract
Comparing boxed primitives using equality operators instead of their equals() method can result in unexpected behavior.
Explanation
When dealing with boxed primitives, when comparing equality, the boxed primitive's equals() method should be called instead of the operators == and !=. The Java Specification states about boxing conversions:

"If the value p being boxed is an integer literal of type int between -128 and 127 inclusive, or the boolean literal true or false, or a character literal between '\u0000' and '\u007f' inclusive, then let a and b be the results of any two boxing conversions of p. It is always the case that a == b."

This means that if a boxed primitive is used (other than Boolean or Byte), only a range of values will be cached, or memoized. For a subset of values, using == or != will return the correct value, for all other values outside of this subset, this will return the result of comparing the object addresses.

Example 1: The following example uses equality operators on boxed primitives.


...
Integer mask0 = 100;
Integer mask1 = 100;
...
if (file0.readWriteAllPerms){
mask0 = 777;
}
if (file1.readWriteAllPerms){
mask1 = 777;
}
...
if (mask0 == mask1){
//assume file0 and file1 have same permissions
...
}
...


The code in Example 1 uses Integer boxed primitives to try to compare two int values. If mask0 and mask1 are both equal to 100, then mask0 == mask1 will return true. However, when mask0 and mask1 are both equal to 777, now mask0 == maske1 will return false as these values are not within the range of cached values for these boxed primitives.
References
[1] EXP03-J. Do not use the equality operators when comparing values of boxed primitives CERT
[2] Java Language Specification Chapter 5. Conversions and Contexts Oracle
[3] Standards Mapping - Common Weakness Enumeration CWE ID 398, CWE ID 754
[4] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)
[5] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 754
desc.structural.java.code_correctness_comparison_of_boxed_primitive_types
Abstract
Making a comparison with NaN is always an error.
Explanation
When a comparison is made to NaN it is always evaluated as false, except for the != operator, which always evaluates to true since NaN is unordered.

Example 1: The following tries to make sure a variable is not NaN.


...
if (result == Double.NaN){
//something went wrong
throw new RuntimeException("Something went wrong, NaN found");
}
...


This attempts to verify that result is not NaN, however using the operator == with NaN always results in a value of false, so this check will never throw the exception.
References
[1] NUM07-J. Do not attempt comparisons with NaN CERT
[2] Java Language Specification Chapter 4. Types, Values, and Variables Oracle
[3] INJECT-9: Prevent injection of exceptional floating point values Oracle
[4] Standards Mapping - Common Weakness Enumeration CWE ID 486
desc.structural.java.code_correctness_comparison_with_nan
Abstract
A constructor of the class calls a function that can be overridden.
Explanation
When a constructor calls an overridable function, it may allow an attacker to access the this reference prior to the object being fully initialized, which can in turn lead to a vulnerability.

Example 1: The following calls a method that can be overridden.


...
class User {
private String username;
private boolean valid;
public User(String username, String password){
this.username = username;
this.valid = validateUser(username, password);
}
public boolean validateUser(String username, String password){
//validate user is real and can authenticate
...
}
public final boolean isValid(){
return valid;
}
}


Since the function validateUser and the class are not final, it means that they can be overridden, and then initializing a variable to the subclass that overrides this function would allow bypassing of the validateUser functionality. For example:


...
class Attacker extends User{
public Attacker(String username, String password){
super(username, password);
}
public boolean validateUser(String username, String password){
return true;
}
}
...
class MainClass{
public static void main(String[] args){
User hacker = new Attacker("Evil", "Hacker");
if (hacker.isValid()){
System.out.println("Attack successful!");
}else{
System.out.println("Attack failed");
}
}
}


The code in Example 1 prints "Attack successful!", since the Attacker class overrides the validateUser() function that is called from the constructor of the superclass User, and Java will first look in the subclass for functions called from the constructor.
References
[1] MET05-J. Ensure that constructors do not call overridable methods CERT
[2] EXTEND-5: Limit the extensibility of classes and methods Oracle
[3] OBJECT-4: Prevent constructors from calling methods that can be overridden Oracle
desc.structural.java.code_correctness_constructor_invokes_overridable_function
Abstract
Determining an object's type based on its class name can lead to unexpected behavior or allow an attacker to inject a malicious class.
Explanation
Attackers can deliberately duplicate class names in order to cause a program to execute malicious code. For this reason, class names are not good type identifiers and should not be used as the basis for granting trust to a given object.

Example 1: The following code determines whether to trust input from an inputReader object based on its class name. If an attacker can supply an implementation of inputReader that executes malicious commands, this code cannot differentiate the benign and malicious versions of the object.


if (inputReader.GetType().FullName == "CompanyX.Transaction.Monetary")
{
processTransaction(inputReader);
}
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 486
desc.dataflow.dotnet.code_correctness_erroneous_class_compare
Abstract
Determining an object's type based on its class name can lead to unexpected behavior or allow an attacker to inject a malicious class.
Explanation
Attackers can deliberately duplicate class names in order to cause a program to execute malicious code. For this reason, class names are not good type identifiers and should not be used as the basis for granting trust to a given object.

Example 1: The following code determines whether to trust input from an inputReader object based on its class name. If an attacker can supply an implementation of inputReader that executes malicious commands, this code cannot differentiate the benign and malicious versions of the object.


if (inputReader.getClass().getName().equals("com.example.TrustedClass")) {
input = inputReader.getInput();
...
}
References
[1] OBJ09-J. Compare classes and not class names CERT
[2] Standards Mapping - Common Weakness Enumeration CWE ID 486
desc.dataflow.java.code_correctness_erroneous_class_compare
Abstract
Determining an object's type based on its class name can lead to unexpected behavior or allow an attacker to inject a malicious class.
Explanation
Attackers can deliberately duplicate class names in order to cause a program to execute malicious code. For this reason, class names are not good type identifiers and should not be used as the basis for granting trust to a given object.

Example 1: The following code determines whether to trust input from an inputReader object based on its class name. If an attacker can supply an implementation of inputReader that executes malicious commands, this code cannot differentiate the benign and malicious versions of the object.


if (inputReader::class.qualifiedName == "com.example.TrustedClass") {
input = inputReader.getInput()
...
}
References
[1] OBJ09-J. Compare classes and not class names CERT
[2] Standards Mapping - Common Weakness Enumeration CWE ID 486
desc.dataflow.kotlin.code_correctness_erroneous_class_compare
Abstract
A field is erroneously assigned a negative value.
Explanation
This field has been annotated with FortifyNonNegative, which is used to indicate that negative values are not permitted.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 20
[2] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[3] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[5] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3)
[6] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 020
desc.structural.java.erroneous_negative_value_field
Abstract
The expressions x = NULL and x != NULL will always be false.
Explanation
In PL/SQL, the value of NULL is indeterminate. It is not equal to anything, not even another NULL value. Also, a null value is never not equal to another value.

Example 1: The following statement will always be false.


checkNull BOOLEAN := x = NULL;
Example 2: The following statement will always be false.


checkNotNull BOOLEAN := x != NULL;
References
[1] Steven Feuerstein Oracle PL/SQL Best Practices O'Reilly
[2] Standards Mapping - Common Weakness Enumeration CWE ID 480
desc.structural.sql.code_correctness_erroneous_null_comparison_plsql
Abstract
Strings should be compared with the equals() method, not == or !=.
Explanation
This program uses == or != to compare two strings for equality, which compares two objects for equality, not their values. Chances are good that the two references will never be equal.

Example 1: The following branch will never be taken.


if (args[0] == STRING_CONSTANT) {
logger.info("miracle");
}


The == and != operators will only behave as expected when they are used to compare strings contained in objects that are equal. The most common way for this to occur is for the strings to be interned, whereby the strings are added to a pool of objects maintained by the String class. Once a string is interned, all uses of that string will use the same object and equality operators will behave as expected. All string literals and string-valued constants are interned automatically. Other strings can be interned manually be calling String.intern(), which will return a canonical instance of the current string, creating one if necessary.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 597
desc.structural.java.code_correctness_erroneous_string_compare