Las aplicaciones de Salesforce utilizan reglas de colaboración para controlar los permisos de los usuarios y el acceso a los registros de la base de datos. Sin embargo, las reglas de uso compartido de usuarios no siempre se aplican en Apex porque las clases de Apex se pueden declarar con diferentes palabras clave de uso compartido que cambian la forma en que se aplican las reglas. Una clase se puede declarar con una de tres palabras clave de uso compartido:

- with sharing: Se aplicarán las reglas de uso compartido de usuarios.
- without sharing: Las reglas de uso compartido no se aplicarán.
- inherited sharing: Se aplicarán las reglas de uso compartido de la clase que realiza la llamada. Cuando la clase que realiza la llamada no especifica una palabra clave de uso compartido, o cuando la propia clase es un punto de entrada, como un controlador de Visualforce, las reglas de uso compartido de usuarios se aplicarán de forma predeterminada.

Cuando no se declara ninguna de las palabras clave compartidas, la clase heredará el modo compartido de la clase llamante, si existe. De lo contrario, no se aplicarán las reglas de uso compartido.

Ejemplo 1: Las siguientes tres clases de Apex tienen palabras clave de uso compartido no seguras para sus llamadas de consulta de base de datos.

    public class MyClass1 {
        public List<Contact> getAllTheSecrets() {
            return Database.query('SELECT Name FROM Contact');
        }
    }

    public without sharing class MyClass2 {
        public List<Contact> getAllTheSecrets() {
            return Database.query('SELECT Name FROM Contact');
        }
    }

    public inherited sharing class MyClass3 {
        public List<Contact> getAllTheSecrets() {
            return Database.query('SELECT Name FROM Contact');
        }
    }

Tanto MyClass1 como MyClass2 son inseguras porque los registros se pueden recuperar sin la aplicación de reglas de uso compartido de usuarios.

MyClass3 es más seguro porque impone reglas de uso compartido de forma predeterminada. Sin embargo, aún se puede otorgar acceso no autorizado si se llama la función getAllTheSecrets() en una clase que declara explícitamente without sharing.

Un solo elemento <security constraint> sugiere que el programa no emplea control de acceso basado en roles, que es el procedimiento recomendado comúnmente aceptado para proteger operaciones sensibles en aplicaciones web seguras. Si la aplicación proporciona acceso a operaciones o datos confidenciales, es posible que no existan controles suficientes para evitar que usuarios no autorizados obtengan acceso. Además, si hay un comodín (*) en la etiqueta <url-pattern>, puede ser una indicación de que el patrón es demasiado amplio.

La API AccessibleObject permite que el programador eluda las comprobaciones de control de acceso proporcionadas por los especificadores de acceso de Java. En particular, permite que el programador permita que un objeto reflejado eluda los controles de acceso de Java y a cambio cambie el valor de los campos privados o invoque métodos privados, es decir, comportamientos que normalmente están prohibidos.

Muchas aplicaciones utilizan cookies para comunicar el identificador de sesión de un usuario. Cuando se accede a la aplicación a través de HTTPS, las cookies están protegidas (los atacantes no pueden examinarlas). Pero si los desarrolladores permiten el acceso HTTP a partes no sensibles de la aplicación, el identificador de sesión puede ser objeto de robo. Cuando un usuario se dirige a una parte no protegida del sitio, la cookie, que contiene el identificador de sesión, se envía sin cifrar. Si los atacantes examinan el tráfico, pueden ver el identificador de sesión y usarlo para tomar el control de la sesión del usuario.


El siguiente ejemplo muestra una configuración que mezcla canales poco seguros y seguros:

  <property name="filterInvocationDefinitionSource">
    <value>
      CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
      \A/secure/.*\Z=REQUIRES_SECURE_CHANNEL
      \A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL
      \A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL
      \A.*\Z=REQUIRES_INSECURE_CHANNEL
    </value>
  </property>

Acegi Security permite reemplazar temporalmente el objeto Authentication en SecurityContext durante la fase de devolución de llamada del objeto seguro. Esta situación solo ocurre si el objeto Authentication original fue procesado correctamente por AuthenticationManager y AccessDecisionManager. RunAsManager crea este objeto Authentication.
Normalmente, los desarrolladores utilizan RunAsManager para configurar uno o más roles adicionales para un usuario autenticado durante la invocación de un método. Esta opción es útil en el caso de un archivo Bean seguro que necesita acceder a una aplicación remota. Dado que la aplicación remota puede exigir diferentes credenciales, esta posibilidad permite traducir entre los roles de llamada y los que necesita la aplicación remota para que el acceso remoto pueda tener éxito. El nuevo objeto Authentication (llamado RunAsUserToken) simplemente se aceptará como un objeto de autenticación válido sin ninguna comprobación adicional de autenticación o autorización.
Agregar nuevos roles o privilegios al nuevo objeto Authentication tiene el potencial de elevar temporalmente los privilegios del usuario, lo que le permite realizar una acción no autorizada.
La siguiente configuración muestra el uso de RunAsManager para agregar el rol "UBER_BOSS" a un usuario que tiene el rol "ROLE_PEON", de forma que se elevan temporalmente los privilegios de este usuario a administrador, lo que permite a todos los peones obtener datos del PrivateCatalog.

<bean id="bankManagerSecurity" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
...
 <property name="objectDefinitionSource">
   <value>
     com.example.service.PrivateCatalog.getData=ROLE_PEON,RUN_AS_UBER_BOSS
...
   </value>
 </property>
</bean>

De forma predeterminada, los flujos de tareas en una aplicación Fusion no son directamente accesibles desde una solicitud GET: cada vez que una URL intenta invocar el flujo de tareas, recibe un código de estado HTTP 403. Sin embargo, confiar en una configuración implícita siempre carece de claridad y puede conducir a comportamientos no deseados si la configuración predeterminada cambia de forma inesperada.

Ejemplo 1: El siguiente fragmento de un archivo de definición de flujo de tarea muestra un ejemplo de flujo de tarea configurado con el ajuste implícito predeterminado url-invoke-disallowed.

...
    <task-flow-definition id="password">
        <default-activity>PasswordPrompt</default-activity>
        <view id="PasswordPrompt">
            <page>/PasswordPrompt.jsff</page>
        </view>
        <use-page-fragments/>
    </task-flow-definition>
...

En una aplicación JSF normal, los valores se convierten y validan mediante convertidores y validadores especificados por los componentes de la interfaz de usuario. La conversión y validación en sí ocurre cuando se envía la página. Una vista que se puede marcar en una aplicación Fusion no causa el envío de páginas y, por lo tanto, no se realiza una conversión o validación similar de forma predeterminada.

Ejemplo 1: El siguiente fragmento de archivo de configuración muestra una vista de muestra, que se puede marcar como favorita, configurada para no realizar ninguna conversión o validación del parámetro de URL paramName.

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

Los valores de atributos de los componentes de Oracle ADF Faces solo se pueden establecer normalmente en el servidor. Sin embargo, diversos componentes permiten al desarrollador definir una lista de atributos que se puede establecer en el cliente. El atributo unsecure de estos componentes puede especificar una lista de este tipo.

El único atributo que puede aparecer actualmente dentro del atributo unsecure es disabled; este permite que el cliente defina los componentes que se habilitarán y aquellos que no. Nunca es recomendable dejar que el cliente controle los valores de los atributos que solo deben establecerse en el servidor.

Ejemplo 1: El siguiente código muestra un componente inputText que recopila información de contraseñas del usuario y utiliza el atributo unsecure.

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

El almacenamiento de claves de cifrado en campos de clase estáticos permite que estas se puedan obtener con facilidad por parte de entidades con acceso a la memoria de procesamiento (por ejemplo, un dispositivo con acceso root) o a los volcados de memoria de procesamiento (por ejemplo, los volcados de memoria).

Si bien es una buena idea definir permisos de lectura y escritura separados para los proveedores de contenido, definir solo el writePermission podría ser engañoso. Debido a la naturaleza de SQL, generar consultas verdaderas de solo escritura es generalmente imposible: incluso cuando el usuario no tiene acceso directo a los datos, un atacante puede reconstruir los datos almacenados manipulando la cláusula where.

Ejemplo 1: A continuación aparece un ejemplo de un proveedor de contenido declarado solo con el writePermission.

 <provider android:name=".ContentProvider" android:writePermission="content.permission.WRITE_CONTENT"/> 

Un procedimiento habitual de desarrollo consiste en añadir un código de "puerta trasera" diseñado específicamente para fines de depuración o pruebas que no se vaya a enviar o implementar con la aplicación. Cuando este tipo de código de depuración se deja accidentalmente en la aplicación, este se abre en modos de interacción no previstos. Estos puntos de entrada de "puerta trasera" conllevan riesgos de seguridad porque no se tienen en cuenta durante las fases de diseño y pruebas, y no se incluyen en las condiciones de funcionamiento previstas de la aplicación.

El destinatario registrado sin el permiso del emisor recibirá mensajes de cualquier emisor. Si estos mensajes contienen datos maliciosos o proceden de emisores malintencionados, se podría poner en peligro la aplicación.

Ejemplo 1: el siguiente código registra un destinatario sin especificar el permiso del mismo.

...
context.registerReceiver(broadcastReceiver, intentFilter);
...

Cualquier aplicación puede acceder a componentes públicos a los que no se les haya asignado explícitamente un permiso de acceso en su definición de manifiesto.

El valor predeterminado del atributo exported de los componentes de actividad, receptor y servicio de una aplicación Android depende de la presencia o ausencia de un intent-filter. La presencia de un intent-filter implica que el componente ha sido diseñado para uso externo, por lo que define el atributo exported como verdadero. Este componente es ahora accesible a cualquier otra aplicación de la plataforma Android.

Ejemplo 1: A continuación se muestra un ejemplo de actividad Android con un intent-filter y sin permiso de acceso explícito definido.

 <activity android:name=".AndroidActivity"/> 

   <intent-filter android:label="activityName"/> 

    <action android:name=".someFunAction"/> 

   </intent-filter> 

    ... 

 </activity> 

Aplicaciones malintencionadas podrían aprovechar esta actividad.

Cualquier aplicación puede acceder a componentes públicos a los que no se les haya asignado explícitamente un permiso de acceso en su definición de manifiesto. El proveedor de contenido de Android se exporta de forma predeterminada para las aplicaciones que configuran android: minSdkVersion o android: targetSdkVersion en "16" o anteriores. Para las aplicaciones que establecen cualquiera de estos atributos en "17" o posterior, el valor predeterminado es "falso".

Ejemplo 1: A continuación aparece un ejemplo de un proveedor de contenido de Android declarado sin un permiso de acceso explícito o marca exportada.

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

Android depende de un proveedor de seguridad para proporcionar comunicaciones de red seguras. Sin embargo, de vez en cuando, se encuentran vulnerabilidades en el proveedor de seguridad predeterminado. Para protegerse contra estas vulnerabilidades, los servicios de Google Play proporcionan una forma de actualizar automáticamente el proveedor de seguridad de un dispositivo para protegerse contra vulnerabilidades conocidas. Mediante la llamada a los métodos de los servicios de Google Play, su aplicación puede estar segura de que se ejecuta en un dispositivo que cuenta con las últimas actualizaciones para protegerse contra vulnerabilidades conocidas.

La característica Network Security Configuration permite a las aplicaciones personalizar su configuración de seguridad de red en un archivo de configuración declarativo y seguro sin modificar el código de la aplicación. Estas opciones se pueden configurar para dominios específicos y para una aplicación específica. Las funcionalidades más importantes de esta característica son las siguientes:
- Delimitadores de confianza personalizados: personalice qué entidades de certificación (CA) son de confianza para las conexiones seguras de una aplicación. Por ejemplo, confiar en determinados certificados autofirmados o restringir el conjunto de CA públicas en las que confía la aplicación.
- Anulaciones solo de depuración: depure las conexiones seguras de una aplicación sin riesgo adicional para la base instalada.
- Exclusión de tráfico de texto sin cifrar: proteja las aplicaciones del uso accidental de tráfico de texto sin cifrar.
- Asignación de certificados: restrinja la conexión segura de una aplicación a determinados certificados.

Las difusiones enviadas sin el permiso del destinatario están accesibles para todos los usuarios. Si estas difusiones contienen datos confidenciales o son interceptadas por un destinatario malintencionado, podría ponerse en peligro la aplicación.

Ejemplo 1: el siguiente código envía una difusión sin especificar el permiso del destinatario.

...
context.sendBroadcast(intent);
...

Las difusiones del sistema se pueden enviar a componentes privados. Los componentes deben ser públicos para recibir transmisiones de terceros que no pertenecen al sistema. Al registrarse para recibir transmisiones del sistema y fuera del sistema en un solo componente, parte de la funcionalidad del componente (la parte del sistema) queda innecesariamente expuesta a terceros.

Al declarar un permiso personalizado, hay cuatro opciones para especificar el nivel de protección del permiso: normal, dangerous, signature, y signature or system. Los permisos Normal se otorgan a cualquier aplicación que los solicite. Los permisos Dangerous se otorgan solo después de la confirmación del usuario. Los permisos Signature se otorgan solo a las aplicaciones firmadas por la misma clave de desarrollador que el paquete que define el permiso. Los permisos Signature or system son similares a permisos signature, pero también se otorgan a paquetes en la imagen del sistema Android.

Ejemplo 1: A continuación aparece un ejemplo de permiso personalizado declarado con el nivel de protección normal.

 <permission android:name="custom.PERMISSION"
                     android:label="@string/label_permission"
                     android:description="@string/desc_permission"
                     android:protectionLevel="normal">
      </permission>

Un proveedor de contenido declarado con atributo permission de lectura y escritura combinadas estará accesible para las entidades que soliciten acceso de lectura o escritura al proveedor. Sin embargo, en muchos casos, al igual que en el caso de los archivos en un sistema de archivos, las entidades que necesitan acceso de lectura a los datos almacenados por el proveedor no deberían poder modificar los datos. Establecer el atributo permission no permite distinguir entre usuarios de datos e interacciones que afectan la integridad de los datos.

Ejemplo 1: A continuación aparece un ejemplo de proveedor de contenido declarado con el permission (permiso) de acceso combinado de lectura y escritura.

 <provider android:name=".ContentProvider" android:permission="content.permission.READ_AND_WRITE_CONTENT"/>