This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to body sensors can pose a danger to user privacy and personal safety. Applications that require access to body sensors must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the BODY_SENSORS permission, which enables an application to access data from body or environmental sensors on the device or connected wearables.

 <uses-permission android:name="android.permission.BODY_SENSORS"/> 

Operations related to making and receiving telephone calls must not be performed without cause or consideration. Malicious software exploits these APIs to call premium-pay numbers, thereby stealing money from unwary users.

Example 1: The following code requests the complete voicemail number.

number = tm.getCompleteVoiceMailNumber(); 

Some permissions on Intents are there to be able to grant permissions to external programs that do not usually have that permission, such as FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION. If a malicious program is able to intercept this intent, it will then gain permission to read from or write to the specified URI. These can often be more susceptible to being intercepted if the intent is implicit rather than explicit.

Example 1: The following code sets the permission flag to enable writing to a URI within the Intent.

  myIntent.setFlags(Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

PL/SQL functions and procedures can be either AUTHID DEFINER or AUTHID CURRENT_USER. Functions and procedures with definer's rights execute under the privileges of the user that defines the code. This can allow updates and access to specific pieces of data without granting access to entire tables or schemas. With invoker's rights, or AUTHID CURRENT_USER, functions and procedures execute under the privileges of the user who invokes them. This does not allow a user to gain access to data it didn't already have access to. If no AUTHID clause is provided, the function or procedure defaults to definer's rights.

Functions and procedures are usually defined by SYS or another highly privileged user, making any exploits of the code potentially more dangerous.

PL/SQL packages can be either AUTHID DEFINER or AUTHID CURRENT_USER. Functions and procedures in a package with definer's rights execute under the privileges of the user that defines the package. This can allow updates and access to specific pieces of data without granting access to entire tables or schemas. In a package with invoker's rights, or AUTHID CURRENT_USER, functions and procedures execute under the privileges of the user who invokes them. This does not allow a user to gain access to data it didn't already have access to. If no AUTHID clause is provided, the package defaults to definer's rights.

Packages are usually defined by SYS or another highly privileged user, making any exploits of the code potentially more dangerous.

Certain Android operations require permissions. Permissions have to be requested by the application at install time by listing them in the AndroidManifest.xml file via <uses-permission/> tags. If the required permissions are not requested, the operations that require these permissions will fail at runtime. In some cases, a java.lang.SecurityException is thrown back to the application. Other times, operations fail silently without an exception.

Example 1: The following code sends a text based SMS.

sms.sendTextMessage(recipient, null, message, PendingIntent.getBroadcast(SmsMessaging.this, 0, new Intent(ACTION_SMS_SENT), 0), null);

This API requires the android.permission.SEND_SMS permission. If this permission is not requested by the application in the manifest file, the application will fail to send an SMS.

Certain Android operations require permissions. Permissions have to be requested by the application at install time by listing them in the AndroidManifest.xml file via <uses-permission/> tags. If the required permissions are not requested, the operations that require these permissions will fail at runtime. In some cases, a java.lang.SecurityException is thrown back to the application. Other times, operations fail silently without an exception.

Example 1: The following code reads contacts information stored on the device.

Cursor cursor = getContentResolver().query(ContactsContract.Contacts.CONTENT_URI, null, null, null, null);

Reading data from this content provider requires the android.permission.READ_CONTACTS permission. If this permission is not requested by the application in the manifest file, the application will fail to read contacts information.

Certain Android operations require permissions. Permissions have to be requested by the application at install time by listing them in the AndroidManifest.xml file via <uses-permission/> tags. If the required permissions are not requested, the operations that require these permissions will fail at runtime. In some cases, a java.lang.SecurityException is thrown back to the application. Other times, operations fail silently without an exception.

Example 1: The following code sends an intent with the android.provider.Telephony.SMS_RECEIVED action.

    Intent i = new Intent("android.provider.Telephony.SMS_RECEIVED");
    context.sendBroadcast(i);

Sending this intent requires the android.permission.BROADCAST_SMS permission. If this permission is not requested by the application in the manifest file, the application will fail to send the intent.

Secure coding principles advocate making access specifiers as restrictive as possible. A method with a public access specifier means that any external code is allowed to call it. Public methods that perform privileged actions can be dangerous when code is shared in libraries or in environments where code can dynamically enter the system (e.g. Code Injection, Dangerous File Inclusion, File Upload, etc).

Example 1: In the following code, doPrivilegedOpenFile() is declared public and performs a privileged operation.

public static void doPrivilegedOpenFile(final String filePath) {
  final BadFileNamePrivilegedAction pa = new BadFileNamePrivilegedAction(filePath);

  FileInputStream fis = null;
  ...
  fis = (FileInputStream)AccessController.doPrivileged(pa);
  ...
}

Using the ALL PRIVILEGES or ALL option will grant the user all of the permissions that can be applied to an object. The programmer may not be aware of all of the privileges being granted.

Example: An administrator may want to give a user the ability to update the data in the procedure.

GRANT ALL ON employees TO john_doe;

In addition to the ability to select, update, add, and remove rows, john_doe now has permission to change the definition of the table.

Some functions may enable a programmer to specify an explicit value for whether permission was allowed. This can then be abused to violate what the user wants and still assume the permission was given.

Example 1: The following code asks permission to use the user's location on Android while using WebView, yet uses the user's location whether or not permission to do so is granted. This is achieved by manually invoking the callback with true to specify that permission was given:

public void onGeolocationPermissionsShowPrompt(String origin, GeolocationPermissions$Callback callback){
  super.onGeolocationPermissionsShowPrompt(origin, callback);
  callback.invoke(origin, true, false);
}

An application should only have the minimum permissions required for its proper execution. Extra permissions might deter users from installing the application. This permission might be unnecessary for this program.

All modern web development frameworks provide built-in session management support. Prior knowledge of session identifiers is essential for hijacking user sessions using attacks such as Cross-Site Request Forgery and Clickjacking. This knowledge can also help attackers fingerprint the web frameworks and technologies used to build the target application. Attackers can use this information to discover hidden resources, customize their exploits, and target known exploits disclosed against the detected frameworks or technologies.

Spring Boot applications can be configured to deploy Actuators, which are REST endpoints that allow users to monitor different aspects of the application. There are different built-in Actuators which may expose sensitive data and are labeled as "sensitive". By default all sensitive HTTP endpoints are secured such that only users that have an ACTUATOR role may access them.

This application is either disabling the authentication requirement for sensitive endpoints:

Example 1:

management.security.enabled=false

Or marking sensitive endpoints as non-sensitive:

Example 2:

endpoints.health.sensitive=false

Or a custom Actuator is set as non-sensitive:

@Component
public class CustomEndpoint implements Endpoint<List<String>> {

    public String getId() {
        return "customEndpoint";
    }

    public boolean isEnabled() {
        return true;
    }

    public boolean isSensitive() {
        return false;
    }

    public List<String> invoke() {
        // Custom logic to build the output
        ...
    }
}

Spring Boot allows developers to enable admin-related features for the application by specifying the spring.application.admin.enabled property. This exposes the SpringApplicationAdminMXBean on the platform MBeanServer. Developers could use this feature to administer the Spring Boot application remotely, however this feature exposes an additional attack surface in the form of a remote JMX endpoint. Depending on the configuration of the MBeanServer the MBean can be exposed locally or remotely, and may or may not require authentication. In the worst case, attackers will be able to manage the application remotely, including shutting it down without any authentication. In the best case, the service will be as strong as the credentials used to protect the server.

Note: If using a JRE version vulnerable to CVE-2016-3427 (fixed in Java 8 Update 91, April 2016), an attacker will be able to pass any serialized Java object as the credentials, which may lead to arbitrary code execution when the remote JVM deserializes it.

The Spring Boot application has DevTools enabled. DevTools include an additional set of tools which can make the application development experience a little more pleasant, but DevTools are not recommended to use on applications in a production environment. As stated in the official Spring Boot documentation: "Enabling spring-boot-devtools on a remote application is a security risk. You should never enable support on a production deployment."

The Shutdown Actuator allows authenticated users to shut down the application. Even though it is configured by default as a sensitive endpoint and therefore authentication is required to use this endpoint, it is not a good practice to enable it without a strong reason since credentials may be weak or the application configuration can be modified to flag the actuator as non-sensitive.

Example 1: A Spring Boot application is configured to deploy the shutdown Actuator:

endpoints.shutdown.enabled=true

Spring Security is configured with an overly permissive catch-all policy whereby a request that does not match any security expression is allowed access.

Example 1: The following code defines a Spring Security configuration that defaults to permit any unmatched requests:

	<http auto-config="true">
        ...
        <intercept-url pattern="/app/admin" access="ROLE_ADMIN" />
        <intercept-url pattern="/**" access="permitAll" />
	</http>

Even if this is currently a secure configuration, new private endpoints might be added to the application in the future. If developers forget to update the security policy, the default catch-all rule will allow public access to the new private endpoint.

Spring Security sets default security headers to help protect the application. The default security headers injected by Spring Security are:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

These are reasonable headers that help protect the application. Do not disable these headers unless they are replaced by more restrictive values.

Example 1: The following code disables Spring Security default headers:

	<http auto-config="true">
        ...
        <headers disabled="true"/>
        ...
	</http>

Spring Security borrowed Ant path expressions to specify how to protect endpoints.

Example 1: In the following example, any endpoint that matches the "/admin" Ant path expression requires administrator privileges for access:

	<http auto-config="true">
        ...
        <intercept-url pattern="/app/admin" access="ROLE_ADMIN" />
        ...
        <intercept-url pattern="/**" access="permitAll" />
	</http>

However, if the protected endpoint is a Spring MVC endpoint, an attacker can bypass this control by abusing Spring MVC content-negotiation features. With Spring MVC users can specify how they want the resource served by either using the Accept header or by specifying the desired content-type using an extension. For example, you can request the /admin resource as a JSON document by sending the request to /admin.json.
Ant path expressions do not account for content-negotiation extensions, and therefore, the request does not match the /admin expression and the endpoint is not protected.