45 elementos encontrados
Debilidades
Abstract
La aplicación refleja un parámetro que puede controlar el usuario como la función de devolución de llamada JavaScript que debe ejecutar el explorador, lo cual puede permitir que un atacante ejecute funciones JavaScript arbitrarias en cualquier página del dominio de ese punto final.
Explanation
La aplicación usa un parámetro bajo el control del atacante como nombre de una función JavaScript que ejecutará el explorador. Un atacante podría crear un sitio malintencionado que muestre primero una página de destino en el dominio de la aplicación y que luego haga referencia a una página vulnerable a fin de ejecutar una función JavaScript arbitraria en la página de destino. El impacto de este ataque es similar al de Cross-Site Scripting, aunque existen algunas restricciones importantes en cuanto a la vulnerabilidad. Si se permiten los caracteres alfanuméricos y de punto en los nombres de devolución de llamada, el atacante podría hacer referencia a los elementos de la página e interactuar con ellos.

Ejemplo 1: el código siguiente crea una respuesta JSONP en la que el usuario puede controlar el nombre de la función de devolución de llamada.


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


Para una solicitud como GET /api/latest.json?callback=myCallbackFunction, el método de controlador generará una respuesta como:


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>})


El atacante podría usar una etiqueta JavaScript Script para cargar la respuesta desde el punto final JSONP, lo que provocará la ejecución de la función myCallbackFunction. Un atacante podría usar un nombre de devolución de llamada diferente e interactuar con el DOM. Por ejemplo, podría usarse opener.document.body.someElemnt.firstChild.nextElementSibling.submit para colocar un formulario en la página de destino y enviarlo.
References
[1] Ben Hayak Same Origin Method Execution (SOME)
desc.semantic.java.same_origin_method_execution
Abstract
La aplicación refleja un parámetro que puede controlar el usuario como la función de devolución de llamada JavaScript que debe ejecutar el explorador, lo cual puede permitir que un atacante ejecute funciones JavaScript arbitrarias en cualquier página del dominio de ese punto final.
Explanation
La aplicación usa un parámetro bajo el control del atacante como nombre de una función JavaScript que ejecutará el explorador. Un atacante podría crear un sitio malintencionado que muestre primero una página de destino en el dominio de la aplicación y que luego haga referencia a una página vulnerable a fin de ejecutar una función JavaScript arbitraria en la página de destino. El impacto de este ataque es similar al de Cross-Site Scripting, aunque existen algunas restricciones importantes en cuanto a la vulnerabilidad. Si se permiten los caracteres alfanuméricos y de punto en los nombres de devolución de llamada, el atacante podría hacer referencia a los elementos de la página e interactuar con ellos.

Ejemplo 1: el código siguiente crea una respuesta JSONP en la que el usuario puede controlar el nombre de la función de devolución de llamada.


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


Para una solicitud como GET /api/latest.json?callback=myCallbackFunction, el método de controlador descrito en Example 1 generará una respuesta como:


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>})


El atacante podría usar una etiqueta JavaScript Script para cargar la respuesta desde el punto final JSONP, lo que provocará la ejecución de la función myCallbackFunction. Un atacante podría usar un nombre de devolución de llamada diferente e interactuar con el DOM. Por ejemplo, podría usarse opener.document.body.someElemnt.firstChild.nextElementSibling.submit para colocar un formulario en la página de destino y enviarlo.
References
[1] Ben Hayak Same Origin Method Execution (SOME)
desc.dataflow.scala.same_origin_method_execution
Abstract
La aplicación inicia una conexión de red a un sistema de terceros usando datos controlados por el usuario para crear el URI de recurso.
Explanation
Se produce una falsificación de solicitud del lado del servidor (SSRF, por sus siglas en inglés) cuando un atacante puede influir en una conexión de red hecha por el servidor de aplicaciones. La conexión de red se origina de la dirección IP interna del servidor de aplicaciones y un atacante puede usar esta conexión para eludir los controles de red y examinar o atacar recursos internos que, de otro modo, no estarían expuestos.

Ejemplo 1: En el ejemplo siguiente, un atacante puede controlar la dirección URL a la que se conecta el servidor.


...
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);


La habilidad del atacante para secuestrar la conexión de red depende de la parte específica del URI que puede controlar y de las bibliotecas usadas para establecer la conexión. Por ejemplo, al controlar el esquema URI, el atacante puede emplear protocolos que no sean http o https, como:

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

Un atacante puede aprovechar esta conexión de red secuestrada para efectuar los siguientes tipos de ataques:

- Examinar los puertos de los recursos de la intranet.
- Eludir los firewalls.
- Atacar a programas vulnerables ejecutándose en el servidor de aplicaciones o en la intranet.
- Atacar a aplicaciones web internas/externas con inyección de código o CSRF.
- Llevar a cabo un ataque de "poisoning" (contaminación) en la memoria caché de DNS.

desc.dataflow.apex.server_side_request_forgery
Abstract
La aplicación inicia una conexión de red a un sistema de terceros usando datos controlados por el usuario para crear el URI de recurso.
Explanation
Se produce una falsificación de solicitud del lado del servidor (SSRF, por sus siglas en inglés) cuando un atacante puede influir en una conexión de red hecha por el servidor de aplicaciones. La conexión de red se origina de la dirección IP interna del servidor de aplicaciones y un atacante puede usar esta conexión para eludir los controles de red y examinar o atacar recursos internos que, de otro modo, no estarían expuestos.

Ejemplo: En el ejemplo siguiente, un atacante puede controlar la dirección URL a la que se conecta el servidor.


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


La habilidad del atacante para secuestrar la conexión de red depende de la parte específica del URI que puede controlar y de las bibliotecas usadas para establecer la conexión. Por ejemplo, al controlar el esquema URI, el atacante puede emplear protocolos que no sean http o https, como:

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

Un atacante puede aprovechar esta conexión de red secuestrada para efectuar los ataques siguientes:

- Supervisión del puerto o de recursos de la intranet.
- Eludir los firewalls.
- Atacar a programas vulnerables ejecutándose en el servidor de aplicaciones o en la intranet.
- Atacar a aplicaciones web internas/externas con inyección de código o CSRF.
- Acceder a archivos locales con file:// scheme.
- En los sistemas de Windows, las rutas file:// scheme y UNC permiten a un atacante examinar y acceder a recursos compartidos internos.
- Llevar a cabo un ataque de "poisoning" (contaminación) en la memoria caché de DNS.

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
La aplicación inicia una conexión de red a un sistema de terceros usando datos controlados por el usuario para crear el URI de recurso.
Explanation
Se produce una falsificación de solicitud del lado del servidor (SSRF, por sus siglas en inglés) cuando un atacante puede influir en una conexión de red hecha por el servidor de aplicaciones. La conexión de red se origina de la dirección IP interna del servidor de aplicaciones y un atacante puede usar esta conexión para eludir los controles de red y examinar o atacar recursos internos que, de otro modo, no estarían expuestos.

Ejemplo: En el ejemplo siguiente, un atacante puede controlar la dirección URL a la que se conecta el servidor.


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


La habilidad del atacante para secuestrar la conexión de red depende de la parte específica del URI que puede controlar y de las bibliotecas usadas para establecer la conexión. Por ejemplo, al controlar el esquema URI, el atacante puede emplear protocolos que no sean http o https, como:

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

Un atacante puede aprovechar esta conexión de red secuestrada para efectuar los ataques siguientes:

- Examinar los puertos de los recursos de la intranet.
- Eludir los firewalls.
- Atacar a programas vulnerables ejecutándose en el servidor de aplicaciones o en la intranet.
- Atacar a aplicaciones web internas/externas con inyección de código o CSRF.
- Acceder a archivos locales con file:// scheme.
- En los sistemas de Windows, usar las rutas file:// scheme y UNC puede permitir a un atacante examinar y acceder a recursos compartidos internos.
- Llevar a cabo un ataque de "poisoning" (contaminación) en la memoria caché de DNS.

desc.dataflow.cpp.server_side_request_forgery
Abstract
La aplicación inicia una conexión de red a un sistema de terceros usando datos controlados por el usuario para crear el URI de recurso.
Explanation
Se produce una falsificación de solicitud del lado del servidor (SSRF, por sus siglas en inglés) cuando un atacante puede influir en una conexión de red hecha por el servidor de aplicaciones. La conexión de red se origina de la dirección IP interna del servidor de aplicaciones y un atacante puede usar esta conexión para eludir los controles de red y examinar o atacar recursos internos que, de otro modo, no estarían expuestos.

Ejemplo: En el ejemplo siguiente, un atacante puede controlar la dirección URL a la que se conecta el servidor.


...
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!));
...
}


La habilidad del atacante para secuestrar la conexión de red depende de la parte específica del URI que puede controlar y de las bibliotecas usadas para establecer la conexión. Por ejemplo, al controlar el esquema URI, el atacante puede emplear protocolos que no sean http o https, como:

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

Un atacante puede aprovechar esta conexión de red secuestrada para efectuar los ataques siguientes:

- Examinar los puertos de los recursos de la intranet.
- Eludir los firewalls.
- Atacar a programas vulnerables ejecutándose en el servidor de aplicaciones o en la intranet.
- Atacar a aplicaciones web internas/externas con inyección de código o CSRF.
- Acceder a archivos locales con file:// scheme.
- En los sistemas de Windows, las rutas file:// scheme y UNC permiten a un atacante examinar y acceder a recursos compartidos internos.
- Llevar a cabo un ataque de "poisoning" (contaminación) en la memoria caché de DNS.

desc.dataflow.dart.server_side_request_forgery
Abstract
La aplicación inicia una conexión de red a un sistema de terceros usando datos controlados por el usuario para crear el URI de recurso.
Explanation
Se produce un ataque Server-Side Request Forgery cuando un atacante puede influir en una conexión de red establecida por el servidor de aplicaciones. La conexión de red se origina de la dirección IP interna del servidor de aplicaciones y un atacante puede usar esta conexión para eludir los controles de red y examinar o atacar recursos internos que de otro modo no estarían expuestos.

Ejemplo: En el ejemplo siguiente, un atacante puede controlar la dirección URL a la que se conecta el servidor.


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


La habilidad del atacante para secuestrar la conexión de red depende de la parte específica del URI que puede controlar y de las bibliotecas usadas para establecer la conexión. Por ejemplo, al controlar el esquema URI, el atacante puede emplear protocolos que no sean http o https, como:

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

Un atacante puede aprovechar esta conexión de red secuestrada para efectuar los ataques siguientes:

- Examinar los puertos de los recursos de la intranet.
- Eludir los firewalls.
- Atacar a programas vulnerables ejecutándose en el servidor de aplicaciones o en la intranet.
- Atacar a aplicaciones web internas/externas con inyección de código o CSRF.
- Acceder a archivos locales con file:// scheme.
- Examinar y acceder a recursos compartidos internos en sistemas Windows con las rutas file:// scheme y UNC.
- Llevar a cabo un ataque de envenenamiento de caché DNS.

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
La aplicación inicia una conexión de red a un sistema de terceros usando datos controlados por el usuario para crear el URI de recurso.
Explanation
Se produce una falsificación de solicitud del lado del servidor (SSRF, por sus siglas en inglés) cuando un atacante puede influir en una conexión de red hecha por el servidor de aplicaciones. La conexión de red se origina de la dirección IP interna del servidor de aplicaciones y un atacante puede usar esta conexión para eludir los controles de red y examinar o atacar recursos internos que, de otro modo, no estarían expuestos.

Ejemplo: En el ejemplo siguiente, un atacante puede controlar la dirección URL a la que se conecta el servidor.


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


La habilidad del atacante para secuestrar la conexión de red depende de la parte específica del URI que puede controlar y de las bibliotecas usadas para establecer la conexión. Por ejemplo, al controlar el esquema URI, el atacante puede emplear protocolos que no sean http o https, como:

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

Un atacante puede aprovechar esta conexión de red secuestrada para efectuar los ataques siguientes:

- Supervisión del puerto o de recursos de la intranet.
- Eludir los firewalls.
- Atacar a programas vulnerables ejecutándose en el servidor de aplicaciones o en la intranet.
- Atacar a aplicaciones web internas/externas con inyección de código o CSRF.
- Acceder a archivos locales con file:// scheme.
- En los sistemas de Windows, las rutas file:// scheme y UNC permiten a un atacante examinar y acceder a recursos compartidos internos.
- Llevar a cabo un ataque de "poisoning" (contaminación) en la memoria caché de DNS.

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
La aplicación inicia una conexión de red a un sistema de terceros usando datos controlados por el usuario para crear el URI de recurso.
Explanation
Se produce una Server-Side Request Forgery cuando un atacante puede influir en una conexión de red hecha por el servidor de aplicaciones. La conexión de red se origina de la dirección IP interna del servidor de aplicaciones y un atacante puede usar esta conexión para eludir los controles de red y examinar o atacar recursos internos que, de otro modo, no estarían expuestos.

Ejemplo: En el ejemplo siguiente, un atacante puede controlar la dirección URL a la que se conecta el servidor.


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);
...


La habilidad del atacante para secuestrar la conexión de red depende de la parte específica del URI que puede controlar y de las bibliotecas usadas para establecer la conexión. Por ejemplo, al controlar el esquema URI, el atacante puede emplear protocolos que no sean http o https, como:

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

Un atacante puede aprovechar esta conexión de red secuestrada para efectuar los ataques siguientes:

- Supervisión del puerto o de recursos de la intranet.
- Eludir los firewalls.
- Atacar a programas vulnerables ejecutándose en el servidor de aplicaciones o en la intranet.
- Atacar a aplicaciones web internas/externas con inyección de código o CSRF.
- Acceder a archivos locales con file:// scheme.
- En los sistemas de Windows, las rutas file:// scheme y UNC permiten a un atacante examinar y acceder a recursos compartidos internos.
- Llevar a cabo un ataque de "poisoning" (contaminación) en la memoria caché de DNS.
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
La aplicación inicia una conexión de red a un sistema de terceros usando datos controlados por el usuario para crear el URI de recurso.
Explanation
Se produce una falsificación de solicitud del lado del servidor (SSRF, por sus siglas en inglés) cuando un atacante puede influir en una conexión de red hecha por el servidor de aplicaciones. La conexión de red se origina de la dirección IP interna del servidor de aplicaciones y un atacante puede usar esta conexión para eludir los controles de red y examinar o atacar recursos internos que, de otro modo, no estarían expuestos.

Ejemplo: En el ejemplo siguiente, un atacante puede controlar la dirección URL a la que se conecta el servidor.


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


La habilidad del atacante para secuestrar la conexión de red depende de la parte específica del URI que puede controlar y de las bibliotecas usadas para establecer la conexión. Por ejemplo, al controlar el esquema URI, el atacante puede emplear protocolos que no sean http o https, como:

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

Un atacante puede aprovechar esta conexión de red secuestrada para efectuar los ataques siguientes:

- Examinar los puertos de los recursos de la intranet.
- Eludir los firewalls.
- Atacar a programas vulnerables ejecutándose en el servidor de aplicaciones o en la intranet.
- Atacar a aplicaciones web internas/externas con inyección de código o CSRF.
- Acceder a archivos locales con file:// scheme.
- En los sistemas de Windows, las rutas file:// scheme y UNC permiten a un atacante examinar y acceder a recursos compartidos internos.
- Llevar a cabo un ataque de "poisoning" (contaminación) en la memoria caché de DNS.

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
La aplicación inicia una conexión de red a un sistema de terceros usando datos controlados por el usuario para crear el URI de recurso.
Explanation
Se produce un caso de Server-Side Request Forgery cuando un atacante puede influir en una conexión de red hecha por el servidor de aplicaciones. La conexión de red se originará de la dirección IP interna del servidor de aplicaciones y un atacante podrá usar esta conexión para eludir los controles de red y examinar o atacar recursos internos que, de otro modo, no estarían expuestos.

Ejemplo: En el ejemplo siguiente, un atacante puede controlar la dirección URL a la que se conecta el servidor.


$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);


La habilidad del atacante para secuestrar la conexión de red depende de la parte específica del URI que puede controlar y de las bibliotecas usadas para establecer la conexión. Por ejemplo, al controlar el esquema URI, el atacante puede emplear protocolos que no sean http o https, como:

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

Un atacante puede aprovechar esta conexión de red secuestrada para efectuar los ataques siguientes:

- Supervisión del puerto o de recursos de la intranet.
- Eludir los firewalls.
- Atacar a programas vulnerables ejecutándose en el servidor de aplicaciones o en la intranet.
- Atacar a aplicaciones web internas/externas con inyección de código o CSRF.
- Acceder a archivos locales con file:// scheme.
- En los sistemas de Windows, las rutas file:// scheme y UNC permiten a un atacante examinar y acceder a recursos compartidos internos.
- Llevar a cabo un ataque de "poisoning" (contaminación) en la memoria caché de DNS.

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
La aplicación inicia una conexión de red a un sistema de terceros usando datos controlados por el usuario para crear el URI de recurso.
Explanation
Se produce un caso de Server-Side Request Forgery cuando un atacante puede influir en una conexión de red hecha por el servidor de aplicaciones. La conexión de red se originará de la dirección IP interna del servidor de aplicaciones y un atacante podrá usar esta conexión para eludir los controles de red y examinar o atacar recursos internos que, de otro modo, no estarían expuestos.

Ejemplo: En el ejemplo siguiente, un atacante puede controlar la dirección URL a la que se conecta el servidor.


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


La habilidad del atacante para secuestrar la conexión de red depende de la parte específica del URI que puede controlar y de las bibliotecas usadas para establecer la conexión. Por ejemplo, al controlar el esquema URI, el atacante puede emplear protocolos que no sean http o https, como:

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

Un atacante puede aprovechar esta conexión de red secuestrada para efectuar los ataques siguientes:

- Supervisión del puerto o de recursos de la intranet.
- Eludir los firewalls.
- Atacar a programas vulnerables ejecutándose en el servidor de aplicaciones o en la intranet.
- Atacar a aplicaciones web internas/externas con inyección de código o CSRF.
- Acceder a archivos locales con file:// scheme.
- En los sistemas de Windows, las rutas file:// scheme y UNC permiten a un atacante examinar y acceder a recursos compartidos internos.
- Llevar a cabo un ataque de "poisoning" (contaminación) en la memoria caché de DNS.

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
La aplicación inicia una conexión de red a un sistema de terceros usando datos controlados por el usuario para crear el URI de recurso.
Explanation
Se produce un caso de Server-Side Request Forgery cuando un atacante puede influir en una conexión de red hecha por el servidor de aplicaciones. La conexión de red se originará de la dirección IP interna del servidor de aplicaciones y un atacante podrá usar esta conexión para eludir los controles de red y examinar o atacar recursos internos que, de otro modo, no estarían expuestos.

Ejemplo: En el ejemplo siguiente, un atacante puede controlar la dirección URL a la que se conecta el servidor.


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


La habilidad del atacante para secuestrar la conexión de red depende de la parte específica del URI que puede controlar y de las bibliotecas usadas para establecer la conexión. Por ejemplo, al controlar el esquema URI, el atacante puede emplear protocolos que no sean http o https, como:

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

Un atacante puede aprovechar esta conexión de red secuestrada para efectuar los ataques siguientes:

- Supervisión del puerto o de recursos de la intranet.
- Eludir los firewalls.
- Atacar a programas vulnerables ejecutándose en el servidor de aplicaciones o en la intranet.
- Atacar a aplicaciones web internas/externas con inyección de código o CSRF.
- Acceder a archivos locales con file:// scheme.
- En los sistemas de Windows, las rutas file:// scheme y UNC permiten a un atacante examinar y acceder a recursos compartidos internos.
- Llevar a cabo un ataque de "poisoning" (contaminación) en la memoria caché de DNS.
desc.dataflow.ruby.server_side_request_forgery
Abstract
La aplicación inicia una conexión de red a un sistema de terceros usando datos controlados por el usuario para crear el URI de recurso.
Explanation
Se produce un caso de Server-Side Request Forgery cuando un atacante puede influir en una conexión de red hecha por el servidor de aplicaciones. La conexión de red se originará de la dirección IP interna del servidor de aplicaciones y un atacante podrá usar esta conexión para eludir los controles de red y examinar o atacar recursos internos que, de otro modo, no estarían expuestos.

Ejemplo: En el ejemplo siguiente, un atacante puede controlar la dirección URL a la que se conecta el servidor.


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")
}
...
}


La habilidad del atacante para secuestrar la conexión de red depende de la parte específica del URI que puede controlar y de las bibliotecas usadas para establecer la conexión. Por ejemplo, al controlar el esquema URI, el atacante puede emplear protocolos que no sean http o https, como:

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

Un atacante puede aprovechar esta conexión de red secuestrada para efectuar los ataques siguientes:

- Supervisión del puerto o de recursos de la intranet.
- Eludir los firewalls.
- Atacar a programas vulnerables ejecutándose en el servidor de aplicaciones o en la intranet.
- Atacar a aplicaciones web internas/externas con inyección de código o CSRF.
- Acceder a archivos locales con file:// scheme.
- En los sistemas de Windows, las rutas file:// scheme y UNC permiten a un atacante examinar y acceder a recursos compartidos internos.
- Llevar a cabo un ataque de "poisoning" (contaminación) en la memoria caché de DNS.

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
Al permitir un control externo de la configuración del sistema se puede interrumpir el servicio o provocar que una aplicación se comporte de manera inesperada.
Explanation
Las vulnerabilidades a ataques Setting Manipulation se producen cuando un usuario malintencionado puede controlar los valores que determinan el comportamiento del sistema, administran los recursos específicos o, de alguna manera, afectan a la funcionalidad de la aplicación.

Como la categoría Setting Manipulation abarca una amplia variedad de funciones, cualquier intento de ilustrarla no tendrá más remedio que ser incompleta. En lugar de buscar una relación estrecha entre las funciones que se tratan en la categoría Setting Manipulation, analice la situación y piense en los tipos de valores del sistema que un usuario malintencionado no debería poder controlar.
desc.dataflow.dotnet.setting_manipulation
Abstract
Al permitir un control externo de la configuración del sistema se puede interrumpir el servicio o provocar que una aplicación se comporte de manera inesperada.
Explanation
Las vulnerabilidades a ataques Setting Manipulation se producen cuando un usuario malintencionado puede controlar los valores que determinan el comportamiento del sistema, administran los recursos específicos o, de alguna manera, afectan a la funcionalidad de la aplicación.

Como la categoría Setting Manipulation abarca una amplia variedad de funciones, cualquier intento de ilustrarla no tendrá más remedio que ser incompleta. En lugar de buscar una relación estrecha entre las funciones que se tratan en la categoría Setting Manipulation, analice la situación y piense en los tipos de valores del sistema que un usuario malintencionado no debería poder controlar.

Ejemplo 1: el siguiente código C acepta un número como uno de sus parámetros de línea de comandos y lo establece como ID de host del equipo actual.


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


Aunque un proceso debe disponer de privilegios para llamar satisfactoriamente a sethostid(), es posible que los usuarios sin privilegios puedan llamar al programa. El código de este ejemplo permite a la entrada de usuario controlar directamente el valor de un parámetro del sistema. Si un atacante especifica un valor malicioso para el ID de host, este puede identificar incorrectamente el equipo en la red o provocar otro comportamiento imprevisto.

En general, no permita que los datos proporcionados por el usuario o que de alguna otra forma no son de confianza controlen los valores confidenciales. La influencia que un usuario malintencionado obtiene mediante el control de estos valores no siempre es obvia, pero no subestime la creatividad de este usuario.
desc.dataflow.cpp.setting_manipulation
Abstract
Al permitir un control externo de la configuración del sistema se puede interrumpir el servicio o provocar que una aplicación se comporte de manera inesperada.
Explanation
Las vulnerabilidades a ataques Setting Manipulation se producen cuando un usuario malintencionado puede controlar los valores que determinan el comportamiento del sistema, administran los recursos específicos o, de alguna manera, afectan a la funcionalidad de la aplicación.



Como la categoría Setting Manipulation abarca una amplia variedad de funciones, cualquier intento de ilustrarla no tendrá más remedio que ser incompleta. En lugar de buscar una relación estrecha entre las funciones que se tratan en la categoría Setting Manipulation, analice la situación y piense en los tipos de valores del sistema que un usuario malintencionado no debería poder controlar.

Ejemplo: el siguiente fragmento de código COBOL lee los valores del terminal y los utiliza para calcular las opciones utilizadas para establecer el acceso a un objeto de cola.


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


En este ejemplo, un usuario malintencionado podría proporcionar una opción que permita el acceso compartido en lugar de exclusivo a la cola.

En general, no permita que los datos proporcionados por el usuario o que de alguna otra forma no son de confianza controlen los valores confidenciales. La influencia que un usuario malintencionado obtiene mediante el control de estos valores no siempre es obvia, pero no subestime la creatividad de este usuario.
desc.dataflow.cobol.setting_manipulation
Abstract
Al permitir un control externo de la configuración del sistema se puede interrumpir el servicio o provocar que una aplicación se comporte de manera inesperada.
Explanation
Las vulnerabilidades a ataques Setting Manipulation se producen cuando un usuario malintencionado puede controlar los valores que determinan el comportamiento del sistema, administran los recursos específicos o, de alguna manera, afectan a la funcionalidad de la aplicación.

Como la categoría Setting Manipulation abarca una amplia variedad de funciones, cualquier intento de ilustrarla no tendrá más remedio que ser incompleta. En lugar de buscar una relación estrecha entre las funciones que se tratan en la categoría Setting Manipulation, analice la situación y piense en los tipos de valores del sistema que un usuario malintencionado no debería poder controlar.

Ejemplo: el siguiente código lee un número de un formulario web y lo utiliza para establecer el valor de tiempo de espera en un archivo de inicialización.


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


Como el valor de Form.newTimeout se utiliza para especificar un tiempo de espera, un usuario malintencionado puede ejecutar un ataque de denegación de servicio (DoS, Denial of Service) contra la aplicación especificando un número lo suficientemente grande.

En general, no permita que los datos proporcionados por el usuario o que de alguna otra forma no son de confianza controlen los valores confidenciales. La influencia que un usuario malintencionado obtiene mediante el control de estos valores no siempre es obvia, pero no subestime la creatividad de este usuario.
desc.dataflow.cfml.setting_manipulation
Abstract
Al permitir un control externo de la configuración del sistema, se puede interrumpir el servicio o generar un comportamiento inesperado en la aplicación.
Explanation
Las vulnerabilidades a ataques Setting Manipulation se producen cuando un usuario malintencionado puede controlar los valores que determinan el comportamiento del sistema, administran los recursos específicos o, de alguna manera, afectan a la funcionalidad de la aplicación.



Como la categoría Setting Manipulation abarca una amplia variedad de funciones, cualquier intento de ilustrarla tendrá un resultado incompleto inevitablemente. En lugar de buscar una relación estrecha entre las funciones que se tratan en la categoría Setting Manipulation, analice la situación y piense en los tipos de valores del sistema que un usuario malintencionado no debería poder controlar.

Ejemplo 1: El siguiente fragmento de código establece una variable de entorno con datos controlados por el usuario.


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


En este ejemplo, un atacante puede establecer cualquier variable de entorno arbitraria y afectar el funcionamiento de otras aplicaciones.

En general, no permita que los datos proporcionados por el usuario o que no son de confianza controlen los valores confidenciales. La influencia que un atacante obtiene mediante el control de estos valores no siempre es obvia, pero no subestime la creatividad del atacante.
desc.dataflow.golang.setting_manipulation
Abstract
Al permitir un control externo de la configuración del sistema se puede interrumpir el servicio o provocar que una aplicación se comporte de manera inesperada.
Explanation
Las vulnerabilidades a ataques Setting Manipulation se producen cuando un usuario malintencionado puede controlar los valores que determinan el comportamiento del sistema, administran los recursos específicos o, de alguna manera, afectan a la funcionalidad de la aplicación.



Como la categoría Setting Manipulation abarca una amplia variedad de funciones, cualquier intento de ilustrarla no tendrá más remedio que ser incompleta. En lugar de buscar una relación estrecha entre las funciones que se tratan en la categoría Setting Manipulation, analice la situación y piense en los tipos de valores del sistema que un usuario malintencionado no debería poder controlar.

Ejemplo 1: el siguiente fragmento de código de Java lee una cadena desde HttpServletRequest y la establece como el catálogo activo para una Connection de base de datos.


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


En este ejemplo, un usuario malintencionado podría provocar un error al proporcionar un nombre de catálogo inexistente o al conectarse a una parte no autorizada de la base de datos.

En general, no permita que los datos proporcionados por el usuario o que de alguna otra forma no son de confianza controlen los valores confidenciales. La influencia que un usuario malintencionado obtiene mediante el control de estos valores no siempre es obvia, pero no subestime la creatividad de este usuario.
desc.dataflow.java.setting_manipulation
Abstract
Al permitir un control externo de la configuración del sistema, se puede interrumpir el servicio o generar un comportamiento inesperado en la aplicación.
Explanation
Las vulnerabilidades a ataques Setting Manipulation se producen cuando un usuario malintencionado puede controlar los valores que determinan el comportamiento del sistema, administran los recursos específicos o, de alguna manera, afectan a la funcionalidad de la aplicación.



Como la categoría Setting Manipulation abarca una amplia variedad de funciones, cualquier intento de ilustrarla no tendrá más remedio que ser incompleta. En lugar de buscar una relación estrecha entre las funciones que se tratan en la categoría Setting Manipulation, analice la situación y piense en los tipos de valores del sistema que un usuario malintencionado no debería poder controlar.

Ejemplo 1: el siguiente segmento de código Node.js lee una cadena de una variable de solicitud http.IncomingMessage y la utiliza para establecer marcas de línea de comandos de V8 adicionales.


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


En este ejemplo, un atacante podría establecer varias marcas diferentes en la VM, lo que podría producir un comportamiento impredecible, como el bloqueo del programa o una posible pérdida de datos.

En general, no permita que los datos proporcionados por el usuario o que de alguna otra forma no son de confianza controlen los valores confidenciales. La influencia que un usuario malintencionado obtiene mediante el control de estos valores no siempre es obvia, pero no subestime la creatividad de este usuario.
desc.dataflow.javascript.setting_manipulation
Abstract
Al permitir un control externo de la configuración del sistema se puede interrumpir el servicio o provocar que una aplicación se comporte de manera inesperada.
Explanation
Las vulnerabilidades a ataques Setting Manipulation se producen cuando un usuario malintencionado puede controlar los valores que determinan el comportamiento del sistema, administran los recursos específicos o, de alguna manera, afectan a la funcionalidad de la aplicación.



Como la categoría Setting Manipulation abarca una amplia variedad de funciones, cualquier intento de ilustrarla no tendrá más remedio que ser incompleta. En lugar de buscar una relación estrecha entre las funciones que se tratan en la categoría Setting Manipulation, analice la situación y piense en los tipos de valores del sistema que un usuario malintencionado no debería poder controlar.

Ejemplo 1: el siguiente fragmento de código PHP lee un parámetro de una solicitud HTTP y lo establece como el catálogo activo para una conexión de base de datos.


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


En este ejemplo, un usuario malintencionado podría provocar un error al proporcionar un nombre de catálogo inexistente o al conectarse a una parte no autorizada de la base de datos.

En general, no permita que los datos proporcionados por el usuario o que de alguna otra forma no son de confianza controlen los valores confidenciales. La influencia que un usuario malintencionado obtiene mediante el control de estos valores no siempre es obvia, pero no subestime la creatividad de este usuario.
desc.dataflow.php.setting_manipulation
Abstract
Al permitir un control externo de la configuración del sistema se puede interrumpir el servicio o provocar que una aplicación se comporte de manera inesperada.
Explanation
Las vulnerabilidades a ataques Setting Manipulation se producen cuando un usuario malintencionado puede controlar los valores que determinan el comportamiento del sistema, administran los recursos específicos o, de alguna manera, afectan a la funcionalidad de la aplicación.



Como la categoría Setting Manipulation abarca una amplia variedad de funciones, cualquier intento de ilustrarla no tendrá más remedio que ser incompleta. En lugar de buscar una relación estrecha entre las funciones que se tratan en la categoría Setting Manipulation, analice la situación y piense en los tipos de valores del sistema que un usuario malintencionado no debería poder controlar.

Ejemplo 1: el siguiente fragmento de código establece una variable de entorno usando datos controlados por el usuario.


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


En este ejemplo, un atacante podría establecer cualquier variable de entorno arbitraria y afectar al funcionamiento de otras aplicaciones.

En general, no permita que los datos proporcionados por el usuario o que de alguna otra forma no son de confianza controlen los valores confidenciales. La influencia que un usuario malintencionado obtiene mediante el control de estos valores no siempre es obvia, pero no subestime la creatividad de este usuario.
desc.dataflow.python.setting_manipulation
Abstract
Al permitir un control externo de la configuración del sistema se puede interrumpir el servicio o provocar que una aplicación se comporte de manera inesperada.
Explanation
Las vulnerabilidades a ataques Setting Manipulation se producen cuando un usuario malintencionado puede controlar los valores que determinan el comportamiento del sistema, administran los recursos específicos o, de alguna manera, afectan a la funcionalidad de la aplicación.



Como la categoría Setting Manipulation abarca una amplia variedad de funciones, cualquier intento de ilustrarla no tendrá más remedio que ser incompleta. En lugar de buscar una relación estrecha entre las funciones que se tratan en la categoría Setting Manipulation, analice la situación y piense en los tipos de valores del sistema que un usuario malintencionado no debería poder controlar.

Ejemplo: El siguiente fragmento de código Scala lee un parámetro de una solicitud HTTP y lo establece como el catálogo activo para una Connection de base de datos.


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


En este ejemplo, un usuario malintencionado podría provocar un error al proporcionar un nombre de catálogo inexistente o al conectarse a una parte no autorizada de la base de datos.

En general, no permita que los datos proporcionados por el usuario o que de alguna otra forma no son de confianza controlen los valores confidenciales. La influencia que un usuario malintencionado obtiene mediante el control de estos valores no siempre es obvia, pero no subestime la creatividad de este usuario.
desc.dataflow.scala.setting_manipulation
Abstract
Al permitir un control externo de la configuración del sistema se puede interrumpir el servicio o provocar que una aplicación se comporte de manera inesperada.
Explanation
Las vulnerabilidades a ataques Setting Manipulation se producen cuando un usuario malintencionado puede controlar los valores que determinan el comportamiento del sistema, administran los recursos específicos o, de alguna manera, afectan a la funcionalidad de la aplicación.

Como la categoría Setting Manipulation abarca una amplia variedad de funciones, cualquier intento de ilustrarla no tendrá más remedio que ser incompleta. En lugar de buscar una relación estrecha entre las funciones que se tratan en la categoría Setting Manipulation, analice la situación y piense en los tipos de valores del sistema que un usuario malintencionado no debería poder controlar.

Ejemplo 1: El siguiente código configura el controlador de registros SQL y utiliza un valor que controla el usuario.


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


En general, no permita que los datos proporcionados por el usuario o que de alguna otra forma no son de confianza controlen los valores confidenciales. La influencia que un usuario malintencionado obtiene mediante el control de estos valores no siempre es obvia, pero no subestime la creatividad de este usuario.
desc.dataflow.swift.setting_manipulation
Abstract
Al permitir un control externo de la configuración del sistema se puede interrumpir el servicio o provocar que una aplicación se comporte de manera inesperada.
Explanation
Las vulnerabilidades a ataques Setting Manipulation se producen cuando un usuario malintencionado puede controlar los valores que determinan el comportamiento del sistema, administran los recursos específicos o, de alguna manera, afectan a la funcionalidad de la aplicación.



Como la categoría Setting Manipulation abarca una amplia variedad de funciones, cualquier intento de ilustrarla no tendrá más remedio que ser incompleta. En lugar de buscar una relación estrecha entre las funciones que se tratan en la categoría Setting Manipulation, analice la situación y piense en los tipos de valores del sistema que un usuario malintencionado no debería poder controlar.

Ejemplo 1: el siguiente fragmento de código VB lee una cadena de un objeto Request y la establece como el catálogo activo para una base de datos 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")
...


En este ejemplo, un usuario malintencionado podría provocar un error al proporcionar un nombre de catálogo inexistente o al conectarse a una parte no autorizada de la base de datos.

En general, no permita que los datos proporcionados por el usuario o que de alguna otra forma no son de confianza controlen los valores confidenciales. La influencia que un usuario malintencionado obtiene mediante el control de estos valores no siempre es obvia, pero no subestime la creatividad de este usuario.
desc.dataflow.vb.setting_manipulation
Abstract
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Se producen errores de SQL Injection cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos utilizados para crear dinámicamente una consulta SQL.
Ejemplo 1: el código siguiente crea y ejecuta dinámicamente una consulta SQL diseñada para buscar facturas que pertenezcan a un usuario. La consulta restringe los elementos que se muestran a aquellos donde usuario es igual al nombre de usuario del usuario actualmente autenticado.


...
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).
...


La consulta que este código intenta ejecutar es la siguiente (siempre que v_account and v_reference no estén en blanco):


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


Sin embargo, como esta consulta se construye de forma dinámica concatenando una cadena de consulta de base constante y una cadena de entrada de usuario, es una candidata a ataques de SQL Injection. Si un usuario malintencionado introduce la cadena "abc` OR MANDT NE `+" para v_reference y la cadena '1000' para v_account, entonces la consulta será de la siguiente forma:


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 `+`.


La adición de la condición OR MANDT NE `+` hace que la cláusula WHERE se evalúe siempre como verdadera porque el campo de cliente nunca puede ser igual al literal +, de manera que la consulta se hace lógicamente equivalente a la consulta mucho más simple:


SELECT * FROM invoice_items
INTO CORRESPONDING FIELDS OF TABLE itab_items.


Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla invoice_items, independientemente del usuario especificado.

Ejemplo 2: en este ejemplo, consideramos el uso de la API de ADBC en un programa que permita a los empleados actualizar sus direcciones.


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 ).



Si un empleado descontento escribe una cadena como "ABC` SALARY = `1000000" para el parámetro p_street, la aplicación permite que la base de datos se actualice con el ascenso de salario.

Un enfoque tradicional a la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

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
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Se producen errores de SQL Injection cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos se utilizan para crear dinámicamente una consulta SQL.

Ejemplo 1: el siguiente código crea y ejecuta una consulta SQL de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.


...
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();
...


La consulta intenta ejecutar el código siguiente:


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


Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:


SELECT * FROM items;


Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'; DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:


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

DELETE FROM items;

--'


Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:


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

DELETE FROM items;

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


Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados podrán evitar algunos ataques, pero no harán que la aplicación quede protegida frente a ataques de SQL Injection.
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
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Se producen errores de SQL Injection cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos se utilizan para crear dinámicamente una consulta SQL.
Ejemplo 1: el siguiente código crea y ejecuta una consulta SQL de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos en los que owner coincide con el nombre de usuario del usuario actualmente autenticado.


...
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);
...


La consulta intenta ejecutar el código siguiente:


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


Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:


SELECT * FROM items;


Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'); DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:


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

DELETE FROM items;

--'


Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:


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

DELETE FROM items;

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


Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados podrán evitar algunos ataques, pero no harán que la aplicación quede protegida frente a ataques de SQL Injection.
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
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Se producen errores de SQL Injection cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos se utilizan para crear dinámicamente una consulta SQL.
Ejemplo 1: el siguiente código crea y ejecuta una consulta SQL de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.


...
ctx.getAuthUserName(&userName); {
CString query = "SELECT * FROM items WHERE owner = '"
+ userName + "' AND itemname = '"
+ request.Lookup("item") + "'";
dbms.ExecuteSQL(query);
...
Ejemplo 2:como alternativa, puede obtener un resultado similar con SQLite utilizando el siguiente código:


...
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);
...


La consulta intenta ejecutar el código siguiente:


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


Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:


SELECT * FROM items;


Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 3: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'); DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:


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

DELETE FROM items;

--'


Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso, el carácter de comentario se utiliza para la comilla simple final que se ha dejado en la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:


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

DELETE FROM items;

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


Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados podrán evitar algunos ataques, pero no harán que la aplicación quede protegida frente a ataques de SQL Injection.
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
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Se producen errores de SQL Injection cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos utilizados para crear dinámicamente una consulta SQL.
Ejemplo 1: el siguiente código crea y ejecuta de forma dinámica una consulta SQL diseñada para buscar elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.


...
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.
...


La consulta que este código tiene la intención de ejecutar es la siguiente:


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


Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itm, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:


SELECT * FROM items;


Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo, se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'; DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:


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

DELETE FROM items;

--'


Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque daría como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos compatibles este tipo de ataque permitirá la ejecución de comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (-); estos indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso los comentarios se utilizan para quitar la comilla simple al final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:


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

DELETE FROM items;

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


Un enfoque tradicional a la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados podrán evitar algunos ataques, pero no harán que la aplicación quede protegida frente a ataques de SQL Injection.
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
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Se producen errores de SQL Injection cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos utilizados para crear dinámicamente una consulta SQL.
Ejemplo 1: el siguiente código crea y ejecuta una consulta SQL de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario autenticado actualmente.


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


La consulta intenta ejecutar el código siguiente:


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


Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si Form.ID no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para Form.ID, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:


SELECT * FROM items;


Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario hacker introduce la cadena "hacker'); DELETE FROM items; --" para Form.ID, la consulta se convertirá en las dos consultas siguientes:


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

DELETE FROM items;

--'


Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:


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

DELETE FROM items;

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


Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados podrán evitar algunos ataques, pero no harán que la aplicación quede protegida frente a ataques de SQL Injection.
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
Usar Java J2EE PersistenceAPI para ejecutar una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza puede permitir que un atacante modifique el significado de la instrucción o ejecute comandos SQL arbitrarios.
Explanation
Se producen errores SQL Injection cuando:

1. Los datos se introducen en un programa desde un origen que no es de confianza.



2. Los datos se utilizan para crear dinámicamente una consulta SQL.

Ejemplo 1: El código siguiente crea y ejecuta dinámicamente una consulta SQL que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.


...
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);
}
...


La consulta intenta ejecutar el código siguiente:


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


Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un atacante con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la siguiente consulta más simple:


SELECT * FROM items;


Esta simplificación de la consulta permite que el atacante eluda el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'; DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:


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

DELETE FROM items;

--'


Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, este tipo de ataque deja que el usuario malintencionado ejecute comandos arbitrarios en las bases de datos que permiten la ejecución por lotes.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso, el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:


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

DELETE FROM items;

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


Un enfoque tradicional para impedir ataques SQL Injection es tratarlos como un problema de validación de entrada y aceptar solo los caracteres de una lista de valores seguros permitidos o bien identificar y excluir una lista de valores potencialmente malintencionados (lista de denegación). Las listas de valores permitidos pueden ser un medio eficaz de aplicar estrictas reglas de validación de entrada, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, la lista de denegación presenta enormes lagunas que la hacen ineficaz para impedir los ataques SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

La asignación manual de escapes a los caracteres de la entrada de las consultas SQL puede servir de ayuda, pero no garantizará la seguridad de la aplicación frente a los ataques SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden transferir a sus parámetros. Sin embargo, existen muchas formas de saltar estas limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados pueden evitar algunos tipos de ataques, pero no garantizarán la protección de la aplicación frente a ataques SQL Injection.
desc.dataflow.dart.sql_injection
Abstract
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza permite que un atacante modifique el significado de la instrucción o ejecute comandos SQL arbitrarios.
Explanation
Se producen errores SQL Injection cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos se utilizan para crear dinámicamente una consulta SQL.
Ejemplo 1: El código siguiente crea y ejecuta dinámicamente una consulta SQL que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.


...
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)
...


La consulta intenta ejecutar el código siguiente:


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


Sin embargo, como el código crea dinámicamente la consulta mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada de usuario, la consulta solo se comporta correctamente si itemName no contiene un carácter de comilla simple. Si un atacante con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la siguiente consulta más simple:


SELECT * FROM items;


Esta simplificación de la consulta permite que el atacante eluda el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'; DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:


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

DELETE FROM items;

--'


Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, este tipo de ataque deja que el usuario malintencionado ejecute comandos arbitrarios en las bases de datos que permiten la ejecución por lotes.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no se debe ejecutar. [4]. En este caso, el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un atacante escribe la cadena "name'; DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crean las tres instrucciones válidas siguientes:


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

DELETE FROM items;

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


Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes pueden:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

La asignación manual de secuencias de escape a los caracteres de la entrada de las consultas SQL puede servir de ayuda, pero no garantiza la seguridad de la aplicación frente a los ataques de SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden transferir a sus parámetros. Sin embargo, existen muchas formas de saltar estas limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados pueden evitar algunos ataques, pero no garantizan la protección de la aplicación frente a ataques de SQL Injection.
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
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Se producen errores de SQL Injection cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos se utilizan para crear dinámicamente una consulta SQL.

Ejemplo 1: el siguiente código crea y ejecuta una consulta SQL de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.


...
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);
...


La consulta intenta ejecutar el código siguiente:


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


Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:


SELECT * FROM items;


Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'; DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:


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

DELETE FROM items;

--'


Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:


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

DELETE FROM items;

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


Algunos piensan que en el mundo de las plataformas móviles, las vulnerabilidades de las aplicaciones web clásicas como la SQL Injection no tienen ningún sentido: ¿por qué se atacaría a sí mismo un usuario? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 3: el siguiente código adapta el Example 1 a la plataforma Android.


...
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);
...


Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados podrán evitar algunos ataques, pero no harán que la aplicación quede protegida frente a ataques de SQL Injection.
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
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Se producen errores de SQL Injection cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos se utilizan para crear dinámicamente una consulta SQL.

Ejemplo 1: el siguiente código crea y ejecuta una consulta SQL de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.


...
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);
}
)
...


La consulta intenta ejecutar el código siguiente:


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


Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:


SELECT * FROM items;


Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'; DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:


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

DELETE FROM items;

--'


Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:


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

DELETE FROM items;

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


Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados podrán evitar algunos ataques, pero no harán que la aplicación quede protegida frente a ataques de SQL Injection.
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
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Se producen errores de SQL Injection cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos se utilizan para crear dinámicamente una consulta SQL.

Ejemplo 1: el siguiente código crea y ejecuta una consulta SQL de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.


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


La consulta intenta ejecutar el código siguiente:


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


Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:


SELECT * FROM items;


Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'; DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:


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

DELETE FROM items;

--'


Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:


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

DELETE FROM items;

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


Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados podrán evitar algunos ataques, pero no harán que la aplicación quede protegida frente a ataques de SQL Injection.
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
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Se producen errores de SQL Injection cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos utilizados para crear dinámicamente una consulta SQL.
Ejemplo 1: El código siguiente crea y ejecuta dinámicamente una consulta SQL diseñada para buscar elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.


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;


La consulta que este código tiene la intención de ejecutar es la siguiente:


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


Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itm, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:


SELECT * FROM items;


Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo, se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'; DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:


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

DELETE FROM items;

--'


Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque daría como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos compatibles este tipo de ataque permitirá la ejecución de comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (-); estos indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso los comentarios se utilizan para quitar la comilla simple al final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:


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

DELETE FROM items;

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


Un enfoque tradicional a la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Tal y como se ha mostrado en esta serie de ejemplos, los procedimientos almacenados pueden ser tan vulnerables como los otros tipos de código. Los procedimientos almacenados pueden ayudar a evitar ciertos tipos de vulnerabilidades de seguridad, pero no harán que la aplicación sea inherentemente segura frente a ataques de SQL Injection.
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
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Se producen errores de SQL Injection cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos se utilizan para crear dinámicamente una consulta SQL.

Ejemplo 1: el siguiente código crea y ejecuta una consulta SQL de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.


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


La consulta intenta ejecutar el código siguiente:


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


Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:


SELECT * FROM items;


Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'; DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:


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

DELETE FROM items;

--'


Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:


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

DELETE FROM items;

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


Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados podrán evitar algunos ataques, pero no harán que la aplicación quede protegida frente a ataques de SQL Injection.
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
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Se producen errores de SQL Injection cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

En este caso, Fortify Static Code Analyzer no pudo determinar si el origen de los datos era de confianza.

2. Los datos se utilizan para crear dinámicamente una consulta SQL.

Ejemplo 1: el siguiente código crea y ejecuta una consulta SQL de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.


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


La consulta intenta ejecutar el código siguiente:


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


Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:


SELECT * FROM items;


Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Debido a que Ruby no es un lenguaje estático, también habilita otros puntos de inyección en consultas SQL que no están disponibles en lenguajes estáticos.
Ejemplo 2: el siguiente código crea y ejecuta una consulta SQL de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.


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


En este caso, la consulta SQL que se espera ejecutar es:


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

Puede ver esta vez que estamos protegidos frente a un atacante especificando una comilla simple dentro de itemName aparentemente hemos evitado la vulnerabilidad de SQL Injection. Sin embargo, como Ruby no es un lenguaje estático, y a pesar de que esperamos que id sea un entero de algún tipo, no tiene por qué ser necesariamente un número, ya que se asigna a partir de la entrada del usuario. Por lo tanto, si un usuario malintencionado logra cambiar el valor de id a 1 OR id!=1--, dado que no se comprueba si id es realmente un número, la consulta SQL se convierte en:


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


Tenga en cuenta el par final de guiones (--) que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. Por este motivo, ahora simplemente ejecuta una consulta SQL formada por:


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


Ahora seleccionamos todo el contenido de la tabla, independientemente de si el valor de id es 1 o no, lo que por supuesto equivale a todo el contenido de la tabla.

Muchos servidores de base de datos permiten la ejecución simultánea de varias instrucciones SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.

Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados podrán evitar algunos ataques, pero no harán que la aplicación quede protegida frente a ataques de SQL Injection.
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
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Los errores SQL Injection se producen cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos se utilizan para crear dinámicamente una consulta SQL.

Ejemplo 1: El código siguiente crea y ejecuta dinámicamente una consulta SQL que busca usuarios que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario proporcionado como parámetro de ruta.


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


La consulta intenta ejecutar el código siguiente:


SELECT * FROM users
WHERE name = <userName>


Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si userName no contiene un carácter de comilla simple. Si un atacante con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para userName, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la siguiente consulta más simple:


SELECT * FROM users;


Esta simplificación de la consulta permite al usuario malintencionado eludir el requisito de que la consulta solo debe devolver usuarios que sean propiedad del usuario especificado; la consulta devuelve ahora todas las entradas almacenadas en la tabla users, independientemente del usuario especificado.

Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas.
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

La asignación manual de escapes a los caracteres de la entrada de las consultas SQL puede servir de ayuda, pero no garantizará la seguridad de la aplicación frente a los ataques SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de saltar estas limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados pueden evitar algunos ataques, pero no garantizarán la protección de la aplicación frente a ataques SQL Injection.
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
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Los errores SQL Injection se producen cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos se utilizan para crear dinámicamente una consulta SQL.
Ejemplo 1: El código siguiente crea y ejecuta dinámicamente una consulta SQL que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde owner coincide con el nombre de usuario del usuario autenticado actualmente.


...
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 {
...
}
}
...


La consulta intenta ejecutar el código siguiente:


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


Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un atacante con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la siguiente consulta más simple:


SELECT * FROM items;


Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 3: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'); DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:


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

DELETE FROM items;

--'


Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso, el carácter de comentario se utiliza para la comilla simple final que se ha dejado en la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:


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

DELETE FROM items;

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


Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

La asignación manual de escapes a los caracteres de la entrada de las consultas SQL puede servir de ayuda, pero no garantizará la seguridad de la aplicación frente a los ataques SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de saltar estas limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados pueden evitar algunos ataques, pero no garantizarán la protección de la aplicación frente a ataques SQL Injection.
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
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Se producen errores de SQL Injection cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos se utilizan para crear dinámicamente una consulta SQL.

Ejemplo 1: el siguiente código crea y ejecuta una consulta SQL de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.


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


La consulta intenta ejecutar el código siguiente:


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


Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si itemName no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name' OR 'a'='a" para itemName, la consulta se convertirá en lo siguiente:


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


La adición de la condición OR 'a'='a' hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:


SELECT * FROM items;


Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla items, independientemente del propietario especificado.

Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el Example 1. Si un usuario malintencionado con el nombre de usuario wiley introduce la cadena "name'; DELETE FROM items; --" para itemName, la consulta se convertirá en las dos consultas siguientes:


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

DELETE FROM items;

--'


Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.

Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general tendría posibilidades de efectuarse con un truco similar al que se muestra en el Example 1. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", se crearán las tres instrucciones válidas siguientes:


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

DELETE FROM items;

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


Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:

- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados

Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.

Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados podrán evitar algunos ataques, pero no harán que la aplicación quede protegida frente a ataques de SQL Injection.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red.
Ejemplo: El código siguiente imprime la información de versión de SAPFTP en la pantalla:


...
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.
...


Dependiendo de la configuración de la pantalla de selección, esta información se puede volcar en una pantalla o enviar directamente a una impresora. En algunos casos la información de versión indica con precisión al usuario malintencionado a qué tipo de ataque será vulnerable el sistema. De la misma forma, los mensajes de error pueden indicar al usuario malintencionado el ataque al que el sistema es vulnerable. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL Injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.
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
La revelación de datos del sistema o de información de depuración podría permitir a un adversario realizar un plan de ataque.
Explanation
Se producen fugas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red.

Ejemplo 1: El siguiente código imprime un seguimiento de pila en una consola "Debug" o en un archivo de registro:


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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o exponer ante un usuario remoto. Por ejemplo, con los mecanismos de scripts es sencillo redirigir la información de salida de un "Error típico" o una "Salida estándar" a un archivo o a otro programa. De forma alternativa, el sistema que ejecuta el programa podría tener un mecanismo de registro remoto, como un servidor como "syslog", que envía los registros a un dispositivo remoto. Durante este proceso, no existe forma alguna de saber dónde se puede terminar mostrando esta información.

En algunos casos el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la ruta de búsqueda podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han puesto los administradores a la hora de configurar el programa.
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
Revelar datos del sistema o la información de depuración permite a un adversario obtener información sobre el sistema y elaborar un plan de ataque.
Explanation
Se producen pérdidas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red. Las fugas externas pueden servir de ayuda a un atacante al revelar datos específicos de los sistemas operativos, los nombres completos de rutas de acceso, la existencia de nombres de usuario o las ubicaciones de los archivos de configuración. Las fugas externas son más graves que las fugas de información internas, cuyo acceso es más complicado para los atacantes.

Ejemplo 1: El siguiente código filtra información de excepción en el elemento <apex:messages/> de una página de Visualforce:


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


Esta información se puede exponer a un usuario remoto. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red.
Ejemplo 1: el siguiente código genera pérdidas de información de Excepción en la respuesta HTTP:


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


Esta información se puede exponer a un usuario remoto. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red.
Ejemplo 1: El siguiente código genera fugas de información del sistema mediante un 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);


Esta información se puede exponer a un usuario remoto. En algunos casos, el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque será vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la ruta de búsqueda podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han puesto los administradores a la hora de configurar el programa.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red.
Ejemplo 1: El siguiente código muestra el código de error SQLCODE y el mensaje de error SQlERRMC asociados al comando SQL que produjo el error para el terminal.


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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o exponer ante un usuario remoto. En algunos casos el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque es vulnerable el sistema. En el Example 1, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red.
Ejemplo: el siguiente código captura una excepción e imprime su mensaje en la página.


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


En función de la configuración del sistema, esta información se puede escribir en un archivo de registro o exponer ante un usuario remoto. En algunos casos el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL Injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red.

Ejemplo 1: El siguiente ejemplo genera fugas de información del sistema mediante una respuesta HTTP.


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


En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de iSQL Injection. Otros mensajes de error pueden revelar pistas más evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red. Las fugas externas pueden revelar datos específicos de los sistemas operativos, los nombres completos de rutas de acceso, la existencia de nombres de usuario o las ubicaciones de los archivos de configuración. Estas son más graves que las fugas de información internas, cuyo acceso es más complicado para los atacantes.

Ejemplo 1: La siguiente propiedad de configuración de Spring Boot fuga información de seguimiento de pila en la respuesta HTTP:


server.error.include-stacktrace=always


Esta información se puede exponer a un usuario remoto. En algunos casos, el mensaje de error revela con exactitud los tipos de ataques a los que es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL injection. Otros mensajes de error pueden revelar pistas más indirectas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.
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
La revelación de datos del sistema o de información de depuración podría permitir a un adversario realizar un plan de ataque.
Explanation
Se producen pérdidas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red. Las pérdidas externas pueden ayudar a los usuarios malintencionados al revelar datos específicos de los sistemas operativos, nombres de rutas de acceso completos, la existencia de nombres de usuario o las ubicaciones de los archivos de configuración, y son más graves que las pérdidas de información internas, a las que los usuarios malintencionados tienen más dificultades para acceder.

Ejemplo 1: el siguiente código genera pérdidas de información de excepción en un área de texto de una página web:


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


Esta información se puede exponer a un usuario remoto. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.
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
La revelación de datos del sistema o de información de depuración podría permitir a un adversario realizar un plan de ataque.
Explanation
Se producen pérdidas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red. Las pérdidas externas pueden ayudar a los usuarios malintencionados al revelar datos específicos de los sistemas operativos, nombres de rutas de acceso completos, la existencia de nombres de usuario o las ubicaciones de los archivos de configuración, y son más graves que las pérdidas de información internas, a las que los usuarios malintencionados tienen más dificultades para acceder.

Ejemplo 1: el siguiente código genera pérdidas de información de Excepción en la respuesta HTTP:


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


Esta información se puede exponer a un usuario remoto. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.

Las pérdidas de información también son motivo de preocupación en los entornos informáticos móviles. En las plataformas móviles, las aplicaciones se descargan desde diversos orígenes y se ejecutan junto con otras aplicaciones en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que los desarrolladores deben tener cuidado con la información que incluyen en los mensajes dirigidos a otras aplicaciones que se ejecutan en el dispositivo.

Ejemplo 2: El siguiente código difunde el seguimiento de pila de una excepción detectada a todos los destinatarios de Android registrados.

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


Se trata de otra situación específica de las plataformas móviles. La mayoría de los dispositivos móviles ahora implementa un protocolo de transmisión de datos en proximidad (NFC) para compartir rápidamente la información entre dispositivos utilizando la comunicación de radio. Funciona cuando se colocan dispositivos cerca los unos de los otros o tocándose. Aunque el campo de la comunicación de NFC está limitado a unos pocos centímetros, sí son posibles las escuchas, la modificación de datos y otros tipos de ataques, ya que NFC por sí solo no es garantía de una comunicación segura.

Ejemplo 3: la plataforma Android tiene compatibilidad con NFC. El código siguiente crea un mensaje que se inserta en otro dispositivo dentro del campo de alcance.

...
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)
...


Un mensaje con formato de intercambio de datos NFC (NDEF) contiene datos escritos, un URI o una carga de aplicación personalizada. Si el mensaje contiene información sobre la aplicación, como su nombre, el tipo MIME o la versión de software del dispositivo, esta información se podría filtrar a una persona que esté escuchando.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red.

Ejemplo: El siguiente código genera fugas de información del sistema mediante una solicitud HTTP:


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];


Esta información se puede exponer a un usuario remoto. En algunos casos, el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque será vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL Injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red.

Ejemplo 1: El siguiente código escribe una excepción en la respuesta HTTP:


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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o exponer ante un usuario remoto. Por ejemplo, con los mecanismos de scripts es sencillo redirigir la información de salida de un "Error típico" o una "Salida estándar" a un archivo o a otro programa. De forma alternativa, el sistema que ejecuta el programa podría tener un mecanismo de registro remoto, como un servidor como "syslog", que envía los registros a un dispositivo remoto. Durante este proceso, no existe forma alguna de saber dónde se puede terminar mostrando esta información.

En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red.
Ejemplo 1: El siguiente código imprime las variables de entorno PATH_INFO y SCRIPT_NAME en la página.


...
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;
...
}


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o exponer ante un usuario remoto. En algunos casos el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la ruta de búsqueda podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han puesto los administradores a la hora de configurar el programa.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red.

Ejemplo 1: El siguiente código imprime todas las variables de entorno del sistema como parte de la respuesta HTTP:


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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o exponer ante un usuario remoto. Por ejemplo, con los mecanismos de scripts es sencillo redirigir la información de salida de un "Error típico" o una "Salida estándar" a un archivo o a otro programa. De forma alternativa, el sistema que ejecuta el programa podría tener un mecanismo de registro remoto, como un servidor como "syslog", que envía los registros a un dispositivo remoto. Durante este proceso, no existe forma alguna de saber dónde se puede terminar mostrando esta información.

En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red.

Ejemplo 1: El siguiente código genera fugas de información del sistema mediante una respuesta HTTP:


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


Esta información se puede exponer a un usuario remoto. En algunos casos, el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque será vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la ruta de búsqueda podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han puesto los administradores a la hora de configurar el programa.
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
La revelación de datos del sistema o de información de depuración podría permitir a un adversario realizar un plan de ataque.
Explanation
Se producen pérdidas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red. Las pérdidas externas pueden ayudar a los usuarios malintencionados al revelar datos específicos de los sistemas operativos, nombres de rutas de acceso completos, la existencia de nombres de usuario o las ubicaciones de los archivos de configuración, y son más graves que las pérdidas de información internas, a las que los usuarios malintencionados tienen más dificultades para acceder.

Ejemplo 1: El siguiente código genera pérdidas de información del sistema en la respuesta HTTP:


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


Esta información se puede exponer a un usuario remoto. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red.

Ejemplo: El siguiente código genera fugas de información del sistema mediante una solicitud HTTP:


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)


Esta información se puede exponer a un usuario remoto. En algunos casos, el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque será vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL Injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.
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
La revelación de datos del sistema o de información de depuración podría permitir a un adversario realizar un plan de ataque.
Explanation
Se producen fugas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red.

Ejemplo 1: El siguiente código escribe una excepción en una secuencia de salida Response:


...
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
...


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o exponer ante un usuario remoto. Por ejemplo, con los mecanismos de scripts es sencillo redirigir la información de salida de un "Error típico" o una "Salida estándar" a un archivo o a otro programa. De forma alternativa, el sistema que ejecuta el programa podría tener un mecanismo de registro remoto, como un servidor como "syslog", que envía los registros a un dispositivo remoto. Durante este proceso, no existe forma alguna de saber dónde se puede terminar mostrando esta información.

En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.
Ejemplo: El código siguiente imprime la información de versión de SAPFTP en la pantalla:


...
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.
...


Dependiendo de la configuración de la pantalla de selección, esta información se puede volcar en una pantalla o enviar directamente a una impresora. En algunos casos la información de versión indica con precisión al usuario malintencionado a qué tipo de ataque será vulnerable el sistema. De la misma forma, los mensajes de error pueden indicar al usuario malintencionado el ataque al que el sistema es vulnerable. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL Injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.
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
La revelación de datos del sistema o de información de depuración podría permitir a un adversario realizar un plan de ataque.
Explanation
Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: El siguiente código imprime un seguimiento de pila en una consola "Debug" o en un archivo de registro:


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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la ruta de búsqueda podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han puesto los administradores a la hora de configurar el programa.
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
La revelación de datos del sistema o de información de depuración podría permitir a un adversario realizar un plan de ataque.
Explanation
Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: El siguiente código escribe un mensaje de excepción en el registro de depuración:


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


El mensaje de error podría permitir a un adversario realizar un plan de ataque. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.
Ejemplo 1: el siguiente código crea una cadena de conexión a base de datos, la utiliza para establecer una nueva conexión a la base de datos y la escribe en la consola.


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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información internas cuando los datos del sistema o la información de depuración se envían mediante creación de registros o impresión a un archivo local, a una consola o a una pantalla.
Ejemplo 1: El siguiente código imprime la variable de entorno de ruta en la secuencia de error estándar:


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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque será vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la ruta de búsqueda podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han puesto los administradores a la hora de configurar el programa.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información internas cuando los datos del sistema o la información de depuración se envían mediante creación de registros o impresión a un archivo local, a una consola o a una pantalla.
Ejemplo: el siguiente código solicita un volcado de transacciones de todas las áreas de almacenamiento relacionadas con la tarea, la tabla de control del terminal y un área de datos especificados:


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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL Injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo: el código siguiente escribe en un archivo del sistema de archivos local:


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


Esta información se escribe en un archivo de registro. En algunos casos, el mensaje ofrece al usuario malintencionado información precisa sobre los tipos de ataque a los que es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL Injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: El siguiente código escribe una excepción en un archivo local:


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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.

Las pérdidas de información también son motivo de preocupación en los entornos informáticos móviles.
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
La revelación de datos del sistema o de información de depuración podría permitir a un adversario realizar un plan de ataque.
Explanation
Se producen fugas de información internas cuando se envían datos del sistema o información de depuración mediante un registro o una impresión en un archivo local, una consola o una pantalla.
Ejemplo 1: El siguiente código imprime la variable de entorno de ruta en la secuencia de error estándar:


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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de iSQL Injection. Otros mensajes de error pueden revelar pistas más evasivas acerca del sistema. En el Example 1, la ruta de búsqueda podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han puesto los administradores a la hora de configurar el programa.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen pérdidas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red. Las pérdidas externas pueden ayudar a los usuarios malintencionados al revelar datos específicos de los sistemas operativos, nombres de rutas de acceso completos, la existencia de nombres de usuario o las ubicaciones de los archivos de configuración, y son más graves que las pérdidas de información internas, a las que los usuarios malintencionados tienen más dificultades para acceder.

Ejemplo 1: el siguiente código genera pérdidas de información de Excepción en la respuesta HTTP:


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


Esta información se puede exponer a un usuario remoto. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.

Las pérdidas de información también son motivo de preocupación en los entornos informáticos móviles. En las plataformas móviles, las aplicaciones se descargan desde diversos orígenes y se ejecutan junto con otras aplicaciones en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que los autores de aplicaciones deben tener cuidado con la información que incluyen en los mensajes dirigidos a otras aplicaciones que se ejecutan en el dispositivo.

Ejemplo 2: El siguiente código difunde el seguimiento de pila de una excepción detectada a todos los destinatarios de Android registrados.

...
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);
}
...


Se trata de otra situación específica de las plataformas móviles. La mayoría de los dispositivos móviles ahora implementa un protocolo de transmisión de datos en proximidad (NFC) para compartir rápidamente la información entre dispositivos utilizando la comunicación de radio. Funciona cuando se colocan dispositivos cerca los unos de los otros o tocándose. Aunque el campo de la comunicación de NFC está limitado a unos pocos centímetros, sí son posibles las escuchas, la modificación de datos y otros tipos de ataques, ya que NFC por sí solo no es garantía de una comunicación segura.

Ejemplo 3: la plataforma Android tiene compatibilidad con NFC. El código siguiente crea un mensaje que se inserta en otro dispositivo dentro del campo de alcance.

...
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);
...


Un mensaje con formato de intercambio de datos NFC (NDEF) contiene datos escritos, un URI o una carga de aplicación personalizada. Si el mensaje contiene información sobre la aplicación, como su nombre, el tipo MIME o la versión de software del dispositivo, esta información se podría filtrar a una persona que esté escuchando.
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
La revelación de datos del sistema o de información de depuración podría permitir a un adversario realizar un plan de ataque.
Explanation
Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: el siguiente código escribe una excepción en una secuencia de error estándar:


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

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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.
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
La revelación de datos del sistema o de información de depuración podría permitir a un adversario realizar un plan de ataque.
Explanation
Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: el siguiente código escribe una excepción en una secuencia de error estándar:


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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.

Las pérdidas de información también son motivo de preocupación en los entornos informáticos móviles.

Ejemplo 2: El siguiente código registra el seguimiento de pila de una excepción detectada en la plataforma Android.

...
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información internas cuando los datos del sistema o la información de depuración se envían mediante creación de registros o impresión a un archivo local, a una consola o a una pantalla.
Ejemplo 1: el siguiente código genera fugas de información en el registro del sistema:


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

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


En el mundo móvil, surgen otras áreas de preocupación sobre el mantenimiento de la información del sistema cuando se pierde o se roba un dispositivo. Una vez en posesión de un dispositivo iOS, un atacante puede acceder a gran cantidad de datos conectando el dispositivo por USB. Los archivos de tipo Lista de propiedades de iOS y las bases de datos de SQLite son fácilmente accesibles y pueden revelar información personal. Como regla general, la información relacionada con la privacidad no debe almacenarse sin protección en el sistema de archivos.

Ejemplo 2: el siguiente código añade una entrada deviceID a la lista de valores predeterminados de usuario y los almacena seguidamente en un archivo Lista de propiedades.


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

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


El código del Example 2 almacena información del sistema del dispositivo móvil en un archivo Lista de propiedades que se almacena desprotegido en el dispositivo. Aunque muchos desarrolladores confían en los archivos Lista de propiedades como ubicaciones de almacenamiento seguro para cualquier dato y para todos los datos, no se debería depender de ellos implícitamente, en concreto cuando la información y privacidad del sistema son una preocupación, ya que los archivos Lista de propiedades los puede leer cualquiera que esté en posesión del dispositivo.

En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque será vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL Injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: el siguiente código escribe una excepción en una secuencia de error estándar:


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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.
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
La revelación de datos del sistema o de información de depuración podría permitir a un adversario realizar un plan de ataque.
Explanation
Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: El siguiente código escribe una excepción en una secuencia de salida estándar:


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


Esta información se vuelca en una consola. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.
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
La revelación de datos del sistema o de información de depuración podría permitir a un adversario realizar un plan de ataque.
Explanation
Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: el siguiente código escribe una excepción en una secuencia de error estándar:


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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa. Por supuesto, otro problema con el Example 1 es recuperar la Exception raíz en vez de un tipo específico de error/excepción, lo que significa que filtrará todas las excepciones, causando potencialmente otros efectos secundarios no considerados.
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
La revelación de datos del sistema o de información de depuración podría permitir a un adversario realizar un plan de ataque.
Explanation
Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: El siguiente código imprime información del sistema en una secuencia de salida estándar:


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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.
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
Revelar datos del sistema o la información de depuración ayuda a un adversario a obtener información sobre el sistema y a elaborar un plan de ataque.
Explanation
Se producen fugas de información internas cuando los datos del sistema o la información de depuración se envían mediante creación de registros o impresión a un archivo local, a una consola o a una pantalla.



En el mundo móvil, surgen otras áreas de preocupación sobre el mantenimiento de la información del sistema cuando se pierde o se roba un dispositivo. Una vez en posesión de un dispositivo iOS, un atacante puede acceder a gran cantidad de datos conectando el dispositivo por USB. Los archivos de tipo Lista de propiedades de iOS y las bases de datos de SQLite son fácilmente accesibles y pueden revelar información personal. Como regla general, la información relacionada con la privacidad no debe almacenarse sin protección en el sistema de archivos.

Ejemplo: El siguiente código imprime el identificador del dispositivo en los registros del sistema:


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


En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque será vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL Injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.
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
La revelación de datos del sistema o de información de depuración podría permitir a un adversario realizar un plan de ataque.
Explanation
Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo: El siguiente código envía un objeto ASPError a un depurador de secuencia de comandos, como Microsoft Script Debugger:


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


En algunos casos el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL Injection. Otros mensajes de error pueden revelar pistas más indirectas acerca del sistema, tales como información acerca del tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto cuidado han puesto los administradores al configurar el programa.
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
Es posible que el programa no pueda liberar un recurso del sistema.
Explanation
Es posible que el programa no pueda liberar un recurso del sistema.

Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede activar de forma intencionada una pérdida de recursos, es posible que este pueda iniciar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo: el siguiente método nunca cierra el identificador de archivo que abre. El método Finalize() de StreamReader con el tiempo llama a Close(), pero no hay ninguna garantía en cuanto el tiempo que pasará antes de que se llame al método Finalize(). De hecho, no hay ninguna garantía de que se llame en algún momento al método Finalize(). En un entorno muy activo, esto puede provocar que la VM utilice todos los identificadores de archivo disponibles.


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
Es posible que el programa no pueda liberar un recurso del sistema.
Explanation
Es posible que el programa no pueda liberar un recurso del sistema.

Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede activar de forma intencionada una pérdida de recursos, es posible que este pueda iniciar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo: el siguiente método nunca cierra el identificador de archivo que abre. El método finalize() de FileInputStream con el tiempo llama a close(), pero no hay ninguna garantía en cuanto al tiempo que pasará antes de que se llame al método finalize(). En un entorno muy activo, esto puede provocar que la JVM utilice todos los identificadores de archivo.

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
La función identificada no puede liberar en ocasiones un recurso del sistema.
Explanation
Es posible que el programa no pueda liberar un recurso del sistema.


Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede activar de forma intencionada una pérdida de recursos, es posible que este pueda iniciar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo 1: el siguiente método nunca cierra la secuencia de la que lee.


...
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
Es posible que el programa no pueda liberar un recurso del sistema.
Explanation
Es posible que el programa no pueda liberar un recurso del sistema.

Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede activar de forma intencionada una pérdida de recursos, es posible que este pueda iniciar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo: El siguiente método nunca cierra el identificador de archivo que abre.

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
La función identificada no puede liberar en ocasiones un recurso del sistema.
Explanation
Es posible que el programa no pueda liberar un recurso del sistema.


Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede activar de forma intencionada una pérdida de recursos, es posible que este pueda iniciar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo 1: El método siguiente nunca cierra la secuencia de la que lee.


...
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