Segurança de software não é o mesmo que software de segurança. Aqui, estamos interessados em tópicos como autenticação, controle de acesso, confidencialidade, criptografia e gestão de privilégios.
<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>
<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>
writePermission definida.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.writePermission.<provider android:name=".ContentProvider" android:writePermission="content.permission.WRITE_CONTENT"/>
...
context.registerReceiver(broadcastReceiver, intentFilter);
...
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.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>
<provider android:name=".ContentProvider"/>
...
context.sendBroadcast(intent);
...
normal.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.normal.<permission android:name="custom.PERMISSION"
android:label="@string/label_permission"
android:description="@string/desc_permission"
android:protectionLevel="normal">
</permission>
permission de acesso combinado de leitura e gravação.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.permission de acesso combinado de leitura e gravação.<provider android:name=".ContentProvider" android:permission="content.permission.READ_AND_WRITE_CONTENT"/>
...
context.sendStickyBroadcast(intent);
...
android.permission.android.permission pode ter consequências inesperadas quando o sistema operacional é atualizado. Se a versão mais recente do sistema operacional definir exatamente a mesma permissão, o Android Package Management Service (PMS) concederá silenciosamente a permissão ao aplicativo, sem pedir ao usuário que permita ataques de escalonamento de privilégios.
myModule.config(function($compileProvider){
$compileProvider.imgSrcSanitizationWhitelist(/^(http(s)?|javascript):.*/);
});
myModule.config(function($sceProvider){
$sceProvider.enabled(false);
});
DangerousEnableCompression como true para ativar a extensão “per-message-deflate”:Exemplo 2: O código a seguir usa
app.Run(async context => {
using var websocket = await context.WebSockets.AcceptWebSocketAsync(new WebSocketAcceptContext() { DangerousEnableCompression = true });
await websocket.SendAsync(...);
await websocket.ReceiveAsync(...);
await websocket.CloseAsync(WebSocketCloseStatus.NormalClosure, null, default);
});
DangerousDeflateOptions para definir as opções para a extensão “per-message-deflate”:
using ClientWebSocket ws = new() {
Options = {
CollectHttpResponseDetails = true,
DangerousDeflateOptions = new WebSocketDeflateOptions() {
ClientMaxWindowBits = 10,
ServerMaxWindowBits = 10
}
}
};
WindowsIdentity.Impersonate().
using System.Security.Principal;
...
//Get the identity of the current user
IIdentity contextId = HttpContext.Current.User.Identity;
WindowsIdentity userId = (WindowsIdentity)contextId;
//Temporarily impersonate
WindowsImpersonationContext imp = userId.Impersonate();
//Perform tasks using the caller's security context
DoSecuritySensitiveTasks();
//Clean up and restore our old security context
impersonate.Undo();
Example 1 personifica o contexto de segurança do usuário atual e o utiliza para realizar uma operação privilegiada. Depois de chamar DoSecuritySensitiveTasks(), o código tenta restaurar o contexto de segurança original. No entanto, se DoSecuritySensitiveTasks() lançar uma exceção, o método Undo() nunca será chamado, e o programa continuará a usar o contexto de segurança representado.