438 items found
Weaknesses

Resource Injection

Abstract
Allowing user input to control resource identifiers could enable an attacker to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example: The following code uses a host name read from an HTTP request to create an FTP connection.


...
host_name = request->get_form_field( 'host' ).
CALL FUNCTION 'FTP_CONNECT'
     EXPORTING
       USER            = user
       PASSWORD        = password
       HOST            = host_name
       RFC_DESTINATION = 'SAPFTP'
     IMPORTING
       HANDLE          = mi_handle
     EXCEPTIONS
       NOT_CONNECTED   = 1
       OTHERS          = 2.
...


The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.abap.resource_injection
Abstract
Allowing user input to control resource identifiers could enable an attacker to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.

Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example: The following code uses a port number read from an HTTP request to create a socket.


int rPort = Int32.Parse(Request.Item("rPort"));
...
IPEndPoint endpoint = new IPEndPoint(address,rPort);
socket = new Socket(endpoint.AddressFamily,
                    SocketType.Stream, ProtocolType.Tcp);
socket.Connect(endpoint);
...


The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.dotnet.resource_injection
Abstract
Allowing user input to control resource identifiers could enable an attacker to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.

Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example: The following code uses a port number read from a CGI request to create a socket.


...
char* rPort = getenv("rPort");
...
serv_addr.sin_port = htons(atoi(rPort));
if (connect(sockfd,&serv_addr,sizeof(serv_addr)) < 0)
error("ERROR connecting");
...


The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.cpp.resource_injection
Abstract
Allowing user input to control resource identifiers could enable an attacker to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker might specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example: The following code uses the value read from the terminal to access a record from the CICS queue of that name. 


...
ACCEPT QNAME.
EXEC CICS
  READQ TD
  QUEUE(QNAME)
  INTO(DATA)
  LENGTH(LDATA)
END-EXEC. 
...


The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.cobol.resource_injection
Abstract
Allowing user input to control resource identifiers could enable an attacker to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify part of the name of a file to be opened or a port number to be used.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program might give the attacker the ability to overwrite the specified file or run with a configuration controlled by the attacker.

Example: The following ColdFusion code creates a Java ServerSocket object and uses a port number read from an HTTP request to create a socket. 


<cfobject action="create" type="java" class="java.net.ServerSocket" name="myObj">
<cfset srvr = myObj.init(#url.port#)>
<cfset socket = srvr.accept()>

Passing user input to objects imported from other languages can be very dangerous.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.semantic.cfml.resource_injection
Abstract
Allowing user input to control resource identifiers could enable an attacker to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

1. An attacker can specify the identifier used to access a system resource.

For example, an attacker might be able to specify a port number and use it to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program might give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for additional details of this vulnerability.

Example 1: The following code uses a port number read from an HTTP request to create a socket.


  final server = await HttpServer.bind('localhost', 18081);
  server.listen((request) async {
    final remotePort = headers.value('port');
    final serverSocket = await ServerSocket.bind(host, remotePort as int);
    final httpServer = HttpServer.listenOn(serverSocket);
  });
...


Some think that in the mobile world, classic web application vulnerabilities, such as resource injection, do not make sense -- why would users attack themselves? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.
desc.dataflow.dart.resource_injection
Abstract
Allowing user input to control resource identifiers could enable an attacker to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example: The following code uses a device name read from a HTTP request to connect to bind the socket associated with fd to the device.


    func someHandler(w http.ResponseWriter, r *http.Request){
        r.parseForm()
        deviceName := r.FormValue("device")
        ...
        syscall.BindToDevice(fd, deviceName)
    }


The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.golang.resource_injection
Abstract
Allowing user input to control resource identifiers could enable an attacker to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections where a user can manipulate the location of resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses a port number read from an HTTP request to create a socket.


String remotePort = request.getParameter("remotePort");
...
ServerSocket srvr = new ServerSocket(remotePort);
Socket skt = srvr.accept();
...


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

Example 2: The following code uses a URL read from an Android intent to load the page in WebView.


...
	WebView webview = new WebView(this);
	setContentView(webview);
        String url = this.getIntent().getExtras().getString("url");
	webview.loadUrl(url);
...


The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.java.resource_injection
Abstract
Allowing user input to control resource identifiers could enable an attacker to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example: The following code uses a URL read from an HTTP request to create a socket.


  var socket = new WebSocket(document.URL.indexOf("url=")+20);


The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.javascript.resource_injection
Abstract
Attackers are able to control the resource identifier argument which could enable them to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource or source location for input files.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third party server.

Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses a host read from a request:


...
char* rHost = getenv("host");
...
CFReadStreamRef readStream;
CFWriteStreamRef writeStream;
CFStreamCreatePairWithSocketToHost(NULL, (CFStringRef)rHost, 80, &readStream, &writeStream);
...


The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.objc.resource_injection
Abstract
Allowing user input to control resource identifiers could enable an attacker to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example: The following code uses a hostname read from an HTTP request to connect to a database, which determines the price for a ticket.


<?php
    $host=$_GET['host'];
    $dbconn = pg_connect("host=$host port=1234 dbname=ticketdb");
...
    $result = pg_prepare($dbconn, "my_query", 'SELECT * FROM pricelist WHERE name = $1');
    $result = pg_execute($dbconn, "my_query", array("ticket"));
?>


The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.php.resource_injection
Abstract
Allowing user input to control resource identifiers could enable an attacker to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

3. An attacker may specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

4. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.

Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example: The following code uses a CGI environment variable as a URL of a document to be downloaded.


...
filename := SUBSTR(OWA_UTIL.get_cgi_env('PATH_INFO'), 2);
WPG_DOCLOAD.download_file(filename);
...


The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in functions that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.sql.resource_injection
Abstract
Allowing user input to control resource identifiers could enable an attacker to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example: The following code uses a hostname read from an HTTP request to connect to a database, which determines the price for a ticket.


host=request.GET['host']
dbconn = db.connect(host=host, port=1234, dbname=ticketdb)
c = dbconn.cursor()
...
result = c.execute('SELECT * FROM pricelist')
...


The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.python.resource_injection
Abstract
Allowing user input to control resource identifiers could enable an attacker to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses a string read from an HTTP request as the key to cache the logged-in user data.


def controllerMethod = Action { request =>
    val result = request.getQueryString("key").map { key =>
        val user = db.getUser() 
        cache.set(key, user)
        Ok("Cached Request") 
    }
    Ok("Done") 
}


The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.scala.resource_injection
Abstract
Attackers are able to control the resource identifier argument which could enable them to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource or source location for input files.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third party server.

Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example 1: The following code uses a host read from a request:


...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
    var inputStream : NSInputStream?
    var outputStream : NSOutputStream?
    ...
    var readStream : Unmanaged<CFReadStream>?
    var writeStream : Unmanaged<CFWriteStream>?
    let rHost = getQueryStringParameter(url.absoluteString, "host")
    CFStreamCreatePairWithSocketToHost(kCFAllocatorDefault, rHost, 80, &readStream, &writeStream);
    ...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
    if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
        return queryItems.filter({ (item) in item.name == param }).first?.value!
    }
    return nil
}
...


The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.swift.resource_injection
Abstract
Allowing user input to control resource identifiers could enable an attacker to access or modify otherwise protected system resources.
Explanation
A resource injection issue occurs when the following two conditions are met:

1. An attacker is able to specify the identifier used to access a system resource.

For example, an attacker may be able to specify a port number to be used to connect to a network resource.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party server.



Note: Resource injections involving resources stored on the file system are reported in a separate category named path manipulation. See the path manipulation description for further details of this vulnerability.

Example: The following code uses a port number read from an HTTP request to create a socket.


...
	Begin MSWinsockLib.Winsock tcpServer
...
Dim Response As Response
Dim Request As Request
Dim Session As Session
Dim Application As Application
Dim Server As Server
Dim Port As Variant
Set Response = objContext("Response")
Set Request = objContext("Request")
Set Session = objContext("Session")
Set Application = objContext("Application")
Set Server = objContext("Server")
Set Port = Request.Form("port")
...
tcpServer.LocalPort = Port
tcpServer.Accept
...



The kind of resource affected by user input indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash are risky when used in methods that interact with the file system. Similarly, data that contains URLs and URIs is risky for functions that create remote connections.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.vb.resource_injection

Android Bad Practices: Use of Released Media Resource

Abstract
The code references the Android media object after it has already been released.
Explanation
The code attempts to use the media object after the it has already been released. Any further references to that media object without reacquiring the resource will throw an exception, and can cause the application to crash if the exception is not caught.

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


public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}
References
[1] Media Player, Android Developers
[2] Audio Capture, Android Developers
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[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 416
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [7] CWE ID 416
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [8] CWE ID 416
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [7] CWE ID 416
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [7] CWE ID 416
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [4] CWE ID 416
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[17] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[50] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.android_bad_practices_use_of_released_media_resource

Android Bad Practices: Use of Released Camera Resource

Abstract
The code references the Camera object after it has already been released.
Explanation
The code attempts to use the Camera object after the it has already been released. Any further references to the Camera object without reacquiring the resource will throw an exception, and can cause the application to crash if the exception is not caught.

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


public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}
References
[1] Camera, Android Developers
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 416
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [7] CWE ID 416
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [8] CWE ID 416
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [7] CWE ID 416
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [7] CWE ID 416
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [4] CWE ID 416
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[16] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.android_bad_practices_use_of_released_camera_resource

Android Bad Practices: Use of Released SQLite Resource

Abstract
The code references the Android database handler after it has already been released.
Explanation
The code attempts to use the Android SQLite database handler after the it has already been closed. Any further references to the handler without re-establishing the database connection will throw an exception, and can cause the application to crash if the exception is not caught.

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


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

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

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}
References
[1] Data Storage, Android Developers
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 416
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [7] CWE ID 416
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [8] CWE ID 416
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [7] CWE ID 416
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [7] CWE ID 416
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [4] CWE ID 416
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[16] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.android_bad_practices_use_of_released_sqlite_resource

J2EE Misconfiguration: Duplicate Security Role

Abstract
Multiple security roles with the same name exist. Duplicate security roles often indicate left over debug code or a typographical error.
Explanation
Duplicate security roles serve no purpose since only the last definition of a given security role will be applied.
Example 1: The entry from a web.xml file defines two admin roles.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>AdminPage</web-resource-name>
        <description>Admin only pages</description>
        <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>
</security-constraint>
...
<security-role>
    <description>Administrator</description>
    <role-name>admin</role-name>
</security-role>

<security-role>
    <description>Non-Administrator</description>
    <role-name>admin</role-name>
</security-role>
References
[1] Sun Microsystems, Inc. Java Servlet Specification 2.4
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 398
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[14] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.j2ee_misconfiguration_duplicate_security_role

Insecure Deployment: Sitemap

Abstract
Ensure that restricted sensitive resources are not exposed through the sitemap.
Explanation
Mapping of the application attack surface and discovering hidden or restricted resources is a primary goal of an attacker and is often achieved through automated crawling methods. Similarly, search engines discover information about your site by employing software known as "spiders" to crawl the web. Once the spiders find a site, they follow links within the site to gather information about all the pages. The spiders periodically revisit sites to find new or changed content.

Sitemap programs provide a detailed view of a website and its organization. Attackers and search bots can use these programs in addition to crawling and indexing a site. Including sensitive and otherwise restricted resources in the sitemap output could expose sensitive functionality to compromise and aid in the attacker discovery process.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[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 200
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2024 M2 Inadequate Supply Chain Security
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[16] Standards Mapping - Web Application Security Consortium Version 2.00 Fingerprinting (WASC-45)
desc.dynamic.xtended_preview.insecure_deployment_sitemap

Azure ARM Misconfiguration: Improper CORS Policy

Abstract
The template defines an overly permissive CORS policy.
Explanation
Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain. Historically, web browsers have restricted their domain resources from being accessed by scripts loaded from a different domain to abide by the same origin policy.
CORS provides a method for a domain to allow other domains and enable them to access its resources.

Be careful when defining a CORS policy because an overly permissive policy configured at the server level for a domain or a directory on a domain can expose more content for cross domain access than intended. CORS can enable a malicious application to communicate with a victim application inappropriately, which can lead to information disclosure, spoofing, data theft, relay, or other attacks.

Implementing CORS can increase an application's attack surface and should only be used when necessary.

Example 1: The following example template defines an overly permissive CORS policy for an Azure SignalR web application.

resource example 'Microsoft.SignalRService/SignalR@2022-02-01' = {
    ...
    properties: {
        ...
        cors: {
            ...
            allowedOrigins: [ '*' ]
        }
    }
}
Example 2: The following example template defines an overly permissive CORS policy for an Azure web application.

resource example 'Microsoft.Web/sites@2020-12-01' = {
    ...
    properties: {
        ...
        siteConfig: {
            ...
            cors: {
                ...
                allowedOrigins: [ '*' ]
            }
        }
    }
}
Example 3: The following example template defines an overly permissive CORS policy for an Azure Maps account.

resource example 'Microsoft.Maps/accounts@2021-12-01-preview' = {
    ...
    properties: {
        ...
        cors: {
            corsRules: [
                {
                    allowedOrigins: [ '*' ]
                }
            ]
        }
    }
}
Example 4: The following example template defines an overly permissive CORS policy for an Azure Cosmos DB account.

resource example 'Microsoft.DocumentDB/databaseAccounts@2023-04-15' = {
    ...
    properties: {
        ...
        cors: [
            {
                ...
                allowedOrigins: '*'
            }
        ]
    }
}
Example 5: The following example template defines an overly permissive CORS policy for an Azure storage blob service.

resource example 'Microsoft.Storage/storageAccounts/blobServices@2021-09-01' = {
    ...
    properties: {
        ...
        cors: {
            corsRules: [
                {
                    ...
                    allowedOrigins: [ '*' ]
                }
            ]
        }
    }
}
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Microsoft Cross-Origin Resource Sharing (CORS) support for Azure Storage
[6] Microsoft Cosmos DB - SQL API - Configure Cross-Origin Resource Sharing (CORS)
[7] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.5
[8] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[9] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[10] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[11] Standards Mapping - CIS Google Kubernetes Engine Benchmark Integrity
[12] Standards Mapping - Common Weakness Enumeration CWE ID 942
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[14] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[17] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[20] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[33] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.bicep.azure_arm_misconfiguration_improper_cors_policy
Abstract
The template defines an overly permissive CORS policy.
Explanation
Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain. Historically, web browsers have restricted their domain resources from being accessed by scripts loaded from a different domain to abide by the same origin policy.
CORS provides a method for a domain to allow other domains and enable them to access its resources.

Be careful when defining a CORS policy because an overly permissive policy configured at the server level for a domain or a directory on a domain can expose more content for cross domain access than intended. CORS can enable a malicious application to communicate with a victim application inappropriately, which can lead to information disclosure, spoofing, data theft, relay, or other attacks.

Implementing CORS can increase an application's attack surface and should only be used when necessary.

Example 1: The following example template defines an overly permissive CORS policy for an Azure SignalR web application.

{
    ...
    "type": "Microsoft.SignalRService/SignalR",
    ...
    "properties": {
    ...
        "cors": {
            "allowedOrigins": ["*"]
        },
    ...
}
Example 2: The following example template defines an overly permissive CORS policy for an Azure web application.

{
    "apiVersion": "2020-12-01",
    "type": "Microsoft.Web/sites",
    ...
    "properties": {
        ...
        "siteConfig": {
            ...
            "cors": {
                "allowedOrigins": [
                    "*"
                ]
            },
    ...
}
Example 3: The following example template defines an overly permissive CORS policy for an Azure Maps account.

{
    "apiVersion": "2021-12-01-preview",
    "type": "Microsoft.Maps/accounts",
    ...
    "properties":{
        "cors":{
            "allowedOrigins": ["*"]
        }
    },
    ...
}
Example 4: The following example template defines an overly permissive CORS policy for an Azure Cosmos DB account.

{
    "type": "Microsoft.DocumentDB/databaseAccounts",
    ...
    "properties": {
        "cors": [{
            "allowedOrigins":"*"
        }],
    ...
}
Example 5: The following example template defines an overly permissive CORS policy for an Azure storage blob service.

{
"type": "Microsoft.Storage/storageAccounts/blobServices",
    ...
    "properties": {
        "cors": {
            "corsRules": [
                {
                    "allowedOrigins":["*"],
                    ...
                }
            ]
        }
    }
    ...
}
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Microsoft Cross-Origin Resource Sharing (CORS) support for Azure Storage
[6] Microsoft Cosmos DB - SQL API - Configure Cross-Origin Resource Sharing (CORS)
[7] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.5
[8] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[9] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[10] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[11] Standards Mapping - CIS Google Kubernetes Engine Benchmark Integrity
[12] Standards Mapping - Common Weakness Enumeration CWE ID 942
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[14] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[17] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[20] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[33] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.json.azure_arm_misconfiguration_improper_cors_policy