Os pacotes PL/SQL podem ser AUTHID DEFINER ou AUTHID CURRENT_USER. As funções e procedimentos em um pacote com os direitos do definidor são executados sob os privilégios do usuário que define o código. Isso pode permitir e o acesso a partes específicas de dados e as respectivas atualizações sem conceder acesso a tabelas ou a esquemas inteiros. Em um pacote com os direitos do chamador, ou AUTHID CURRENT_USER, as funções e os procedimentos são executados sob os privilégios do usuário que os invoca. Isso não permite a um usuário o acesso a dados aos quais ele ainda não tem acesso. Se nenhuma cláusula AUTHID for fornecida o pacote padroniza aos direitos do definidor.

Os pacotes são geralmente definidos pelo SYS ou por outro usuário extremamente privilegiado, fazendo com que quaisquer ataques do código sejam potencialmente mais perigosos.

Certas operações do Android exigem permissões. Essas permissões precisam ser solicitadas pelo aplicativo na ocasião da instalação, listando-as no arquivo AndroidManifest.xml por meio de tags <uses-permission/>. Se as permissões necessárias não forem solicitadas, as operações que as exigirem falharão em tempo de execução. Em alguns casos, uma java.lang.SecurityException é lançada de volta para o aplicativo. Em outros casos, as operações falham silenciosamente sem uma exceção.

Exemplo 1: O código a seguir envia um SMS baseado em texto.

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

Essa API requer a permissão android.permission.SEND_SMS. Se essa permissão não for solicitada no arquivo de manifesto pelo aplicativo, este não poderá enviar um SMS.

Certas operações do Android exigem permissões. Essas permissões precisam ser solicitadas pelo aplicativo na ocasião da instalação, listando-as no arquivo AndroidManifest.xml por meio de tags <uses-permission/>. Se as permissões necessárias não forem solicitadas, as operações que as exigirem falharão em tempo de execução. Em alguns casos, uma java.lang.SecurityException é lançada de volta para o aplicativo. Em outros casos, as operações falham silenciosamente sem uma exceção.

Exemplo 1: O código a seguir lê informações de contato armazenadas no dispositivo.

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

A leitura de dados desse provedor de conteúdo requer a permissão android.permission.READ_CONTACTS. Se essa permissão não for solicitada no arquivo de manifesto pelo aplicativo, este não poderá ler informações de contatos.

Certas operações do Android exigem permissões. Essas permissões precisam ser solicitadas pelo aplicativo na ocasião da instalação, listando-as no arquivo AndroidManifest.xml por meio de tags <uses-permission/>. Se as permissões necessárias não forem solicitadas, as operações que as exigirem falharão em tempo de execução. Em alguns casos, uma java.lang.SecurityException é lançada de volta para o aplicativo. Em outros casos, as operações falham silenciosamente sem uma exceção.

Exemplo 1: O código a seguir envia uma intenção com a ação android.provider.Telephony.SMS_RECEIVED.

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

O envio dessa intenção exige a permissão android.permission.BROADCAST_SMS. Se essa permissão não for solicitada no arquivo de manifesto pelo aplicativo, este não poderá enviar a intenção.

Princípios de codificação segura defendem tornar especificadores de acesso os mais restritivos possíveis. Um método com um especificador de acesso public significa que qualquer código externo pode chamá-lo. Métodos públicos que realizam ações privilegiadas podem ser perigosos quando o código é compartilhado em bibliotecas ou em ambientes nos quais o código pode entrar dinamicamente no sistema (por exemplo, Injeção de Código, Inclusão de Arquivos Perigosos, Carregamento de arquivo etc).

Exemplo 1: No código a seguir, doPrivilegedOpenFile() é declarado como public e realiza uma operação privilegiada.

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

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

Usar a opção ALL PRIVILEGES ou ALL concederá ao usuário todas as permissões que podem ser aplicadas a um objeto. O programador pode não estar ciente de todos os privilégios sendo concedidos.

Exemplo 1: Um administrador pode desejar conceder a um usuário a capacidade de atualizar os dados no procedimento.

GRANT ALL ON employees TO john_doe;

Além da capacidade de selecionar, atualizar, adicionar e remover linhas, john_doe agora tem permissão para alterar a definição da tabela.

Algumas funções podem permitir que um programador especifique um valor explícito para se a permissão foi ou não permitida. Em seguida, é possível abusar dessa situação de forma a violar o que o usuário deseja e ainda assumir que a permissão foi concedida.

Exemplo 1: O código a seguir pede permissão para usar a localização do usuário no Android durante o uso de WebView, mas ainda usa a localização desse usuário independentemente de haver ou não uma permissão para isso. Isso é obtido com a invocação manual do retorno de chamada com true para especificar que a permissão foi concedida:

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

Um aplicativo deve ter apenas as permissões mínimas necessárias para sua execução adequada. Permissões extras podem impedir os usuários de instalar o aplicativo. Essa permissão pode ser desnecessária para este programa.

Os aplicativos Spring Boot podem ser configurados para implantar Atuadores, que são terminais REST que permitem aos usuários monitorar diferentes aspectos do aplicativo. Existem diferentes atuadores integrados que podem expor dados confidenciais e são rotulados como "confidenciais". Por padrão, todos os endpoints HTTP confidenciais são protegidos de forma que apenas os usuários que têm uma função ACTUATOR podem acessá-los.

Este aplicativo está desativando o requisito de autenticação para endpoints confidenciais:

Exemplo 1:

management.security.enabled=false

Ou marcando endpoints como não confidenciais:

Exemplo 2:

endpoints.health.sensitive=false

Ou um atuador personalizado está definido como não confidencial:

@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
        ...
    }
}

O Spring Boot permite que os desenvolvedores habilitem recursos relacionados ao administrador para o aplicativo, especificando a propriedade spring.application.admin.enabled. Isso expõe o SpringApplicationAdminMXBean na plataforma MBeanServer. Os desenvolvedores podem usar esse recurso para administrar o aplicativo Spring Boot remotamente; no entanto, esse recurso expõe uma superfície de ataque adicional na forma de um endpoint JMX remoto. Dependendo da configuração do MBeanServer o MBean pode ser exposto local ou remotamente e pode ou não exigir autenticação. Na pior das hipóteses, os invasores serão capazes de gerenciar o aplicativo remotamente, incluindo desligá-lo sem qualquer autenticação. Na melhor das hipóteses, o serviço será tão forte quanto as credenciais usadas para proteger o servidor.

Observação: Se estiver usando uma versão JRE vulnerável ao CVE-2016-3427 (corrigido no Java 8 Update 91, abril de 2016), um invasor será capaz de passar qualquer objeto Java serializado como as credenciais, o que pode levar à execução arbitrária de código quando o JVM remoto desserializa.

O aplicativo Spring Boot tem DevTools habilitado. As DevTools incluem um conjunto adicional de ferramentas que podem tornar a experiência de desenvolvimento de aplicativos um pouco mais agradável, mas as DevTools não são recomendadas para uso em aplicativos em um ambiente de produção. Conforme declarado na documentação oficial do Spring Boot: "Habilitar as spring-boot-devtools em um aplicativo remoto é um risco de segurança. Você nunca deve habilitar o suporte em uma implantação de produção."

O Shutdown Actuator permite que usuários autenticados desliguem o aplicativo. Mesmo que seja configurado por padrão como um endpoint confidencial e, portanto, a autenticação seja necessária para usar este endpoint, não é uma boa prática habilitá-lo sem um motivo forte, pois as credenciais podem ser fracas ou a configuração do aplicativo pode ser modificada para sinalizar o atuador como não confidencial.

Exemplo 1: Um aplicativo Spring Boot é configurado para implantar o desligamento do atuador:

endpoints.shutdown.enabled=true

O Spring Security é configurado com uma política "catch-all" excessivamente flexível, em que é permitido o acesso a uma solicitação que não corresponde a nenhuma expressão de segurança.

Exemplo 1: O seguinte código define uma configuração do Spring Security que, por padrão, permite todas as solicitações sem correspondência:

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

Mesmo que, atualmente, essa seja uma configuração segura, novos pontos de extremidade privados poderão ser adicionados ao aplicativo no futuro. Se os desenvolvedores se esquecerem de atualizar a política de segurança, a regra "catch-all" padrão permitirá o acesso público ao novo ponto de extremidade privado.

O Spring Security define cabeçalhos de segurança padrão para proteger o aplicativo. Os cabeçalhos de segurança padrão injetados pelo Spring Security são:

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

Esses são cabeçalhos razoáveis que ajudam a proteger o aplicativo. Não desabilite esses cabeçalhos, a menos que sejam substituídos por valores mais restritivos.

Exemplo 1: O seguinte código desabilita os cabeçalhos padrão do Spring Security:

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

O Spring Security tomou por empréstimo expressões de caminho Ant para especificar como proteger pontos de extremidade.

Exemplo 1: No seguinte exemplo, qualquer ponto de extremidade que corresponda à expressão de caminho "/admin" Ant requer privilégios de administrador para acesso:

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

No entanto, se o ponto de extremidade protegido for do Spring MVC, um invasor poderá ignorar esse controle abusando dos recursos de negociação de conteúdo do Spring MVC. Com o Spring MVC, os usuários podem especificar como desejam que o recurso seja fornecido usando o cabeçalho Accept ou especificando o tipo de conteúdo desejado usando uma extensão. Por exemplo, você pode solicitar o recurso /admin como um documento JSON enviando a solicitação a /admin.json.
As expressões de caminho Ant não consideram extensões de negociação de conteúdo. Portanto, a solicitação não corresponde à expressão /admin, e o ponto de extremidade não é protegido.

O Spring Security usa um controle de acesso baseado em expressão que permite que os desenvolvedores definam um conjunto de verificações a serem aplicadas a cada solicitação. Para determinar se o controle de acesso deve ser aplicado à solicitação, o Spring Security tenta fazer a correspondência entre ela e o correspondente de solicitação definido para cada verificação de segurança. Se a solicitação for correspondente, o controle de acesso será aplicado a ela. Existe um correspondente de solicitação especial para sempre corresponder a qualquer solicitação: anyRequest(). Se não for definida uma verificação de fallback que use o correspondente anyRequest(), isso poderá deixar pontos de extremidade desprotegidos.

Exemplo 1: O código a seguir define uma configuração do Spring Security que não define uma verificação de fallback:

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

No Example 1 acima, pontos de extremidade atuais ou futuros, /admin/panel, podem ficar desprotegidos.

O Spring Security inclui um firewall HTTP que ajuda a proteger o aplicativo, limpando solicitações que contêm caracteres potencialmente mal-intencionados. O Spring realiza isso incluindo o HttpFirewall em seu FilterChainProxy, que processa as solicitações antes que elas sejam enviadas pela cadeia de filtros. O Sprint Security usa a implementação StrictHttpFirewall por padrão.


Exemplo 1: O seguinte código torna mais flexível a política de firewall para permitir caracteres %2F e ;:

    <beans:bean id="httpFirewall" class="org.springframework.security.web.firewall.StrictHttpFirewall" p:allowSemicolon="true" p:allowUrlEncodedSlash="true"/>

Se forem permitidos caracteres potencialmente mal-intencionados, isso poderá levar a vulnerabilidades se esses caracteres forem processados de maneira incorreta ou inconsistente. Por exemplo, se o ponto e vírgula for permitido, isso habilitará parâmetros de caminho (conforme definido no RFC 2396), que não são processados consistentemente por servidores Web front-end como o nginx e servidores de aplicativos como o Apache Tomcat. Essas inconsistências podem ser usadas para ataques de passagem de caminho ou bypass de controle de acesso.

Qualquer servidor que contenha informações confidenciais ou funcionalidades privilegiadas, como um painel de administração remota, deverá exigir autenticação para acesso. Se esse não for o caso, um invasor poderá roubar informações confidenciais ou assumir o controle de um host alvo simplesmente adivinhando nomes de usuários comuns.

O cliente pode usar o método de autenticação NoneAuth para determinar os métodos de autenticação disponíveis.

Exemplo 1: O código Paramiko a seguir tenta se autenticar no servidor usando a solicitação de autenticação "none".

    client = SSHClient()
    client.connect(host, port, auth_strategy=NoneAuth("user"))

Os programas implantados fora da infraestrutura de rede uma empresa perdem as garantias internas de segurança de transmissão de dados. Um invasor residente em uma rede compartilhada pode ser capaz de espionar o tráfego não criptografado.

Os invasores podem atacar servidores MongoDB não autenticados para comprometer os dados neles armazenados e, dependendo da versão do MongoDB, estabelecer uma base de operações na sua rede interna, comprometendo esses servidores.

Diferentes ataques podem ser usados contra um servidor MongoDB para obter uma execução de código arbitrário em seu sistema operacional subjacente. Por exemplo, no passado, existiam vulnerabilidades que permitiam que os invasores transformassem uma vulnerabilidade de Server-Side JavaScript Injection em uma execução remota de código. Quando o servidor é usado para armazenar objetos, um invasor também pode armazenar cargas de desserialização para diferentes linguagens, como Java, Python, Ruby ou PHP, para obter a execução remota de código no ponto de extremidade de desserialização.

Observe que, mesmo que o servidor MongoDB não esteja exposto externamente, um invasor externo ainda pode acessá-lo, ou acessar a API REST, por meio de uma vulnerabilidade de Server-Side Request Forgery em qualquer aplicativo na mesma rede. Por exemplo, Servidores MongoDB podem ser atacados usando protocolos HTTP ou Gopher.

A falha em proteger a porta do MongoDB externamente pode ter um grande impacto na segurança. Por exemplo, um invasor externo pode usar um único comando remove para excluir todo o conjunto de dados. Recentemente, tem havido relatos de ataques mal-intencionados em instâncias desprotegidas do MongoDB abertamente em execução na Internet. O atacante apagou o banco de dados e exigiu que um resgate fosse pago para que ele pudesse ser restaurado.