By default, Flash applications are subject to the Same Origin Policy which ensures that two SWF applications can access each other's data only if they come from the same domain. Adobe Flash allows developers to alter the policy either programmatically or via appropriate settings in the crossdomain.xml configuration file. However, caution should be taken when changing the settings because an overly permissive cross-domain policy will allow a malicious application to communicate with the victim application in an inappropriate way, leading to spoofing, data theft, relay, and other attacks.

Example 1: The following excerpt is an example of using a wildcard to programmatically specify to which domains the application is allowed to communicate.

   flash.system.Security.allowDomain("*");

Using the * as the argument to allowDomain() indicates that the application's data is accessible to other SWF applications from any domain.

Attackers may exploit vulnerabilities in unchecked permissions in the following way:

1. Data enters the application from an untrusted source.

2. The data is used to represent the user or group identifier, list of permissions, or the resource to which the permission is applied, without undergoing any prior sanity checks. The application then uses this non-sanitized data to edit permission settings.

By default, Silverlight applications are subject to the Same-Origin Policy which ensures that a Silverlight application can access data on a service only if they come from the same domain. Silverlight allows developers to alter the policy via appropriate settings in the clientaccesspolicy.xml configuration file on the host. However, caution should be taken when changing the settings because an overly permissive cross-domain policy will allow a malicious applications to communicate with the victim service in an inappropriate way, leading to spoofing, data theft, relay, and other attacks.

Example 1: The following configuration shows clientaccesspolicy.xml using a wildcard to specify with which domains the service is allowed to communicate.

<allow-from http-request-headers="*">
	<domain uri="*"/>
</allow-from>

Using the * as the value of the domain element's uri attribute indicates that applications on any domain can connect to the service.

Any application can access public components that are not explicitly assigned an access permission in their manifest definition. Android content providers are exported by default for applications that set either android:minSdkVersion or android:targetSdkVersion to "16" or earlier. For applications that set either of these attributes to "17" or later, the default is "false".

Example 1: The following is an example of an Android content provider declared without an explicit access permission or exported flag.

 <provider android:name=".ContentProvider"/> 

Azure SQL Database instances with unrestricted ranges of allowable IP addresses unnecessarily broaden an organization's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by attackers.

Example 1: The following example Ansible task defines an overly exposed Azure SQL Database instance.

- name: Create Firewall Rule
  azure.azcollection.azure_rm_sqlfirewallrule:
    resource_group: orgTestGroup
    server_name: orgSQLServer
    name: SQLServerFWRule
    start_ip_address: 0.0.0.0
    end_ip_address: 255.255.255.255

In an invoker's rights, or AUTHID CURRENT_USER package, identifiers are first resolved against the current user's schema. This can cause unexpected behavior if the definer of the code does not explicitly say which schema an identifier belongs to.

Example: The following code checks whether a user has permissions to perform an action by looking up the user in a permissions table. Most users will only have read access to SYS.PERMISSIONS and be unable to modify the defined permissions.

CREATE or REPLACE FUNCTION check_permissions(
  p_name IN VARCHAR2, p_action IN VARCHAR2)
  RETURN BOOLEAN
  AUTHID CURRENT_USER
IS
  r_count NUMBER;
  perm BOOLEAN := FALSE;
BEGIN
  SELECT count(*) INTO r_count FROM PERMISSIONS
    WHERE name = p_name AND action = p_action;
  IF r_count > 0 THEN
    perm := TRUE;
  END IF;
  RETURN perm;
END check_permissions

If the user calling the check_permissions function defines a PERMISSIONS table in their schema, the database will resolve the identifier to refer to the local table. The user would have write access to the new table and could modify it to gain permissions they wouldn't otherwise have.

This permission has a "dangerous" or "signature" protection level. Permissions with this protection level imply an increased risk to user data privacy or device operation. In this case, access to make and receive telephone calls or read the phone state must not be requested without cause, nor granted without consideration. Malicious software exploits these permissions to call premium-pay numbers, thereby stealing money from unwary users.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the CALL_PHONE permission, which enables an application to initiate phone calls without user confirmation.

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

Example 2: The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_PHONE_STATE permission, which enables an application to access the phone state, including cellular network information, ongoing call status, and phone account details.

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

Example 3: The <uses-permission .../> element of AndroidManifest.xml declares usage of the ADD_VOICEMAIL permission, which enables an application to add voicemails into the system.

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

Example 4: The <uses-permission .../> element of AndroidManifest.xml declares usage of the USE_SIP permission, which enables an application to use the Session Initiation Protocol (SIP) API for internet-based calling and messaging.

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

Example 5: The <uses-permission .../> element of AndroidManifest.xml declares usage of the PROCESS_OUTGOING_CALLS permission, which enables an application to see the phone numbers of outgoing calls and optionally redirect or abort phone calls.

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

Example 6: The <uses-permission .../> element of AndroidManifest.xml declares usage of the ANSWER_PHONE_CALLS permission, which enables an application to answer incoming phone calls.

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

Example 7: The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_PHONE_NUMBERS permission, which enables an application to read the device's phone number(s).

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

Example 8: The <uses-permission .../> element of AndroidManifest.xml declares usage of the ACCEPT_HANDOVER permission, which enables an application to continue a call that was started in another application.

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