45 items found
Weaknesses
Abstract
The application reflects a user-controllable parameter as the JavaScript callback function to be executed by the browser that might enable an attacker to execute arbitrary JavaScript functions on any pages on the same endpoint's domain.
Explanation
The application uses a parameter under the attacker's control as the name of a JavaScript function that the browser will execute. An attacker may create a malicious site which first frames a target page on the same application's domain and then references the vulnerable page in order to execute an arbitrary JavaScript function on the target page. The impact of this attack is similar to the impact of Cross-Site Scripting, though there are some important exploitation restrictions. If alphanumeric and dot characters are allowed to be used as the callback name, the attacker will be able to reference and interact with the elements of the page.

Example 1: The following code constructs a JSONP response where the callback function name can be controlled by the user.


@ControllerAdvice
public class JsonpAdvice extends AbstractJsonpResponseBodyAdvice {
public JsonpAdvice() {
super("callback");
}
}


For a request such as GET /api/latest.json?callback=myCallbackFunction, the controller method will generate a response such as:


HTTP/1.1 200 Ok
Content-Type: application/json; charset=utf-8
Date: Tue, 12 Dec 2017 16:16:04 GMT
Server: nginx/1.12.1
Content-Length: 225
Connection: Close

myCallbackFunction({<json>})


The attacker can use a JavaScript Script tag to load the response from the JSONP endpoint, which will turn into the execution of the myCallbackFunction function. An attacker could use a different callback name to navigate and interact with the DOM. For example opener.document.body.someElemnt.firstChild.nextElementSibling.submit could be used to locate a form in the target page and submit it.
References
[1] Ben Hayak Same Origin Method Execution (SOME)
desc.semantic.java.same_origin_method_execution
Abstract
The application reflects a user-controllable parameter as the JavaScript callback function to be executed by the browser that might enable an attacker to execute arbitrary JavaScript functions on any pages on the same endpoint's domain.
Explanation
The application uses a parameter under the attacker's control as the name of a JavaScript function that the browser will execute. An attacker may create a malicious site which first frames a target page on the same application's domain and then references the vulnerable page in order to execute an arbitrary JavaScript function on the target page. The impact of this attack is similar to the impact of Cross-Site Scripting, though there are some important exploitation restrictions. If alphanumeric and dot characters are allowed to be used as the callback name, the attacker will be able to reference and interact with the elements of the page.

Example 1: The following code constructs a JSONP response where the callback function name can be controlled by the user.


def myJSONPService(callback: String) = Action {
val json = getJSONToBeReturned()
Ok(Jsonp(callback, json))
}


For a request such as GET /api/latest.json?callback=myCallbackFunction, the controller method described in Example 1 will generate a response such as:


HTTP/1.1 200 Ok
Content-Type: application/json; charset=utf-8
Date: Tue, 12 Dec 2017 16:16:04 GMT
Server: nginx/1.12.1
Content-Length: 225
Connection: Close

myCallbackFunction({<json>})


The attacker can use a JavaScript Script tag to load the response from the JSONP endpoint, which will turn into the execution of the myCallbackFunction function. An attacker could use a different callback name to navigate and interact with the DOM. For example opener.document.body.someElemnt.firstChild.nextElementSibling.submit could be used to locate a form in the target page and submit it.
References
[1] Ben Hayak Same Origin Method Execution (SOME)
desc.dataflow.scala.same_origin_method_execution
Abstract
The application initiates a network connection to a third-party system using user-controlled data to craft the resource URI.
Explanation
A Server-Side Request Forgery occurs when an attacker can influence a network connection made by the application server. The network connection will originate from the application server's internal IP and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example 1: In the following example, an attacker can control the URL to which the server is connecting.


...
PageReference ref = ApexPages.currentPage();
Map<String,String> params = ref.getParameters();
HttpRequest req = new HttpRequest();
req.setEndpoint(params.get('url'));
HTTPResponse res = new Http().send(req);


The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https such as:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following types of attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Perform a DNS cache poisoning attack.

desc.dataflow.apex.server_side_request_forgery
Abstract
The application initiates a network connection to a third-party system using user-controlled data to craft the resource URI.
Explanation
A Server-Side Request Forgery occurs when an attacker can influence a network connection made by the application server. The network connection will originate from the application server's internal IP and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example: In the following example, an attacker can control the URL to which the server is connecting.


string url = Request.Form["url"];
HttpClient client = new HttpClient();
HttpResponseMessage response = await client.GetAsync(url);


The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https like:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- On Windows systems, file:// scheme and UNC paths can allow an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.

References
[1] Alexander Polyakov SSRF vs. Business critical applications BlackHat 2012
[2] SSRF bible. Cheatsheet ONSec Labs
desc.dataflow.dotnet.server_side_request_forgery
Abstract
The application initiates a network connection to a third-party system using user-controlled data to craft the resource URI.
Explanation
A Server-Side Request Forgery occurs when an attacker can influence a network connection made by the application server. The network connection will originate from the application server's internal IP and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example: In the following example, an attacker can control the URL to which the server is connecting.


char *url = maliciousInput();
CURL *curl = curl_easy_init();
curl_easy_setopt(curl, CURLOPT_URL, url);
CURLcode res = curl_easy_perform(curl);


An attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https such as:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using the file:// scheme.
- On Windows systems, using the file:// scheme and UNC paths can enable an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.

desc.dataflow.cpp.server_side_request_forgery
Abstract
The application initiates a network connection to a third-party system using user-controlled data to craft the resource URI.
Explanation
A Server-Side Request Forgery occurs when an attacker can influence a network connection made by the application server. The network connection originates from the application server's internal IP and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example: In the following example, an attacker can control the URL to which the server is connecting.


...
final server = await HttpServer.bind('localhost', 18081);
server.listen((request) async {
final headers = request.headers;
final url = headers.value('url');
final client = IOClient();
final response = await client.get(Uri.parse(url!));
...
}


The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https such as:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- On Windows systems, file:// scheme and UNC paths can allow an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.

desc.dataflow.dart.server_side_request_forgery
Abstract
The application initiates a network connection to a third-party system using user-controlled data to craft the resource URI.
Explanation
A Server-Side Request Forgery occurs when an attacker might influence a network connection made by the application server. The network connection originates from the application server's internal IP address and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example: In the following example, an attacker can control the URL the server is connecting to.


url := request.Form.Get("url")
res, err =: http.Get(url)
...


The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and the libraries used to establish the connection. For example, controlling the URI scheme enables the attacker to use protocols different from http or https like:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- Scan and access internal shares on Windows systems with file:// scheme and UNC paths.
- Perform a DNS cache poisoning attack.

References
[1] Alexander Polyakov SSRF vs. Business critical applications BlackHat 2012
[2] SSRF bible. Cheatsheet ONSec Labs
desc.dataflow.golang.server_side_request_forgery
Abstract
The application initiates a network connection to a third-party system using user-controlled data to craft the resource URI.
Explanation
A Server-Side Request Forgery occurs when an attacker can influence a network connection made by the application server. The network connection will originate from the application server's internal IP and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example: In the following example, an attacker can control the URL to which the server is connecting.


String url = request.getParameter("url");
CloseableHttpClient httpclient = HttpClients.createDefault();
HttpGet httpGet = new HttpGet(url);
CloseableHttpResponse response1 = httpclient.execute(httpGet);


The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https like:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- On Windows systems, file:// scheme and UNC paths can allow an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.

References
[1] Alexander Polyakov SSRF vs. Business critical applications BlackHat 2012
[2] SSRF bible. Cheatsheet ONSec Labs
desc.dataflow.java.server_side_request_forgery
Abstract
The application initiates a network connection to a third-party system using user-controlled data to craft the resource URI.
Explanation
A Server-Side Request Forgery occurs when an attacker may influence a network connection made by the application server. The network connection will originate from the application server's internal IP address and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example: In the following example, an attacker can control the URL to which the server is connecting.


var http = require('http');
var url = require('url');

function listener(request, response){
var request_url = url.parse(request.url, true)['query']['url'];
http.request(request_url)
...
}
...
http.createServer(listener).listen(8080);
...


The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https like:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- On Windows systems, file:// scheme and UNC paths can allow an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.
References
[1] Alexander Polyakov SSRF vs. Business critical applications BlackHat 2012
[2] SSRF bible. Cheatsheet ONSec Labs
desc.dataflow.javascript.server_side_request_forgery
Abstract
The application initiates a network connection to a third-party system using user-controlled data to craft the resource URI.
Explanation
A Server-Side Request Forgery occurs when an attacker can influence a network connection made by the application server. The network connection will originate from the application server's internal IP and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example: In the following example, an attacker can control the URL to which the server is connecting.


val url: String = request.getParameter("url")
val httpclient: CloseableHttpClient = HttpClients.createDefault()
val httpGet = HttpGet(url)
val response1: CloseableHttpResponse = httpclient.execute(httpGet)


The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https like:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- On Windows systems, file:// scheme and UNC paths can allow an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.

References
[1] Alexander Polyakov SSRF vs. Business critical applications BlackHat 2012
[2] SSRF bible. Cheatsheet ONSec Labs
desc.dataflow.kotlin.server_side_request_forgery
Abstract
The application initiates a network connection to a third-party system using user-controlled data to craft the resource URI.
Explanation
A Server-Side Request Forgery occurs when an attacker may influence a network connection made by the application server. The network connection will originate from the application server's internal IP address and an attacker will be able to use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example: In the following example, an attacker can control the URL to which the server is connecting.


$url = $_GET['url'];
$c = curl_init();
curl_setopt($c, CURLOPT_POST, 0);
curl_setopt($c,CURLOPT_URL,$url);
$response=curl_exec($c);
curl_close($c);


The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https like:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- On Windows systems, file:// scheme and UNC paths can allow an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.

References
[1] Alexander Polyakov SSRF vs. Business critical applications BlackHat 2012
[2] SSRF bible. Cheatsheet ONSec Labs
desc.dataflow.php.server_side_request_forgery
Abstract
The application initiates a network connection to a third-party system using user-controlled data to craft the resource URI.
Explanation
A Server-Side Request Forgery occurs when an attacker may influence a network connection made by the application server. The network connection will originate from the application server's internal IP address and an attacker will be able to use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example: In the following example, an attacker can control the URL to which the server is connecting.


url = request.GET['url']
handle = urllib.urlopen(url)


The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https like:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- On Windows systems, file:// scheme and UNC paths can allow an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.

References
[1] Alexander Polyakov SSRF vs. Business critical applications BlackHat 2012
[2] SSRF bible. Cheatsheet ONSec Labs
desc.dataflow.python.server_side_request_forgery
Abstract
The application initiates a network connection to a third-party system using user-controlled data to craft the resource URI.
Explanation
A Server-Side Request Forgery occurs when an attacker may influence a network connection made by the application server. The network connection will originate from the application server's internal IP address and an attacker will be able to use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example: In the following example, an attacker can control the URL to which the server is connecting.


url = req['url']
Net::HTTP.get(url)


The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https like:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- On Windows systems, file:// scheme and UNC paths can allow an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.
desc.dataflow.ruby.server_side_request_forgery
Abstract
The application initiates a network connection to a third-party system using user-controlled data to craft the resource URI.
Explanation
A Server-Side Request Forgery occurs when an attacker may influence a network connection made by the application server. The network connection will originate from the application server's internal IP address and an attacker will be able to use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.

Example: In the following example, an attacker can control the URL to which the server is connecting.


def getFile(url: String) = Action { request =>
...
val url = request.body.asText.getOrElse("http://google.com")

ws.url(url).get().map { response =>
Ok(s"Request sent to $url")
}
...
}


The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https like:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- On Windows systems, file:// scheme and UNC paths can allow an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.

References
[1] Alexander Polyakov SSRF vs. Business critical applications BlackHat 2012
[2] SSRF bible. Cheatsheet ONSec Labs
desc.dataflow.scala.server_side_request_forgery
Abstract
The application initiates a network connection to a third-party system using user-controlled data to craft the resource URI.
Explanation

A Server-Side Request Forgery occurs when an attacker can influence a network connection made by the application server. The network connection will originate from the application server's internal IP and an attacker can use this connection to bypass network controls and scan or attack internal resources that are otherwise not exposed.

Example 1: Example of an actual user checking details of a given product.

POST /checkDetails HTTP/1.1

url=https://example.com/product/1
Example 2: Few examples of how an attacker that has control over the url parameter can tamper the request in Example 1.

POST /checkDetails HTTP/1.1

url=https://localhost.com/admin

POST /checkDetails HTTP/1.1

url=file:///etc/passwd



The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from http or https like:

- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://

An attacker can leverage this hijacked network connection to perform the following attacks:

- Port Scanning of intranet resources.
- Bypass firewalls.
- Access authorization credentials.
- Attack vulnerable programs running on the application server or on the intranet.
- Gain remote code execution.
- Access local files.

References
[1] OWASP A10 Server-Side Request Forgery (SSRF) OWASP Top 10:2021
[2] Alexander Polyakov SSRF vs. Business critical applications BlackHat 2012
[3] SSRF bible. Cheatsheet ONSec Labs
desc.dynamic.xtended_preview.server_side_request_forgery
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.

Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.
desc.dataflow.dotnet.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.

Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.

Example 1: The following C code accepts a number as one of its command line parameters and sets it as the host ID of the current machine.


...
sethostid(argv[1]);
...


Although a process must be privileged to successfully invoke sethostid(), unprivileged users may be able to invoke the program. The code in this example allows user input to directly control the value of a system setting. If an attacker provides a malicious value for host ID, the attacker may misidentify the affected machine on the network or cause other unintended behavior.

In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
desc.dataflow.cpp.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.



Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.

Example: The following COBOL code snippet reads values from the terminal and uses them to compute the options used to establish access to a queue object.


...
ACCEPT OPT1.
ACCEPT OPT2
COMPUTE OPTS = OPT1 + OPT2.
CALL 'MQOPEN' USING HCONN, OBJECTDESC, OPTS, HOBJ, COMPOCODE REASON.
...


In this example, an attacker could supply an option that allows shared rather than exclusive access to the queue.

In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
desc.dataflow.cobol.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.

Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.

Example: The following code reads a number from a web form and uses it to set the timeout value in an initialization file.


...
<cfset code = SetProfileString(IniPath,
Section, "timeout", Form.newTimeout)>
...


Because the value of Form.newTimeout is used to specify a timeout, an attacker may be able to mount a denial of service (DoS) attack against the application by specifying a sufficiently large number.

In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
desc.dataflow.cfml.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.



Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.

Example 1: The following code snippet sets an environment variable with user-controlled data.


...
catalog := request.Form.Get("catalog")
path := request.Form.Get("path")
os.Setenv(catalog, path)
...


In this example, an attacker could set any arbitrary environment variable and affect how other applications work.

In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always obvious, but do not underestimate the creativity of your attacker.
desc.dataflow.golang.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.



Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.

Example 1: The following Java code snippet reads a string from an HttpServletRequest and sets it as the active catalog for a database Connection.


...
conn.setCatalog(request.getParamter("catalog"));
...


In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.

In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
desc.dataflow.java.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.



Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.

Example 1: The following Node.js code snippet reads a string from an http.IncomingMessage request variable and uses it to set additional V8 commnd line flags.


var v8 = require('v8');
...
var flags = url.parse(request.url, true)['query']['flags'];
...
v8.setFlagsFromString(flags);
...


In this example, an attacker could cause various different flags to be set on the VM, which may result in unpredictable behavior including crashing the program and potentially data loss.

In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
desc.dataflow.javascript.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.



Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.

Example 1: The following PHP code snippet reads a parameter from an HTTP request and sets it as the active catalog for a database connection.


<?php
...
$table_name=$_GET['catalog'];
$retrieved_array = pg_copy_to($db_connection, $table_name);
...
?>


In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.

In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
desc.dataflow.php.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.



Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.

Example 1: The following code snippet sets an environment variable using user-controlled data.


...
catalog = request.GET['catalog']
path = request.GET['path']
os.putenv(catalog, path)
...


In this example, an attacker could set any arbitrary environment variable and affect how other applications work.

In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
desc.dataflow.python.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.



Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.

Example: The following Scala code snippet reads a string from an Http Request and sets it as the active catalog for a database Connection.


def connect(catalog: String) = Action { request =>
...
conn.setCatalog(catalog)
...
}


In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.

In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
desc.dataflow.scala.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.

Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.

Example 1: The following code configures the SQL log handler and uses a value controllable by the user.


...
sqlite3(SQLITE_CONFIG_LOG, user_controllable);
...


In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
desc.dataflow.swift.setting_manipulation
Abstract
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.
Explanation
Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.



Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.

Example 1: The following VB code snippet reads a string from a Request object and sets it as the active catalog for a database Connection.


...
Dim conn As ADODB.Connection
Set conn = New ADODB.Connection
Dim rsTables As ADODB.Recordset
Dim Catalog As New ADOX.Catalog
Set Catalog.ActiveConnection = conn
Catalog.Create Request.Form("catalog")
...


In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.

In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.
desc.dataflow.vb.setting_manipulation
Abstract
Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.

2. The data used to dynamically construct a SQL query.
Example 1: The following code dynamically constructs and executes a SQL query designed to search for invoices belonging to a user. The query restricts the items displayed to those where user is equal to the user name of the currently authenticated user.


...
v_account = request->get_form_field( 'account' ).
v_reference = request->get_form_field( 'ref_key' ).

CONCATENATE `user = '` sy-uname `'` INTO cl_where.
IF v_account IS NOT INITIAL.
CONCATENATE cl_where ` AND account = ` v_account INTO cl_where SEPARATED BY SPACE.
ENDIF.
IF v_reference IS NOT INITIAL.
CONCATENATE cl_where "AND ref_key = `" v_reference "`" INTO cl_where.
ENDIF.

SELECT *
FROM invoice_items
INTO CORRESPONDING FIELDS OF TABLE itab_items
WHERE (cl_where).
...


The query this code intends to execute is the following(provided v_account and v_reference are not blanks):


SELECT *
FROM invoice_items
INTO CORRESPONDING FIELDS OF TABLE itab_items
WHERE user = sy-uname
AND account = <account>
AND ref_key = <reference>.


However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, it is a candidate for SQL injection attacks. If an attacker enters the string "abc` OR MANDT NE `+" for v_reference and string '1000' for v_account, then the query becomes the following:


SELECT *
FROM invoice_items
INTO CORRESPONDING FIELDS OF TABLE itab_items
WHERE user = sy-uname
AND account = 1000
AND ref_key = `abc` OR MANDT NE `+`.


The addition of the OR MANDT NE `+` condition causes the WHERE clause to always evaluate to true because the client field can never be equal to literal +, so query becomes logically equivalent to the much simpler query:


SELECT * FROM invoice_items
INTO CORRESPONDING FIELDS OF TABLE itab_items.


This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the invoice_items table, regardless of the specified user.

Example 2: In this example, we will consider the usage of ADBC API in a program that lets employees update their address.


PARAMETERS: p_street TYPE string,
p_city TYPE string.

Data: v_sql TYPE string,
stmt TYPE REF TO CL_SQL_STATEMENT.

v_sql = "UPDATE EMP_TABLE SET ".

"Update employee address. Build the update statement with changed details
IF street NE p_street.
CONCATENATE v_sql "STREET = `" p_street "`".
ENDIF.
IF city NE p_city.
CONCATENATE v_sql "CITY = `" p_city "`".
ENDIF.

l_upd = stmt->execute_update( v_sql ).



If a disgruntled employee inputs a string like "ABC` SALARY = `1000000" for the parameter p_street, the application lets the database be updated with revised salary!

One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

References
[1] SAP OSS notes 1520356, 1487337, 1502272 and related notes.
[2] S. J. Friedl SQL Injection Attacks by Example
[3] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[4] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[5] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.abap.sql_injection
Abstract
Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a SQL query.

Example 1: The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where the owner matches the user name of the currently-authenticated user.


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var username:String = String(params["username"]);
var itemName:String = String(params["itemName"]);
var query:String = "SELECT * FROM items WHERE owner = " + username + " AND itemname = " + itemName;

stmt.sqlConnection = conn;
stmt.text = query;
stmt.execute();
...


The query intends to execute the following code:


SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;


However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:


SELECT * FROM items;


This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Example 2: This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name wiley enters the string "name'; DELETE FROM items; --" for itemName, then the query becomes the following two queries:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

--'


Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. In this case the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';


One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.actionscript.sql_injection
Abstract
Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.

2. The data is used to dynamically construct a SQL query.
Example 1: The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where owner matches the user name of the currently-authenticated user.


...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
+ userName + "' AND itemname = '"
+ ItemName.Text + "'";
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
...


The query intends to execute the following code:


SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;


However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:


SELECT * FROM items;


This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Example 2: This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name wiley enters the string "name'); DELETE FROM items; --" for itemName, then the query becomes the following two queries:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

--'


Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. In this case the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';


One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.dotnet.sql_injection
Abstract
Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.

2. The data is used to dynamically construct a SQL query.
Example 1: The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where the owner matches the user name of the currently-authenticated user.


...
ctx.getAuthUserName(&userName); {
CString query = "SELECT * FROM items WHERE owner = '"
+ userName + "' AND itemname = '"
+ request.Lookup("item") + "'";
dbms.ExecuteSQL(query);
...
Example 2:Alternatively, a similar result could be obtained with SQLite using the following code:


...
sprintf (sql, "SELECT * FROM items WHERE owner='%s' AND itemname='%s'", username, request.Lookup("item"));
printf("SQL to execute is: \n\t\t %s\n", sql);
rc = sqlite3_exec(db,sql, NULL,0, &err);
...


The query intends to execute the following code:


SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;


However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:


SELECT * FROM items;


This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Example 3: This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name wiley enters the string "name'); DELETE FROM items; --" for itemName, then the query becomes the following two queries:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

--'


Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. In this case the comment character serves to the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';


One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] Parameterized CRecordset and CDatabase for SQL Server
[6] Parameterizing a Recordset Microsoft
[7] ODBC API Reference: SQLNumParams() Microsoft
[8] ODBC API Reference: SQLBindParameter() Microsoft
[9] OLE DB Reference: ICommandWithParameters Microsoft
desc.dataflow.cpp.sql_injection
Abstract
Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.

2. The data used to dynamically construct a SQL query.
Example 1: The following code dynamically constructs and executes a SQL query designed to search for items matching a specified name. The query restricts the items displayed to those where owner is equal to the user name of the currently authenticated user.


...
ACCEPT USER.
ACCEPT ITM.
MOVE "SELECT * FROM items WHERE owner = '" TO QUERY1.
MOVE "' AND itemname = '" TO QUERY2.
MOVE "'" TO QUERY3.

STRING
QUERY1, USER, QUERY2, ITM, QUERY3 DELIMITED BY SIZE
INTO QUERY
END-STRING.

EXEC SQL
EXECUTE IMMEDIATE :QUERY
END-EXEC.
...


The query this code intends to execute is the following:


SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;


However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itm, then the query becomes the following:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so query becomes logically equivalent to the much simpler query:


SELECT * FROM items;


This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Example 2: In this example, we will consider the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name wiley enters the string "name'; DELETE FROM items; --" for itemName, then the query becomes the following two queries:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

--'


Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string would result in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on supported databases this type of attack will allow the execution of arbitrary commands against the database.

Notice the trailing pair of hyphens (--); these indicate to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. In this case the comments are used to remove the trailing single-quote leftover from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';


One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.cobol.sql_injection
Abstract
Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.

2. The data used to dynamically construct a SQL query.
Example 1: The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where owner matches the user name of the currently-authenticated user.


...
<cfquery name="matchingItems" datasource="cfsnippets">
SELECT * FROM items
WHERE owner='#Form.userName#'
AND itemId=#Form.ID#
</cfquery>
...


The query intends to execute the following code:


SELECT * FROM items
WHERE owner = <userName>
AND itemId = <ID>;


However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if Form.ID does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for Form.ID, then the query becomes the following:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemId = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:


SELECT * FROM items;


This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Example 2: This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name hacker enters the string "hacker'); DELETE FROM items; --" for Form.ID, then the query becomes the following two queries:


SELECT * FROM items
WHERE owner = 'hacker'
AND itemId = 'name';

DELETE FROM items;

--'


Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. In this case the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:


SELECT * FROM items
WHERE owner = 'hacker'
AND itemId = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';


One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.cfml.sql_injection
Abstract
Using the Java J2EE PersistenceAPI to execute a dynamic SQL statement built with input coming from an untrusted source can enable an attacker to modify the statement's meaning or to execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a SQL query.

Example 1: The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where the owner matches the user name of the currently-authenticated user.


...
final server = await HttpServer.bind('localhost', 18081);
server.listen((request) async {
final headers = request.headers;
final userName = headers.value('userName');
final itemName = headers.value('itemName');
final query = "SELECT * FROM items WHERE owner = '"
+ userName! + "' AND itemname = '"
+ itemName! + "'";
db.query(query);
}
...


The query intends to execute the following code:


SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;


However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:


SELECT * FROM items;


This simplification of the query enables the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Example 2: This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name wiley enters the string "name'; DELETE FROM items; --" for itemName, then the query becomes the following two queries:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

--'


Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack enables the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. In this case, the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';


One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be an effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers might:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed to deal with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some types of exploits, but they will not make your application secure against SQL injection attacks.
desc.dataflow.dart.sql_injection
Abstract
Constructing a dynamic SQL statement with input that comes from an untrusted source enables an attacker to modify the statement's meaning or to execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.

2. The data is used to dynamically construct a SQL query.
Example 1: The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where the owner matches the user name of the currently-authenticated user.


...
rawQuery := request.URL.Query()
username := rawQuery.Get("userName")
itemName := rawQuery.Get("itemName")
query := "SELECT * FROM items WHERE owner = " + username + " AND itemname = " + itemName + ";"

db.Exec(query)
...


The query intends to execute the following code:


SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;


However, because the code dynamically constructs the query by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:


SELECT * FROM items;


This simplification of the query enables the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Example 2: This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name wiley enters the string "name'; DELETE FROM items; --" for itemName, then the query becomes the following two queries:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

--'


Many database servers, including Microsoft(R) SQL Server 2000, allow the simultaneous execution of multiple SQL statements separated by semicolons. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack enables the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers to treat the remainder of the statement as a comment and to not execute it. [4]. In this case, the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'; DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements are created:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';


One traditional approach to prevent SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective to prevent SQL injection attacks. For example, attackers can:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it does not make your application secure from SQL injection attacks.

Another solution commonly proposed to deal with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they do not make your application secure against SQL injection attacks.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.golang.sql_injection
Abstract
Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a SQL query.

Example 1: The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where the owner matches the user name of the currently-authenticated user.


...
String userName = ctx.getAuthenticatedUserName();
String itemName = request.getParameter("itemName");
String query = "SELECT * FROM items WHERE owner = '"
+ userName + "' AND itemname = '"
+ itemName + "'";
ResultSet rs = stmt.execute(query);
...


The query intends to execute the following code:


SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;


However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:


SELECT * FROM items;


This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Example 2: This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name wiley enters the string "name'; DELETE FROM items; --" for itemName, then the query becomes the following two queries:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

--'


Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. In this case the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';


Some think that in the mobile world, classic web application vulnerabilities, such as SQL injection, do not make sense -- why would the user attack themself? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.

Example 3: The following code adapts Example 1 to the Android platform.


...
PasswordAuthentication pa = authenticator.getPasswordAuthentication();
String userName = pa.getUserName();
String itemName = this.getIntent().getExtras().getString("itemName");
String query = "SELECT * FROM items WHERE owner = '"
+ userName + "' AND itemname = '"
+ itemName + "'";
SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
Cursor c = db.rawQuery(query, null);
...


One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] IDS00-J. Prevent SQL Injection CERT
[6] INJECT-2: Avoid dynamic SQL Oracle
desc.dataflow.java.sql_injection
Abstract
Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a SQL query.

Example 1: The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where the owner matches the user name of the currently-authenticated user.


...
var username = document.form.username.value;
var itemName = document.form.itemName.value;
var query = "SELECT * FROM items WHERE owner = " + username + " AND itemname = " + itemName + ";";
db.transaction(function (tx) {
tx.executeSql(query);
}
)
...


The query intends to execute the following code:


SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;


However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:


SELECT * FROM items;


This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Example 2: This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name wiley enters the string "name'; DELETE FROM items; --" for itemName, then the query becomes the following two queries:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

--'


Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. In this case the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';


One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.javascript.sql_injection
Abstract
Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a SQL query.

Example 1: The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where the owner matches the user name of the currently-authenticated user.


...
$userName = $_SESSION['userName'];
$itemName = $_POST['itemName'];
$query = "SELECT * FROM items WHERE owner = '$userName' AND itemname = '$itemName';";
$result = mysql_query($query);
...


The query intends to execute the following code:


SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;


However, because the query is constructed dynamically by concatenating a constant query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:


SELECT * FROM items;


This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Example 2: This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name wiley enters the string "name'; DELETE FROM items; --" for itemName, then the query becomes the following two queries:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

--'


Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. In this case the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';


One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.php.sql_injection
Abstract
Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.

2. The data used to dynamically construct a SQL query.
Example 1: The following code dynamically constructs and executes a SQL query designed to search for items matching a specified name. The query restricts the items displayed to those where owner is equal to the user name of the currently authenticated user.


procedure get_item (
itm_cv IN OUT ItmCurTyp,
usr in varchar2,
itm in varchar2)
is
open itm_cv for ' SELECT * FROM items WHERE ' ||
'owner = '''|| usr || '''' ||
' AND itemname = ''' || itm || '''';
end get_item;


The query this code intends to execute is the following:


SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;


However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itm, then the query becomes the following:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so query becomes logically equivalent to the much simpler query:


SELECT * FROM items;


This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Example 2: In this example, we will consider the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name wiley enters the string "name'; DELETE FROM items; --" for itemName, then the query becomes the following two queries:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

--'


Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string would result in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on supported databases this type of attack will allow the execution of arbitrary commands against the database.

Notice the trailing pair of hyphens (--); these indicate to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. In this case the comments are used to remove the trailing single-quote leftover from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';


One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. As this series of examples has shown, stored procedures can be just as vulnerable as other kinds of code. Stored procedures can help prevent certain types of exploits, but they will not make your application inherently secure from SQL injection attacks.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] David Litchfield Lateral SQL Injection: A New Class of Vulnerability in Oracle
desc.dataflow.sql.sql_injection
Abstract
Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a SQL query.

Example 1: The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where the owner matches the user name of the currently-authenticated user.


...
userName = req.field('userName')
itemName = req.field('itemName')
query = "SELECT * FROM items WHERE owner = ' " + userName +" ' AND itemname = ' " + itemName +"';"
cursor.execute(query)
result = cursor.fetchall()
...


The query intends to execute the following code:


SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;


However, because the query is constructed dynamically by concatenating a constant query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:


SELECT * FROM items;


This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Example 2: This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name wiley enters the string "name'; DELETE FROM items; --" for itemName, then the query becomes the following two queries:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

--'


Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. In this case the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';


One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.python.sql_injection
Abstract
Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.

In this case, Fortify Static Code Analyzer could not determine that the source of the data is trusted.

2. The data is used to dynamically construct a SQL query.

Example 1: The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where the owner matches the user name of the currently-authenticated user.


...
userName = getAuthenticatedUserName()
itemName = params[:itemName]
sqlQuery = "SELECT * FROM items WHERE owner = '#{userName}' AND itemname = '#{itemName}'"
rs = conn.query(sqlQuery)
...


The query intends to execute the following code:


SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;


However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:


SELECT * FROM items;


This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Due to the fact that Ruby is not statically typed also enables other points of injection into SQL queries that may not be available in statically typed languages.
Example 2: The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where the owner matches the user name of the currently-authenticated user.


...
id = params[:id]
itemName = Mysql.escape_string(params[:itemName])
sqlQuery = "SELECT * FROM items WHERE id = #{userName} AND itemname = '#{itemName}'"
rs = conn.query(sqlQuery)
...


In this case, the expected SQL query to be run is:


SELECT * FROM items WHERE id=<id> AND itemname = <itemName>;

You can see this time that we've protected against an attacker specifying a single quote inside itemName and seemingly prevented the SQL injection vulnerability. However as Ruby is not a statically typed language, even though we are expecting id to be an integer of some variety, as this is assigned from user input it won't necessarily be a number. If an attacker can instead change the value of id to 1 OR id!=1--, since there is no check that id is in fact numeric, the SQL query now becomes:


SELECT * FROM items WHERE id=1 OR id!=1-- AND itemname = 'anyValue';


Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. Due to this, it's now just running a SQL query consisting of:


SELECT * FROM items WHERE id=1 OR id!=1;


We are now just selecting everything from that table whether the value of id is equal to 1 or not, which of course equates to everything within the table.

Many database servers allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.ruby.sql_injection
Abstract
Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a SQL query.

Example 1: The following code dynamically constructs and executes a SQL query that searches for users matching a specified name. The query restricts the items displayed to those where the owner matches the user name provided as a path parameter.


def doSQLQuery(value:String) = Action.async { implicit request =>
val result: Future[Seq[User]] = db.run {
sql"select * from users where name = '#$value'".as[User]
}
...
}


The query intends to execute the following code:


SELECT * FROM users
WHERE name = <userName>


However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if userName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for userName, then the query becomes the following:


SELECT * FROM users
WHERE name = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:


SELECT * FROM users;


This simplification of the query allows the attacker to bypass the requirement that the query must only return users owned by the specified user; the query now returns all entries stored in the users table, regardless of their specified user.

One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] IDS00-J. Prevent SQL Injection CERT
[6] INJECT-2: Avoid dynamic SQL Oracle
desc.dataflow.scala.sql_injection
Abstract
Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.

2. The data is used to dynamically construct a SQL query.
Example 1: The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where the owner matches the user name of the currently-authenticated user.


...
let queryStatementString = "SELECT * FROM items WHERE owner='\(username)' AND itemname='\(item)'"
var queryStatement: OpaquePointer? = nil
if sqlite3_prepare_v2(db, queryStatementString, -1, &queryStatement, nil) == SQLITE_OK {
if sqlite3_step(queryStatement) == SQLITE_ROW {
...
}
}
...


The query intends to execute the following code:


SELECT * FROM items
WHERE owner = '<userName>'
AND itemname = '<itemName>'


However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:


SELECT * FROM items;


This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Example 3: This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name wiley enters the string "name'); DELETE FROM items; --" for itemName, then the query becomes the following two queries:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

--'


Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. In this case the comment character serves to the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';


One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] Parameterized CRecordset and CDatabase for SQL Server
[6] Parameterizing a Recordset Microsoft
[7] ODBC API Reference: SQLNumParams() Microsoft
[8] ODBC API Reference: SQLBindParameter() Microsoft
[9] OLE DB Reference: ICommandWithParameters Microsoft
desc.dataflow.swift.sql_injection
Abstract
Constructing a dynamic SQL statement with input from an untrusted source might allow an attacker to modify the statement's meaning or execute arbitrary SQL commands.
Explanation
SQL injection errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a SQL query.

Example 1: The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where the owner matches the user name of the currently-authenticated user.


...
username = Session("username")
itemName = Request.Form("itemName")
strSQL = "SELECT * FROM items WHERE owner = '"& userName &"' AND itemname = '" & itemName &"'"
objRecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
...


The query intends to execute the following code:


SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;


However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';


The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:


SELECT * FROM items;


This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Example 2: This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name wiley enters the string "name'; DELETE FROM items; --" for itemName, then the query becomes the following two queries:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

--'


Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. In this case the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:


SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';


One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
desc.dataflow.vb.sql_injection
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection.
Example: The following code prints the SAPFTP version information on the screen:


...
CALL FUNCTION 'FTP_VERSION'
...
IMPORTING
EXEPATH = p
VERSION = v
WORKING_DIR = dir
RFCPATH = rfcp
RFCVERSION = rfcv
TABLES
FTP_TRACE = FTP_TRACE.

WRITE: 'exepath: ', p, 'version: ', v, 'working_dir: ', dir, 'rfcpath: ', rfcp, 'rfcversion: ', rfcv.
...


Depending upon the configuration of the selection screen, this information can be dumped to a screen or sent directly to a printer. In some cases the version information tells the attacker precisely what sort of an attack the system will be vulnerable to. In the same manner, error messages can tell the attacker what attack the system is vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.abap.system_information_leak_external
Abstract
Revealing system data or debugging information could enable an adversary to use system information to plan an attack.
Explanation
An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection.

Example 1: The following code prints a stack trace to either a "Debug" console or a log file:


try {
...
}
catch(e:Error) {
trace(e.getStackTrace());
}


Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. For example, with scripting mechanisms it is trivial to redirect output information from "Standard error" or "Standard output" into a file or another program. Alternatively, the system that the program runs on could have a remote logging mechanism such as a "syslog" server that sends the logs to a remote device. During development, you have no way of knowing where this information might end up being displayed.

In some cases the error message tells the attacker precisely what sort of an attack the system is vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.actionscript.system_information_leak_external
Abstract
Revealing system data or debugging information enables an adversary to learn about the system and form a plan of attack.
Explanation
An external information leak occurs when system data or debug information leaves the program to a remote machine via a socket or network connection. External leaks can help an attacker by revealing specific data about operating systems, full pathnames, the existence of usernames, or locations of configuration files. External leaks are more serious than internal information leaks, which are more difficult for an attacker to access.

Example 1: The following code leaks Exception information in the <apex:messages/> element of a Visualforce page:


try {
...
} catch (Exception e) {
ApexPages.Message msg = new ApexPages.Message(ApexPages.Severity.FATAL, e.getMessage());
ApexPages.addMessage(msg);
}


This information can be exposed to a remote user. In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.
References
[1] Ernst Haselsteiner and Klemens Breitfuss Security in Near Field Communication (NFC): Strengths and Weaknesses
[2] ERR01-J. Do not allow exceptions to expose sensitive information CERT
[3] ENV02-J. Do not trust the values of environment variables CERT
[4] FUNDAMENTALS-4: Establish trust boundaries Oracle
[5] CONFIDENTIAL-1: Purge sensitive information from exceptions Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[10] Standards Mapping - CIS Kubernetes Benchmark partial
[11] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[19] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[20] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[21] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.apex.system_information_leak_external
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection.
Example 1: The following code leaks Exception information in the HTTP response:


try
{
...
}
catch (Exception e)
{
Response.Write(e.ToString());
}


This information can be exposed to a remote user. In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.dotnet.system_information_leak_external
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection.
Example 1: The following code leaks system information via a socket:


int sockfd;
int flags;
char hostname[1024];
hostname[1023] = '\0';
gethostname(hostname, 1023);
...
sockfd = socket(AF_INET, SOCK_STREAM, 0);
flags = 0;
send(sockfd, hostname, strlen(hostname), flags);


This information can be exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.cpp.system_information_leak_external
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection.
Example 1: The following code displays the error code SQLCODE and the error message SQlERRMC associated with the SQL command that caused the error to the terminal.


...
EXEC SQL
WHENEVER SQLERROR
PERFORM DEBUG-ERR
SQL-EXEC.
...
DEBUG-ERR.
DISPLAY "Error code is: " SQLCODE.
DISPLAY "Error message is: " SQLERRMC.
...


Depending on the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system is vulnerable to. In Example 1, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.cobol.system_information_leak_external
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection.
Example: The following code catches an exception and prints its message to the page.


<cfcatch type="Any">
<cfset exception=getException(myObj)>
<cfset message=exception.toString()>
<cfoutput>
Exception message: #message#
</cfoutput>
</cfcatch>


Depending on the system configuration, this information can be written to a log file or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system is vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.cfml.system_information_leak_external
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection.

Example 1: The following example leaks system information via an HTTP response.


func handler(w http.ResponseWriter, r *http.Request) {
host, err := os.Hostname()
...
fmt.Fprintf(w, "%s is busy, please try again later.", host)
}


In some cases, the error message tells the attacker to which precise type of attack the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.golang.system_information_leak_external
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection. External leaks can reveal specific data about operating systems, full pathnames, the existence of usernames, or locations of configuration files. These are mores serious than internal information leaks, which are more difficult for an attacker to access.

Example 1: The following Spring Boot configuration property leaks stacktrace information in the HTTP response:


server.error.include-stacktrace=always


This information can be exposed to a remote user. In some cases, the error message reveals exactly the types of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more indirect clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] ERR01-J. Do not allow exceptions to expose sensitive information CERT
[2] ENV02-J. Do not trust the values of environment variables CERT
[3] FUNDAMENTALS-4: Establish trust boundaries Oracle
[4] CONFIDENTIAL-1: Purge sensitive information from exceptions Oracle
[5] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[11] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[12] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[13] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[18] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[19] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[20] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.system_information_leak_external
Abstract
Revealing system data or debugging information could enable an adversary to use system information to plan an attack.
Explanation
An external information leak occurs when system data or debug information leaves the program to a remote machine via a socket or network connection. External leaks can help an attacker by revealing specific data about operating systems, full pathnames, the existence of usernames, or locations of configuration files, and are more serious than internal information leaks, which are more difficult for an attacker to access.

Example 1: The following code leaks Exception information into a text area within a web page:


...
dirReader.readEntries(function(results){
...
}, function(error){
$("#myTextArea").val('There was a problem: ' + error);
});
...


This information can be exposed to a remote user. In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.javascript.system_information_leak_external
Abstract
Revealing system data or debugging information could enable an adversary to use system information to plan an attack.
Explanation
An external information leak occurs when system data or debug information leaves the program to a remote machine via a socket or network connection. External leaks can help an attacker by revealing specific data about operating systems, full pathnames, the existence of usernames, or locations of configuration files, and are more serious than internal information leaks, which are more difficult for an attacker to access.

Example 1: The following code leaks Exception information in the HTTP response:


protected fun doPost(req: HttpServletRequest, res: HttpServletResponse) {
...
val out: PrintWriter = res.getWriter()
try {
...
} catch (e: Exception) {
out.println(e.message)
}
}


This information can be exposed to a remote user. In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.

Information leaks are also a concern in a mobile computing environment. With mobile platforms, applications are downloaded from various sources and are run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which is why developers must be careful about the information included in messages addressed to other applications running on the device.

Example 2: The following code broadcasts the stack trace of a caught exception to all the registered Android receivers.

...
try {
...
} catch (e: Exception) {
val exception = Log.getStackTraceString(e)
val intent = Intent()
intent.action = "SEND_EXCEPTION"
intent.putExtra("exception", exception)
view.context.sendBroadcast(intent)
}
...


This is another scenario specific to the mobile environment. Most mobile devices now implement a Near-Field Communication (NFC) protocol for quickly sharing information between devices using radio communication. It works by bringing devices in close proximity or having the devices touch each other. Even though the communication range of NFC is limited to just a few centimeters, eavesdropping, data modification and various other types of attacks are possible, because NFC alone does not ensure secure communication.

Example 3: The Android platform provides support for NFC. The following code creates a message that gets pushed to the other device within range.

...
companion object {
const val TAG = "NfcActivity"
private const val DATA_SPLITTER = "__:DATA:__"
private const val MIME_TYPE = "application/my.applications.mimetype"
}
...
val tm = Context.getSystemService(Context.TELEPHONY_SERVICE) as TelephonyManager
val VERSION = tm.getDeviceSoftwareVersion();
...
val nfcAdapter = NfcAdapter.getDefaultAdapter(this)

val text: String = "$TAG$DATA_SPLITTER$VERSION"
val record = NdefRecord(NdefRecord.TNF_MIME_MEDIA, MIME_TYPE.getBytes(), ByteArray(0), text.toByteArray())
val records = arrayOf(record)
val msg = NdefMessage(records)
nfcAdapter.setNdefPushMessage(msg, this)
...


An NFC Data Exchange Format (NDEF) message contains typed data, a URI, or a custom application payload. If the message contains information about the application, such as its name, MIME type, or device software version, this information could be leaked to an eavesdropper.
References
[1] Ernst Haselsteiner and Klemens Breitfuss Security in Near Field Communication (NFC): Strengths and Weaknesses
[2] ERR01-J. Do not allow exceptions to expose sensitive information CERT
[3] ENV02-J. Do not trust the values of environment variables CERT
[4] FUNDAMENTALS-4: Establish trust boundaries Oracle
[5] CONFIDENTIAL-1: Purge sensitive information from exceptions Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[10] Standards Mapping - CIS Kubernetes Benchmark partial
[11] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[19] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[20] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[21] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.kotlin.system_information_leak_external
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection.

Example: The following code leaks system information via an HTTP request:


NSString *deviceName = [[UIDevice currentDevice] name];
NSString *baseUrl = @"http://myserver.com/?dev=";
NSString *urlString = [baseUrl stringByAppendingString:deviceName];
NSURL *url = [NSURL URLWithString:urlString];
NSURLRequest* request = [NSURLRequest requestWithURL:url cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:60.0];
NSError *err = nil;
NSURLResponse* response = nil;
NSData *data = [NSURLConnection sendSynchronousRequest:request returningResponse:&response error:&err];


This information can be exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.objc.system_information_leak_external
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection.

Example 1: The following code writes an exception to the HTTP response:


<?php
...
echo "Server error! Printing the backtrace";
debug_print_backtrace();
...
?>


Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. For example, with scripting mechanisms it is trivial to redirect output information from "Standard error" or "Standard output" into a file or another program. Alternatively, the system that the program runs on could have a remote logging mechanism such as a "syslog" server that sends the logs to a remote device. During development, you have no way of knowing where this information might end up being displayed.

In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.php.system_information_leak_external
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection.
Example 1: The following code prints the environment variables PATH_INFO and SCRIPT_NAME to the page.


...
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Environment Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Path Information: ' ||
OWA_UTIL.get_cgi_env('PATH_INFO') || '
');
HTP.print('Script Name: ' ||
OWA_UTIL.get_cgi_env('SCRIPT_NAME') || '
');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
}


Depending on the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system is vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.sql.system_information_leak_external
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection.

Example 1: The following code prints all the system environment variables as part of the HTTP response:


...
import cgi
cgi.print_environ()
...


Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. For example, with scripting mechanisms it is trivial to redirect output information from "Standard error" or "Standard output" into a file or another program. Alternatively, the system that the program runs on could have a remote logging mechanism such as a "syslog" server that sends the logs to a remote device. During development, you have no way of knowing where this information might end up being displayed.

In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.python.system_information_leak_external
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection.

Example 1: The following code leaks system information via an HTTP response:


response = Rack::Response.new
...
stacktrace = caller # Kernel#caller returns an array of the execution stack
...
response.finish do |res|
res.write "There was a problem: #{stacktrace}"
end


This information can be exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.ruby.system_information_leak_external
Abstract
Revealing system data or debugging information could enable an adversary to use system information to plan an attack.
Explanation
An external information leak occurs when system data or debug information leaves the program to a remote machine via a socket or network connection. External leaks can help an attacker by revealing specific data about operating systems, full pathnames, the existence of usernames, or locations of configuration files, and are more serious than internal information leaks, which are more difficult for an attacker to access.

Example 1: The following code leaks System details in the HTTP response:


def doSomething() = Action { request =>
...
Ok(Html(Properties.osName)) as HTML
}


This information can be exposed to a remote user. In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Ernst Haselsteiner and Klemens Breitfuss Security in Near Field Communication (NFC): Strengths and Weaknesses
[2] ERR01-J. Do not allow exceptions to expose sensitive information CERT
[3] ENV02-J. Do not trust the values of environment variables CERT
[4] FUNDAMENTALS-4: Establish trust boundaries Oracle
[5] CONFIDENTIAL-1: Purge sensitive information from exceptions Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[10] Standards Mapping - CIS Kubernetes Benchmark partial
[11] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[19] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[20] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[21] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.scala.system_information_leak_external
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection.

Example: The following code leaks system information via an HTTP request:


let deviceName = UIDevice.currentDevice().name
let urlString : String = "http://myserver.com/?dev=\(deviceName)"
let url : NSURL = NSURL(string:urlString)
let request : NSURLRequest = NSURLRequest(URL:url)
var err : NSError?
var response : NSURLResponse?
var data : NSData = NSURLConnection.sendSynchronousRequest(request, returningResponse: &response, error:&err)


This information can be exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.swift.system_information_leak_external
Abstract
Revealing system data or debugging information could enable an adversary to use system information to plan an attack.
Explanation
An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection.

Example 1: The following code writes an exception to the Response output stream:


...
If Err.number <>0 then
Response.Write "An Error Has Occurred on this page!<BR>"
Response.Write "The Error Number is: " & Err.number & "<BR>"
Response.Write "The Description given is: " & Err.Description & "<BR>"
End If
...


Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. For example, with scripting mechanisms it is trivial to redirect output information from "Standard error" or "Standard output" into a file or another program. Alternatively, the system that the program runs on could have a remote logging mechanism such as a "syslog" server that sends the logs to a remote device. During development, you have no way of knowing where this information might end up being displayed.

In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 215, CWE ID 489, CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2, MASVS-STORAGE-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.vb.system_information_leak_external
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An internal information leak occurs when system data or debug information is sent to a local file, console, or screen via printing or logging.
Example: The following code prints the SAPFTP version information on the screen:


...
CALL FUNCTION 'FTP_VERSION'
...
IMPORTING
EXEPATH = p
VERSION = v
WORKING_DIR = dir
RFCPATH = rfcp
RFCVERSION = rfcv
TABLES
FTP_TRACE = FTP_TRACE.

WRITE: 'exepath: ', p, 'version: ', v, 'working_dir: ', dir, 'rfcpath: ', rfcp, 'rfcversion: ', rfcv.
...


Depending upon the configuration of the selection screen, this information can be dumped to a screen or sent directly to a printer. In some cases the version information tells the attacker precisely what sort of an attack the system will be vulnerable to. In the same manner, error messages can tell the attacker what attack the system is vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.abap.system_information_leak_internal
Abstract
Revealing system data or debugging information could enable an adversary to use system information to plan an attack.
Explanation
An internal information leak occurs when system data or debug information is sent to a local file, console, or screen via printing or logging.

Example 1: The following code prints a stack trace to either a "Debug" console or a log file:


try {
...
}
catch(e:Error) {
trace(e.getStackTrace());
}


Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a user. In some cases the error message tells the attacker precisely what sort of an attack the system is vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.actionscript.system_information_leak_internal
Abstract
Revealing system data or debugging information could enable an adversary to use system information to plan an attack.
Explanation
An internal information leak occurs when system data or debug information is sent to a local file, console, or screen via printing or logging.

Example 1: The following code writes an exception message to the debug log:


try {
...
} catch (Exception e) {
System.Debug(LoggingLevel.ERROR, e.getMessage());
}


The error message could enable an adversary to plan an attack. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.
References
[1] Ernst Haselsteiner and Klemens Breitfuss Security in Near Field Communication (NFC): Strengths and Weaknesses
[2] ERR01-J. Do not allow exceptions to expose sensitive information CERT
[3] ENV02-J. Do not trust the values of environment variables CERT
[4] FUNDAMENTALS-4: Establish trust boundaries Oracle
[5] CONFIDENTIAL-1: Purge sensitive information from exceptions Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[10] Standards Mapping - CIS Kubernetes Benchmark partial
[11] Standards Mapping - Common Weakness Enumeration CWE ID 497
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[19] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[20] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[21] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.apex.system_information_leak_internal
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An internal information leak occurs when system data or debug information is sent to a local file, console, or screen via printing or logging.
Example 1: The following code constructs a database connection string, uses it to create a new connection to the database, and writes it to the console.


string cs="database=northwind;server=mySQLServer...";
SqlConnection conn=new SqlConnection(cs);
...
Console.Writeline(cs);


Depending on the system configuration, this information can be dumped to a console, written to a log file, or exposed to a user. In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.dotnet.system_information_leak_internal
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An internal information leak occurs when system data or debugging information is sent via logging or printing to a local file, console, or screen.
Example 1: The following code prints the path environment variable to the standard error stream:


char* path = getenv("PATH");
...
fprintf(stderr, "cannot find exe on path %s\n", path);


Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.cpp.system_information_leak_internal
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An internal information leak occurs when system data or debugging information is sent via logging or printing to a local file, console, or screen.
Example: The following code requests a transaction dump of all the task-related storage areas, the terminal control table, and a specified data area:


...
EXEC CICS DUMP TRANSACTION
DUMPCODE('name')
FROM (data-area)
LENGTH (data-value)
END-EXEC.
...


Depending on the system configuration, this information can be dumped to a console, written to a log file, or exposed to a user. In some cases the error message tells the attacker precisely what sort of an attack the system is vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.cobol.system_information_leak_internal
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An internal information leak occurs when system data or debugging information is sent to a local file, console, or screen via printing or logging.

Example: The following code writes to a file on the local file system:


<cfscript>
try {
obj = CreateObject("person");
}
catch(any excpt) {
f = FileOpen("c:\log.txt", "write");
FileWriteLine(f, "#excpt.Message#");
FileClose(f);
}
</cfscript>


This information is written to a log file. In some cases the message tells the attacker precisely what sort of an attack the system is vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.cfml.system_information_leak_internal
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An internal information leak occurs when system data or debug information is sent to a local file, console, or screen via printing or logging.

Example 1: The following code writes an exception to a local file:


final file = await File('example.txt').create();
final raf = await file.open(mode: FileMode.write);
final data = String.fromEnvironment("PASSWORD");
raf.writeString(data);


Depending on the system configuration, this information can be dumped to a console, written to a log file, or exposed to a user. In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.

Information leaks are also a concern in a mobile computing environment.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.dart.system_information_leak_internal
Abstract
Revealing system data or debugging information could enable an adversary to use system information to plan an attack.
Explanation
An internal information leak occurs when system data or debugging information is sent via logging or printing to a local file, console, or screen.
Example 1: The following code prints the path environment variable to the standard error stream:


path := os.Getenv("PATH")
...
log.Printf("Cannot find exe on path %s\n", path)


Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a user. In some cases, the error message tells the attacker to which precise type of attack the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.golang.system_information_leak_internal
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An external information leak occurs when system data or debug information leaves the program to a remote machine via a socket or network connection. External leaks can help an attacker by revealing specific data about operating systems, full pathnames, the existence of usernames, or locations of configuration files, and are more serious than internal information leaks, which are more difficult for an attacker to access.

Example 1: The following code leaks Exception information in the HTTP response:


protected void doPost (HttpServletRequest req, HttpServletResponse res) throws IOException {
...
PrintWriter out = res.getWriter();
try {
...
} catch (Exception e) {
out.println(e.getMessage());
}
}


This information can be exposed to a remote user. In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.

Information leaks are also a concern in a mobile computing environment. With mobile platforms, applications are downloaded from various sources and are run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which is why application authors need to be careful about what information they include in messages addressed to other applications running on the device.

Example 2: The following code broadcasts the stack trace of a caught exception to all the registered Android receivers.

...
try {
...
} catch (Exception e) {
String exception = Log.getStackTraceString(e);
Intent i = new Intent();
i.setAction("SEND_EXCEPTION");
i.putExtra("exception", exception);
view.getContext().sendBroadcast(i);
}
...


This is another scenario specific to the mobile environment. Most mobile devices now implement a Near-Field Communication (NFC) protocol for quickly sharing information between devices using radio communication. It works by bringing devices in close proximity or having the devices touch each other. Even though the communication range of NFC is limited to just a few centimeters, eavesdropping, data modification and various other types of attacks are possible, because NFC alone does not ensure secure communication.

Example 3: The Android platform provides support for NFC. The following code creates a message that gets pushed to the other device within range.

...
public static final String TAG = "NfcActivity";
private static final String DATA_SPLITTER = "__:DATA:__";
private static final String MIME_TYPE = "application/my.applications.mimetype";
...
TelephonyManager tm = (TelephonyManager)Context.getSystemService(Context.TELEPHONY_SERVICE);
String VERSION = tm.getDeviceSoftwareVersion();
...
NfcAdapter nfcAdapter = NfcAdapter.getDefaultAdapter(this);
if (nfcAdapter == null)
return;

String text = TAG + DATA_SPLITTER + VERSION;
NdefRecord record = new NdefRecord(NdefRecord.TNF_MIME_MEDIA,
MIME_TYPE.getBytes(), new byte[0], text.getBytes());
NdefRecord[] records = { record };
NdefMessage msg = new NdefMessage(records);
nfcAdapter.setNdefPushMessage(msg, this);
...


An NFC Data Exchange Format (NDEF) message contains typed data, a URI, or a custom application payload. If the message contains information about the application, such as its name, MIME type, or device software version, this information could be leaked to an eavesdropper.
References
[1] Ernst Haselsteiner and Klemens Breitfuss Security in Near Field Communication (NFC): Strengths and Weaknesses
[2] ERR01-J. Do not allow exceptions to expose sensitive information CERT
[3] ENV02-J. Do not trust the values of environment variables CERT
[4] FUNDAMENTALS-4: Establish trust boundaries Oracle
[5] CONFIDENTIAL-1: Purge sensitive information from exceptions Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[10] Standards Mapping - CIS Kubernetes Benchmark partial
[11] Standards Mapping - Common Weakness Enumeration CWE ID 497
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[19] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[20] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[21] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.java.system_information_leak_external
Abstract
Revealing system data or debugging information could enable an adversary to use system information to plan an attack.
Explanation
An internal information leak occurs when system data or debug information is sent to a local file, console, or screen via printing or logging.

Example 1: The following code writes an exception to the standard error stream:


var http = require('http');
...

http.request(options, function(res){
...
}).on('error', function(e){
console.log('There was a problem with the request: ' + e);
});
...


Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a user. In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.javascript.system_information_leak_internal
Abstract
Revealing system data or debugging information could enable an adversary to use system information to plan an attack.
Explanation
An internal information leak occurs when system data or debug information is sent to a local file, console, or screen via printing or logging.

Example 1: The following code writes an exception to the standard error stream:


try {
...
} catch (e: Exception) {
e.printStackTrace()
}


Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a user. In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.

Information leaks are also a concern in a mobile computing environment.

Example 2: The following code logs the stack trace of a caught exception on the Android platform.

...
try {
...
} catch (e: Exception) {
Log.e(TAG, Log.getStackTraceString(e))
}
...
References
[1] Ernst Haselsteiner and Klemens Breitfuss Security in Near Field Communication (NFC): Strengths and Weaknesses
[2] ERR01-J. Do not allow exceptions to expose sensitive information CERT
[3] ENV02-J. Do not trust the values of environment variables CERT
[4] FUNDAMENTALS-4: Establish trust boundaries Oracle
[5] CONFIDENTIAL-1: Purge sensitive information from exceptions Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[10] Standards Mapping - CIS Kubernetes Benchmark partial
[11] Standards Mapping - Common Weakness Enumeration CWE ID 497
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[19] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[20] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[21] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.kotlin.system_information_leak_internal
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An internal information leak occurs when system data or debugging information is sent via logging or printing to a local file, console, or screen.
Example 1: The following code leaks system information to the system log:


...
NSString* deviceID = [[UIDevice currentDevice] name];

NSLog(@"DeviceID: %@", deviceID);
...


In the mobile world, other areas of concern for maintaining system information arise when a device has been lost or stolen. Once in possession of an iOS device, an attacker may access a great deal of data by connecting the device by USB. Files such as iOS Property Lists (plists) and SQLite databases are easily accessed and can disclose personal information. As a general rule, privacy related information should not be stored unprotected on the file system.

Example 2: The following code adds a deviceID entry to the list of user defaults, and stores them immediately to a plist file.


...
NSString* deviceID = [[UIDevice currentDevice] name];

[defaults setObject:deviceID forKey:@"deviceID"];
[defaults synchronize];
...


The code in Example 2 stores system information from the mobile device in an unprotected plist file stored on the device. Although many developers trust plist files as a safe storage location for any and all data, it should not be trusted implicitly particularly when system information and privacy are a concern, since plist files could be read by anyone in possession of the device.

Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.objc.system_information_leak_internal
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An internal information leak occurs when system data or debug information is sent to a local file, console, or screen via printing or logging.

Example 1: The following code writes an exception to the standard error stream:


<?php
...
echo "Server error! Printing the backtrace";
debug_print_backtrace();
...
?>


Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a user. In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.php.system_information_leak_internal
Abstract
Revealing system data or debugging information could enable an adversary to use system information to plan an attack.
Explanation
An internal information leak occurs when system data or debug information is sent to a local file, console, or screen via printing or logging.

Example 1: The following code writes an exception to the standard output stream:


try:
...
except:
print(sys.exc_info()[2])


This information is dumped to a console. In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.python.system_information_leak_internal
Abstract
Revealing system data or debugging information could enable an adversary to use system information to plan an attack.
Explanation
An internal information leak occurs when system data or debug information is sent to a local file, console, or screen via printing or logging.

Example 1: The following code writes an exception to the standard error stream:


...
begin
log = Logger.new(STDERR)
...
rescue Exception
log.info("Exception: " + $!)
...
end


Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a user. In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program. Of course, another problem with Example 1 is rescuing the root Exception instead of a specific type or error/exception, meaning it will catch all exceptions, potentially causing other unconsidered side effects.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.ruby.system_information_leak_internal
Abstract
Revealing system data or debugging information could enable an adversary to use system information to plan an attack.
Explanation
An internal information leak occurs when system data or debug information is sent to a local file, console, or screen via printing or logging.

Example 1: The following code prints System information to the standard output stream:


...
println(Properties.osName)
...


Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a user. In some cases, the error message provides the attacker with the precise type of attack to which the system is vulnerable. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In Example 1, the leaked information could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Ernst Haselsteiner and Klemens Breitfuss Security in Near Field Communication (NFC): Strengths and Weaknesses
[2] ERR01-J. Do not allow exceptions to expose sensitive information CERT
[3] ENV02-J. Do not trust the values of environment variables CERT
[4] FUNDAMENTALS-4: Establish trust boundaries Oracle
[5] CONFIDENTIAL-1: Purge sensitive information from exceptions Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[10] Standards Mapping - CIS Kubernetes Benchmark partial
[11] Standards Mapping - Common Weakness Enumeration CWE ID 497
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[19] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[20] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[21] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.scala.system_information_leak_internal
Abstract
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
Explanation
An internal information leak occurs when system data or debugging information is sent via logging or printing to a local file, console, or screen.



In the mobile world, other areas of concern for maintaining system information arise when a device has been lost or stolen. Once in possession of an iOS device, an attacker may access a great deal of data by connecting the device by USB. Files such as iOS Property Lists (plists) and SQLite databases are easily accessed and can disclose personal information. As a general rule, privacy related information should not be stored unprotected on the file system.

Example: The following code prints the device identifier to the system logs:


let deviceName = UIDevice.currentDevice().name
...
NSLog("Device Identifier: %@", deviceName)


Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.swift.system_information_leak_internal
Abstract
Revealing system data or debugging information could enable an adversary to use system information to plan an attack.
Explanation
An internal information leak occurs when system data or debug information is sent to a local file, console, or screen via printing or logging.

Example: The following code sends an ASPError object to a script debugger, such as the Microsoft Script Debugger:


...
Debug.Write Server.GetLastError()
...


In some cases the error message tells the attacker precisely what sort of an attack the system is vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system, such as information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 497
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-002420
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.2 Sensitive Private Data (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.3 Unintended Security Disclosure Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000450 CAT II, APSC-DV-002480 CAT II, APSC-DV-002570 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.vb.system_information_leak_internal
Abstract
The program can potentially fail to release a system resource.
Explanation
The program can potentially fail to release a system resource.

Resource leaks have at least two common causes:

- Error conditions and other exceptional circumstances.

- Confusion over which part of the program is responsible for releasing the resource.

Most unreleased resource issues result in general software reliability problems. However, if an attacker can intentionally trigger a resource leak, the attacker may be able to launch a denial of service attack by depleting the resource pool.

Example: The following method never closes the file handle it opens. The Finalize() method for StreamReader eventually calls Close(), but there is no guarantee as to how long it will take before the Finalize() method is invoked. In fact, there is no guarantee that Finalize() will ever be invoked. In a busy environment, this can result in the VM using up all of its available file handles.


private void processFile(string fName) {
StreamWriter sw = new StreamWriter(fName);
string line;
while ((line = sr.ReadLine()) != null)
processLine(line);
}
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 772
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [21] CWE ID 772
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094, CCI-001133
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[10] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.3 - Web Software Attack Mitigation
[20] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 404
[21] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[42] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[43] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.dotnet.unreleased_resource_streams
Abstract
The program can potentially fail to release a system resource.
Explanation
The program can potentially fail to release a system resource.

Resource leaks have at least two common causes:

- Error conditions and other exceptional circumstances.

- Confusion over which part of the program is responsible for releasing the resource.

Most unreleased resource issues result in general software reliability problems. However, if an attacker can intentionally trigger a resource leak, the attacker may be able to launch a denial of service attack by depleting the resource pool.

Example: The following method never closes the file handle it opens. The finalize() method for FileInputStream eventually calls close(), but there is no guarantee as to how long it will take before the finalize() method will be invoked. In a busy environment, this can result in the JVM using up all of its file handles.

private void processFile(String fName) throws FileNotFoundException, IOException {
FileInputStream fis = new FileInputStream(fName);
int sz;
byte[] byteArray = new byte[BLOCK_SIZE];
while ((sz = fis.read(byteArray)) != -1) {
processBytes(byteArray, sz);
}
}
References
[1] FIO04-J. Release resources when they are no longer needed CERT
[2] DOS-2: Release resources in all cases Oracle
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 772
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [21] CWE ID 772
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094, CCI-001133
[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 Top 10 2004 A9 Application Denial of Service
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 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 4.0 Requirement 6.2.4
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.3 - Web Software Attack Mitigation
[22] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 404
[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.1 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002000 CAT II, 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.unreleased_resource_streams
Abstract
The identified function sometimes fails to release a system resource.
Explanation
The program can potentially fail to release a system resource.


Resource leaks have at least two common causes:

- Error conditions and other exceptional circumstances.

- Confusion over which part of the program is responsible for releasing the resource.

Most unreleased resource issues result in general software reliability problems. However, if an attacker can intentionally trigger a resource leak, the attacker may be able to launch a denial of service attack by depleting the resource pool.

Example 1: The following method never closes the stream that it reads from.


...
CFIndex numBytes;
do {
UInt8 buf[bufferSize];
numBytes = CFReadStreamRead(readStream, buf, sizeof(buf));
if( numBytes > 0 ) {
handleBytes(buf, numBytes);
} else if( numBytes < 0 ) {
CFStreamError error = CFReadStreamGetError(readStream);
reportError(error);
}
} while( numBytes > 0 );
...
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 772
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [21] CWE ID 772
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094, CCI-001133
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[10] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.3 - Web Software Attack Mitigation
[20] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 404
[21] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[42] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[43] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.objc.unreleased_resource_streams
Abstract
The program can potentially fail to release a system resource.
Explanation
The program can potentially fail to release a system resource.

Resource leaks have at least two common causes:

- Error conditions and other exceptional circumstances.

- Confusion over which part of the program is responsible for releasing the resource.

Most unreleased resource issues result in general software reliability problems. However, if an attacker can intentionally trigger a resource leak, the attacker may be able to launch a denial of service attack by depleting the resource pool.

Example: The following method never closes the file handle it opens.

def readFile(filename: String): Unit = {
val data = Source.fromFile(fileName).getLines.mkString
// Use the data
}
References
[1] FIO04-J. Release resources when they are no longer needed CERT
[2] DOS-2: Release resources in all cases Oracle
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 772
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [21] CWE ID 772
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094, CCI-001133
[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 Top 10 2004 A9 Application Denial of Service
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 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 4.0 Requirement 6.2.4
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.3 - Web Software Attack Mitigation
[22] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 404
[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.1 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002000 CAT II, 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.scala.unreleased_resource_streams
Abstract
The identified function sometimes fails to release a system resource.
Explanation
The program can potentially fail to release a system resource.


Resource leaks have at least two common causes:

- Error conditions and other exceptional circumstances.

- Confusion over which part of the program is responsible for releasing the resource.

Most unreleased resource issues result in general software reliability problems. However, if an attacker can intentionally trigger a resource leak, the attacker may be able to launch a denial of service attack by depleting the resource pool.

Example 1: The following method never closes the stream that it reads from.


...
func leak(reading input: InputStream) {
input.open()
let bufferSize = 1024
let buffer = UnsafeMutablePointer<UInt8>.allocate(capacity: bufferSize)
while input.hasBytesAvailable {
let read = input.read(buffer, maxLength: bufferSize)
}
buffer.deallocate(capacity: bufferSize)
}
...
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 772
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [21] CWE ID 772
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094, CCI-001133
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[10] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.3 - Web Software Attack Mitigation
[20] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 404
[21] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002000 CAT II, APSC-DV-002400 CAT II
[42] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[43] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.swift.unreleased_resource_streams