Os aplicativos Salesforce usam regras de compartilhamento para controlar as permissões do usuário e o acesso aos registros do banco de dados. No entanto, as regras de compartilhamento do usuário nem sempre são aplicadas no Apex porque as classes do Apex podem ser declaradas com diferentes palavras-chave de compartilhamento que alteram a forma como as regras são aplicadas. Uma classe pode ser declarada com uma das três palavras-chave de compartilhamento diferentes:

- with sharing: As regras de compartilhamento do usuário serão aplicadas.
- without sharing: As regras de compartilhamento não serão aplicadas.
- inherited sharing: As regras de compartilhamento da classe de chamada serão aplicadas. Quando a classe de chamada não especificar uma palavra-chave de compartilhamento ou quando a própria classe for um ponto de entrada, como um controlador do Visualforce, as regras de compartilhamento do usuário serão impostas por padrão.

Quando nenhuma das palavras-chave de compartilhamento for declarada, a classe herdará o modo de compartilhamento da classe de chamada, se houver. Caso contrário, as regras de compartilhamento não serão aplicadas.

Exemplo 1: As três classes do Apex a seguir têm palavras-chave de compartilhamento não seguras para suas chamadas de consulta de banco de dados.

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

MyClass1 e MyClass2 não são seguros porque os registros podem ser recuperados sem a imposição de regras de compartilhamento do usuário.

MyClass3 é mais seguro, porque impõe regras de compartilhamento por padrão. No entanto, o acesso não autorizado ainda poderá ser concedido se a função getAllTheSecrets() for chamada em uma classe que declarar explicitamente without sharing.

Um único elemento <security constraint> sugere que o programa não emprega controle de acesso baseado em função, que é a melhor prática comumente aceita para proteger operações confidenciais em aplicativos da web seguros. Se o aplicativo fornecer acesso a operações ou dados confidenciais, pode não haver controles suficientes para impedir que usuários não autorizados obtenham acesso. Além disso, se houver um caractere curinga (*) no <url-pattern>, isso pode ser uma indicação de que o padrão é excessivamente amplo.

A API AccessibleObject permite que o programador contorne as verificações de controle de acesso fornecidas por especificadores de acesso Java. Em particular, ela possibilita que o programador permita que um objeto refletido contorne controles de acesso Java e, por sua vez, altere o valor de campos particulares ou invoque métodos privados, comportamentos que são normalmente proibidos.

Muitos aplicativos usam cookies para comunicar o identificador de sessão de um usuário. Quando o aplicativo é acessado por HTTPS, os cookies são protegidos (os invasores não conseguem detectá-los). Mas se os desenvolvedores permitirem acesso HTTP a partes não confidenciais do aplicativo, o identificador de sessão pode ser roubado. Quando um usuário navega para uma parte desprotegida do site, o cookie, contendo o ID da sessão, é enviado sem proteção. Se os invasores detectam o tráfego, eles poderão ver o ID da sessão e usá-lo para assumir o controle da sessão do usuário.


O exemplo a seguir mostra uma configuração que combina canais inseguros e 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>

O Acegi Security permite a substituição temporária do objeto de autenticação no SecurityContext durante a fase de retorno de chamada do objeto seguro. Isso ocorre apenas se o objeto de autenticação original foi processado com êxito pelo AuthenticationManager e AccessDecisionManager. O RunAsManager cria esse objeto de autenticação.
Normalmente, os desenvolvedores usam RunAsManager para configurar uma ou mais funções adicionais para um usuário autenticado durante a chamada de um método. Isso é útil para um bean seguro que precisa acessar um aplicativo remoto. Como o aplicativo remoto pode exigir credenciais diferentes, isso permite a tradução entre as funções de chamada e aquelas que o aplicativo remoto precisa para que o acesso remoto seja bem-sucedido. O novo objeto de autenticação (chamado RunAsUserToken) será simplesmente aceito como um objeto de autenticação válido sem qualquer autenticação ou verificação de autorização adicional.
Adicionar novas funções ou privilégios ao novo objeto de autenticação tem a possibilidade de elevar temporariamente os privilégios do usuário, permitindo que ele execute uma ação não autorizada.
A configuração a seguir mostra o uso de RunAsManager para adicionar a função "UBER_BOSS" a um usuário que tem a função "ROLE_PEON", elevando temporariamente esse usuário para ter privilégios de gerente, o que permite que todos os peões obtenham dados do 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>

Por padrão, os fluxos de tarefas em um aplicativo Fusion não são diretamente acessíveis a partir de uma solicitação GET: sempre que um URL tenta invocar o fluxo de tarefas, ele recebe um código de status HTTP 403. No entanto, confiar em uma configuração implícita sempre carece de clareza e pode levar a um comportamento indesejado se a configuração padrão for alterada posteriormente.

Exemplo 1: O seguinte trecho de um arquivo de definição de fluxo de tarefas mostra o mesmo fluxo de tarefas definida com a configuração implícita url-invoke-disallowed por padrão.

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

Em um aplicativo JSF regular, os valores são convertidos e validados usando conversores e validadores especificados pelos componentes de IU. A conversão e validação em si acontecem quando a página é enviada. Uma visualização favoritável de um aplicativo Fusion resulta no não envio da página e, portanto, nenhuma conversão ou validação semelhante é realizada por padrão.

Exemplo 1: O seguinte trecho de um arquivo de configuração mostra uma amostra de visualização favoritável, configurada para não realizar conversão ou validação do parâmetro do URL paramName.

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

Os valores de atributos para componentes do Oracle ADF Faces podem ser definidos normalmente apenas no servidor. No entanto, vários componentes permitem que o desenvolvedor defina uma lista de atributos que podem ser definidos no cliente. O atributo unsecure desses componentes pode especificar uma lista como essa.

Atualmente, o único atributo que pode aparecer dentro do atributo unsecure é disabled e permite que o cliente defina quais componentes estão habilitados e quais não estão. Nunca é uma boa ideia deixar que o cliente controle os valores de atributos que só devem ser configuráveis no servidor.

Exemplo 1: O código a seguir demonstra um componente inputText que coleta informações de senha do usuário e usa o atributo unsecure.

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

O armazenamento de chaves de criptografia em campos de classe estática permite a recuperação fácil por uma entidade que pode acessar a memória de processo (por exemplo, dispositivo com raiz) ou despejos de memória de processo (por exemplo, despejos de memória).

Embora seja uma boa ideia definir permissões separadas de leitura e gravação para provedores de conteúdo, definir apenas a writePermission pode ser enganoso. Devido à natureza do SQL, gerar somente consultas verdadeiras de gravação é geralmente impossível: mesmo quando o usuário não tem acesso direto aos dados, um invasor pode reconstruir os dados armazenados manipulando a cláusula where.

Exemplo 1: Veja a seguir um exemplo de um provedor de conteúdo declarado somente com a writePermission.

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

Uma prática comum de desenvolvimento é adicionar código "back door" (porta dos fundos), projetado especificamente para fins de depuração ou teste, que não se destina a ser enviado ou implantado com o aplicativo. Quando esse tipo de código de depuração é acidentalmente deixado no aplicativo, o aplicativo fica aberto a modos não intencionais de interação. Esses pontos de entrada "back door" criam riscos de segurança, pois não são levados em consideração durante procedimentos de design ou teste e não se enquadram nas condições operacionais esperadas do aplicativo.

O receptor registrado sem a permissão do transmissor receberá mensagens de qualquer transmissor. Se essas mensagens contiverem dados mal-intencionados ou provenientes de um transmissor mal-intencionado, o aplicativo poderá ficar comprometido.

Exemplo 1: O código a seguir registra um receptor sem especificar a permissão do transmissor.

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

Qualquer aplicativo pode acessar componentes públicos que não tenham uma permissão de acesso explicitamente atribuída em sua definição de manifesto.

O valor padrão do atributo exported para os componentes de atividade, receptor e serviço em um aplicativo Android depende da presença ou ausência de um intent-filter. A presença de um intent-filter implica que o componente destina-se para uso externo, definindo assim o atributo exported como "true". Esse componente agora está acessível para qualquer outro aplicativo na plataforma Android.

Exemplo 1: Veja a seguir um exemplo de uma atividade do Android com um intent-filter e sem nenhuma permissão de acesso explícito definida.

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

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

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

   </intent-filter> 

    ... 

 </activity> 

Esta atividade pode ser explorada por aplicativos mal-intencionados.

Qualquer aplicativo pode acessar componentes públicos que não tenham uma permissão de acesso explicitamente atribuída em sua definição de manifesto. Os provedores de conteúdo Android são exportados por padrão para aplicativos que definem android:minSdkVersion ou android:targetSdkVersion como "16" ou anterior. Para aplicativos que definem qualquer um desses atributos como "17" ou posterior, o padrão é "false".

Exemplo 1: Veja a seguir um exemplo de um provedor de conteúdo Android declarado sem uma permissão de acesso explícita ou um sinalizador exportado.

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

O Android depende de um provedor de segurança para fornecer comunicações de rede seguras. No entanto, de vez em quando, vulnerabilidades são encontradas no provedor de segurança padrão. Para se proteger contra essas vulnerabilidades, o Google Play Services oferece uma maneira de atualizar automaticamente o provedor de segurança de um dispositivo para proteção contra explorações conhecidas. Ao chamar os métodos do Google Play Services, seu aplicativo pode garantir que está sendo executado em um dispositivo que possui as atualizações mais recentes para proteção contra explorações conhecidas.

O recurso de configuração de segurança de rede permite que os aplicativos personalizem suas configurações de segurança de rede em um arquivo de configuração declarativo e seguro sem modificar o código do aplicativo. Essas configurações podem ser definidas para domínios específicos e para um aplicativo específico. Os principais recursos desse recurso são os seguintes:
- Âncoras de confiança personalizadas: Personalize quais Autoridades de Certificação (CA) são confiáveis para as conexões seguras de um aplicativo. Por exemplo, confiar em certificados autoassinados específicos ou restringir o conjunto de CAs públicas nas quais o aplicativo confia.
- Substituições apenas de depuração: Depure com segurança conexões seguras em um aplicativo sem risco adicional para a base instalada.
- Desativação do tráfego de texto simples: Proteja os aplicativos do uso acidental de tráfego de texto não criptografado.
- Fixação de certificado: Restrinja a conexão segura de um aplicativo a certificados específicos.

Transmissões enviadas sem a permissão do receptor ficam acessíveis a qualquer receptor. Se essas transmissões contiverem dados confidenciais ou acessarem um receptor mal-intencionado, o aplicativo poderá ficar comprometido.

Exemplo 1: O código a seguir envia uma transmissão sem especificar a permissão do receptor.

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

As transmissões do sistema podem ser enviadas para componentes privados. Os componentes precisam ser públicos para receber transmissões que não são do sistema de terceiros. Ao se registrar para receber tanto transmissões do sistema quanto transmissões que não são do sistema em um único componente, parte da funcionalidade do componente (a parte do sistema) é desnecessariamente exposta a terceiros.

Ao declarar uma permissão personalizada, existem quatro opções para especificar o nível de proteção da permissão: normal, dangerous, signature e signature or system. Normal as permissões são concedidas a qualquer aplicativo que as solicite. Dangerous as permissões são concedidas somente após a confirmação do usuário. Signature as permissões são concedidas apenas a aplicativos assinados pela mesma chave de desenvolvedor do pacote que define a permissão. Signature or system permissões são semelhantes às permissões signature, mas também são concedidas a pacotes na imagem do sistema Android.

Exemplo 1: Veja a seguir um exemplo de uma permissão personalizada declarada com o nível de proteção normal.

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

Um provedor de conteúdo declarado com a permission combinada de leitura e gravação estará acessível para as entidades que solicitam acesso de leitura ou gravação ao provedor. No entanto, em muitos casos, assim como no caso de arquivos em um sistema de arquivos, as entidades que precisam de acesso de leitura aos dados armazenados pelo provedor não devem ter permissão para modificar os dados. Configurar o atributo permission não permite distinguir entre usuários de dados e interações que afetam a integridade dos dados.

Exemplo 1: Veja a seguir um exemplo de um provedor de conteúdo declarado com o atributo permission de acesso combinado de leitura e gravação.

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