Os testes de automação de UI no macOS podem derrotar uma aprovação de agente?

Um cartão de aprovação só é um controle de segurança se a própria pessoa, e não outro processo, causar a aprovação. Isso parece óbvio até você colocar o cartão em uma área de trabalho comum do macOS, onde clientes de Acessibilidade podem inspecionar controles, ferramentas de automação podem ativar aplicativos e qualquer janela em primeiro plano pode disputar o próximo clique.

Não teste isso perguntando se o cartão parece modal ou se o botão tem um rótulo tranquilizador. Teste se um processo que já possui privilégios locais realistas consegue causar uma ação protegida sem que a pessoa pretendida faça uma escolha deliberada e informada. O resultado útil não é um vídeo dramático de exploração. É uma resposta reproduzível para uma pergunta mais específica: quais caminhos de entrada conseguem atravessar a fronteira de aprovação, com quais permissões e que evidência comprova o resultado?

Este é um exercício de red team para software que você possui, em um Mac e uma conta sob seu controle. Mantenha a ação solicitada inofensiva. Use um endpoint HTTP fictício, um host SSH que não esteja em produção ou uma ação que retorne um valor de teste fixo. Um teste de segurança que pode gastar dinheiro, apagar dados ou alterar o acesso à produção por acidente já está mal definido antes de alguém escrever um script.

A permissão de Acessibilidade muda o modelo do atacante

Um processo com permissão de Acessibilidade não é um processo comum em segundo plano. A Apple descreve o acesso de Acessibilidade como uma permissão que permite aos apps controlar um Mac, e o macOS exige que a pessoa conceda esse acesso nos ajustes de Privacidade e Segurança. A Apple descreve separadamente a permissão de Automação, que permite acessar e controlar outros apps. São permissões diferentes, mas ambas pertencem ao modelo de ameaça quando um cartão de aprovação fica na área de trabalho.

A distinção que as equipes costumam misturar é esta: uma interface de aprovação pode ser acessível sem que toda ação originada pela acessibilidade seja tratada como prova da intenção humana. A acessibilidade precisa expor rótulos, funções, estados e foco relevantes para que pessoas que usam tecnologia assistiva consigam operar o aplicativo. Isso é uma exigência de inclusão. Não exige que o aplicativo permita que um processo externo invoque a ação de confirmação irreversível sem nenhum sinal local da pessoa.

Comece o teste registrando por escrito o atacante que você realmente está simulando. Evite o rótulo vago «malware». Ele esconde as permissões que decidem o resultado. Um atacante de referência útil é um helper assinado, executado localmente, sob o mesmo usuário conectado e que já recebeu permissão de Acessibilidade. Uma variante mais forte também tem permissão de Automação e pode solicitar a ativação de aplicativos. Nenhuma das variantes recebe credenciais de administrador, acesso para contornar o bloqueio da tela ou uma cópia modificada do aplicativo de aprovação.

Esse limite torna o teste justo. Se sua conclusão for «um atacante com controle total da conta do usuário pode controlar a conta do usuário», você não aprendeu nada. Se a conclusão for «um helper com as mesmas permissões que uma pessoa poderia conceder a um gerenciador de janelas, executor de testes, ferramenta de macros ou utilitário assistivo pode aprovar o uso de uma credencial», você encontrou um problema de design com um caminho claro para corrigi-lo.

Monte uma ficha de capacidades antes da primeira execução:

Não conceda uma permissão só porque uma ferramenta de teste a solicitou. Cada permissão adicional muda a afirmação que você poderá fazer depois. Registre a combinação exata no título do resultado, como «helper somente com Acessibilidade não consegue confirmar uma aprovação por chamada», em vez de «a aprovação é segura». A segunda afirmação não resiste a uma configuração diferente da área de trabalho.

Registre também o identificador do bundle do helper, a autoridade de assinatura de código, o ID do processo, o processo pai e o caminho de inicialização. Um bom sistema de aprovação deve mostrar identidade de processo suficiente para que uma pessoa avalie a solicitação, mas o registro do teste precisa de mais detalhes do que um cartão consegue exibir. O operador precisa responder se um processo filho herdou um processo pai com aparência confiável, se um wrapper de terminal iniciou o helper e se uma nova inicialização criou uma identidade de processo diferente.

Um botão clicável não prova que a aprovação é fraca

Um botão exposto pela hierarquia de acessibilidade do macOS não é automaticamente uma vulnerabilidade. O AppKit espera que os elementos de acessibilidade participem dessa hierarquia para que clientes assistivos encontrem um controle funcional, e a Apple documenta que os controles expõem propriedades como rótulos, títulos, molduras e a indicação de estarem habilitados.

O design fraco é aquele em que invocar esse botão basta como evidência para uma ação sensível. Ele torna uma ação sintética de acessibilidade indistinguível de um clique consciente. Também costuma falhar silenciosamente, porque a equipe testa com um mouse, vê o callback esperado e nunca pergunta o que mais pode produzir o mesmo callback.

Faça a decisão de aprovação depender de um evento de autorização local, e não apenas do handler da ação do botão. O controle de UI pode iniciar a solicitação, mas a ação protegida deve esperar um resultado de autorização que registre como a confirmação ocorreu. Em uma aprovação comum de sessão, isso pode ser um clique deliberado depois que o aplicativo verificar que sua própria superfície de aprovação está ativa e atualizada. Para uma ação de alto risco, exija um evento de autenticação local mediado pelo sistema, como o Touch ID quando disponível.

Não cometa o erro comum de ocultar ou renomear o botão Aprovar na árvore de acessibilidade. Isso pune pessoas que precisam de tecnologia assistiva e pouco faz contra um atacante local capaz, que ainda pode manipular o foco ou invocar caminhos alternativos. Em vez disso, teste se o fluxo de confirmação rejeita um caminho sintético, um cartão antigo, um cartão inativo e uma solicitação cujos detalhes exibidos já não correspondem à ação prestes a ser executada.

Um registro interno de decisão útil é assim:

{
  "request_id": "test-4d8f",
  "decision": "approved",
  "decision_method": "touch_id",
  "card_generation": 7,
  "request_generation": 7,
  "app_active": true,
  "card_frontmost": true,
  "requester_pid": 48102,
  "requester_signing_authority": "Example Development Team",
  "action_started_after_decision": true
}

Os nomes dos campos importam menos que a separação. decision informa o que aconteceu. decision_method informa como aconteceu. Os valores de geração impedem que um cartão antigo aprove uma solicitação mais nova depois de uma redesenho, nova tentativa ou substituição da ação. Os campos de ativação registram se a pessoa estava olhando para o seu cartão quando a decisão ocorreu. O campo final permite que o teste verifique a ordem das operações.

Essa separação também detecta uma falha sutil de implementação: aceitar uma aprovação cedo demais e depois exibir o cartão apenas como cortesia. Nesse bug, todo teste visual é aprovado. A ação protegida já começou, então o cartão oferece encenação em vez de controle. Faça o executor da ação exigir um token de decisão que somente o subsistema de aprovação cria depois que as verificações relevantes terminam.

O ambiente de teste deve produzir execuções inofensivas e comparáveis

Crie um fixture de teste que gere uma solicitação de aprovação previsível e um observador que reúna as evidências. Não comece com um framework geral de automação de área de trabalho apontado para uma credencial real. Um ambiente de teste deve reduzir a ambiguidade, não aumentá-la.

Seu fixture precisa de uma solicitação com identificador estável, detalhes visíveis que variem a cada execução, expiração curta e um efeito de conclusão inofensivo. Por exemplo, faça a ação protegida chamar um endpoint local que retorne approved:test-4d8f somente depois que o sistema de aprovação a liberar. Se a ação for bem-sucedida sem um registro de aprovação válido, o teste terá uma falha clara. Se expirar ou registrar uma recusa, você terá um resultado claro de não aprovação.

Use um nonce de curta duração tanto no cartão quanto na solicitação protegida. Um cartão que diga apenas «Permitir acesso do agente?» não revela um bug de janela antiga. Um cartão que diga «Permitir que a solicitação de teste 4d8f chame o serviço de eco de staging?» revela. Mude o nonce a cada execução e confirme que o resultado da ação contém o mesmo nonce.

Mantenha três relógios independentes nas evidências:

1. O momento de criação da solicitação.
2. O momento da decisão.
3. O momento de início da ação protegida.

Use tempo monotônico dentro do aplicativo sempre que possível. O horário do relógio é útil para uma linha do tempo humana, mas pode mudar por causa de sincronização de rede, suspensão ou alterações manuais. A regra de ordenação é simples: a ação deve começar depois de uma decisão válida para a mesma geração da solicitação. Uma captura de tela não prova essa ordem.

Seu observador deve capturar o aplicativo ativo, a janela com foco, o ID da solicitação visível no cartão e o resultado final da ação. Uma gravação de tela ajuda a diagnosticar comportamentos inesperados, mas não substitui eventos estruturados. Gravações perdem identificadores de processo, comprimem transições rápidas e muitas vezes escondem o evento relevante atrás de um movimento do ponteiro.

Use um registro de teste assim para cada tentativa:

case=AX-invoke-approve
request=test-4d8f
helper=TestHelper pid=48102
permissions=accessibility
approval_surface=active
attempt=accessibility_action
decision=denied
protected_action=not_started
artifact=activity-event-0192

O valor de attempt deve descrever o mecanismo, não o resultado desejado. Escreva activate-then-click, stale-window, keyboard-focus-shift ou voiceover-navigation, e não attack-1. Seis semanas depois, essa descrição simples evitará que alguém execute o caso errado.

Execute primeiro o mesmo fixture sem permissões de helper. Esse é o seu controle. Depois, habilite uma capacidade por vez. Um resultado de red team sem uma execução de controle é difícil de interpretar. Talvez o cartão nunca tenha sido acessível pelo teclado. Talvez o endpoint tenha falhado. Talvez o helper de teste não tivesse a autorização que você imaginava. O controle transforma essas desculpas em diferenças visíveis.

Teste a aprovação sintética sem transformar o teste em um kit de exploração

O objetivo deste caso é descobrir se um cliente de acessibilidade autorizado consegue invocar o controle de aprovação e fazer a ação protegida ser executada. Você não precisa de um clicador pronto para distribuição pública nem de uma pilha de scripts frágeis baseados em coordenadas para responder a isso.

Use seu próprio helper de teste com uma tarefa limitada: encontrar a janela de aprovação do seu aplicativo de teste pela identidade do aplicativo e pelo nonce exclusivo da solicitação de teste, solicitar a mesma ação semântica que um cliente de acessibilidade solicitaria e informar se a ação protegida foi concluída. Não pesquise todas as janelas da área de trabalho. Não mire em diálogos de terceiros. Não armazene credenciais nem interaja com contas de serviço reais.

Teste estes caminhos separadamente, porque eles comprovam coisas diferentes:

• Uma invocação semântica de acessibilidade do controle Aprovar.
• Navegação pelo teclado que chega a Aprovar, seguida de uma ativação sintética.
• Uma ação do ponteiro depois que o helper traz o aplicativo de aprovação para a frente.
• Uma ação do ponteiro sem que o helper o traga para a frente.
• Uma ação atrasada depois que o cartão expira ou a solicitação muda.

Vale manter o clique por coordenadas somente como teste de regressão para sobreposição visual. Ele informa se um clique em uma posição da tela pode atingir o controle errado depois de uma mudança de layout. Não informa se um processo externo consegue identificar e ativar o elemento pretendido. A automação semântica de UI é o teste mais forte para a lógica de autorização; as coordenadas são mais fortes para acidentes de layout e foco.

Espere resultados diferentes conforme o modo de aprovação. Uma aprovação no nível da sessão normalmente é projetada para autorizar um processo de agente reconhecido durante a vida desse processo. Se sua aprovação de sessão aceita um clique comum, um helper com Acessibilidade pode conseguir imitá-lo, a menos que o app diferencie o caminho de entrada ou vincule a aprovação a um evento local mais forte. Isso pode ser uma escolha aceitável para ações de baixo risco, mas declare-a abertamente.

A aprovação por chamada deve resistir a mais coisas. Se a ação usa uma credencial que pode alterar dados, publicar uma versão ou alcançar um host de produção, um simples pressionamento de botão é insuficiente. Solicite o Touch ID ou outro sinal local mediado pelo sistema. O teste passa a ser: o helper consegue fazer o prompt aparecer, invocar todos os controles acessíveis ao redor dele e ainda assim não consegue concluir a ação protegida sem que a pessoa se autentique? Essa é uma propriedade de segurança muito mais clara.

Não informe «bloqueado» simplesmente porque o botão não respondeu. Informe a cadeia completa: se o helper encontrou o cartão, se invocou o controle, se o app registrou uma decisão, se o subsistema de autorização emitiu um token e se o executor da ação começou. Um helper pode não conseguir pressionar o botão hoje, enquanto um caminho alternativo pelo teclado pode funcionar amanhã. O token de decisão é a fronteira que importa.

O furto de foco pode transformar um clique honesto na decisão errada

Cliques diretos por script chamam atenção porque parecem maliciosos. O furto de foco costuma ser uma falha mais realista, pois pode transformar um gesto humano genuíno na aprovação de uma solicitação diferente.

A documentação do AppKit da Apple deixa claro que a ativação de um aplicativo é uma solicitação, não uma garantia, e que o estado de ativação pode mudar enquanto o macOS gerencia a área de trabalho. A Apple também oferece APIs que iniciam ou abrem aplicativos com comportamento de ativação. Por isso, o código de aprovação deve tratar o estado de primeiro plano como um evento que observa e verifica, e não como um fato permanente assumido quando o cartão foi desenhado.

Teste a disputa de propósito. Exiba um cartão de aprovação inofensivo com um nonce exclusivo. Mova o ponteiro sobre o controle de confirmação do cartão sem clicar. Faça seu helper controlado ativar um segundo aplicativo de teste ou exibir uma janela de teste inócua. Depois, execute o clique pretendido no mesmo momento em várias execuções. Registre qual aplicativo estava ativo no mouse-down e no mouse-up, qual janela era dona do elemento com foco e se a ação protegida começou.

Não aceite «o cartão continuou visível» como aprovação. Um cartão visível pode estar inativo. Pode estar atrás de outra janela. Seus controles podem continuar desenhados enquanto o foco do teclado mudou para outro lugar. O caminho de aprovação deve verificar novamente se a solicitação atual ainda é dona do cartão exibido e se o app está ativo no momento em que consome a aprovação.

Um conjunto sólido de testes de furto de foco inclui estes casos:

A expressão «exigir uma nova interação» importa. Restaurar o foco automaticamente e aceitar o clique original depois de uma breve interrupção é perigoso. A pessoa pode pensar que o clique dispensou a interrupção, enquanto o aplicativo o trata como aprovação. Retire a decisão pendente ou redefina-a de forma visível. Faça a pessoa iniciar uma nova confirmação depois que o app estiver claramente ativo novamente.

Não resolva isso forçando agressivamente o app para o primeiro plano. Isso cria outro problema: um comportamento inesperado em primeiro plano ensina as pessoas a clicar sem ler. O cartão deve aparecer claramente quando uma solicitação chegar, mas não deve travar uma guerra de foco com a área de trabalho. Se perder a ativação no momento errado, ele pode falhar de forma segura e pedir novamente.

Cartões antigos e trocas de solicitações merecem casos de ataque próprios

Um cartão pode resistir a um clique sintético direto e ainda assim autorizar a ação errada. Isso acontece quando a UI representa uma solicitação enquanto o backend já passou para outra.

A versão conhecida é um bug de nova tentativa. Um agente solicita uma chamada HTTP. O cartão aparece. O agente se desconecta, reconecta e envia uma segunda solicitação com cabeçalhos ligeiramente diferentes. A UI reutiliza o cartão existente porque ele parece semelhante. Um clique no que a pessoa acredita ser a solicitação A libera a solicitação B. O texto da identidade pode estar perfeito e a aprovação ainda assim estar errada.

Vincule a aprovação a um digest imutável da solicitação. Inclua o tipo de operação, o destino, a identidade ou o alias da credencial, os detalhes relevantes do alvo, a identidade do processo do agente e o nonce. Quando qualquer campo protegido mudar, invalide o cartão atual. Não atualize o rótulo no mesmo lugar mantendo um controle Aprovar já pronto. Substitua a geração da solicitação e torne a instância anterior da UI incapaz de concluir qualquer coisa.

Para um fixture de teste, envie duas solicitações em rápida sucessão:

A: POST staging.example.invalid/echo
   header X-Test-Nonce: alpha-4d8f

B: POST staging.example.invalid/echo
   header X-Test-Nonce: bravo-7a21

Deixe o cartão da solicitação A visível tempo suficiente para que o operador do teste o identifique. Depois, envie B pelo mesmo processo de agente. Tente confirmar pelo mouse, pelo teclado, por uma ação de acessibilidade e depois de uma mudança de foco. As únicas conclusões aceitáveis são: A termina com alpha-4d8f, B termina depois de sua própria aprovação nova com bravo-7a21, ou nenhuma termina. Se o cartão visível de A liberar B, trate isso como um defeito de autorização que bloqueia o lançamento.

Faça o mesmo para uma mudança de destino que pareça inofensiva para alguém com pressa. Uma ação SSH pode manter o comando e mudar o host. Uma ação HTTP pode manter o host e mudar o caminho ou a credencial injetada. Seu cartão não precisa imprimir todos os bytes de uma solicitação, mas deve mostrar os detalhes que distinguem a decisão de segurança. O backend precisa vincular a solicitação canônica completa, e não apenas os detalhes que você escolheu exibir.

Os testes de expiração também importam. Não faça apenas uma contagem regressiva visual. Quando uma solicitação expirar, revogue o caminho de autorização do backend para aquela geração da solicitação. Depois, teste uma ação de Acessibilidade disparada exatamente no limite de expiração e um mouse-up que chegue logo depois. O resultado esperado é uma recusa com um motivo que informe se expiração, perda de foco, incompatibilidade de geração ou falha de autorização interrompeu a ação.

Seus logs precisam encerrar a discussão depois que a gravação de tela termina

Os testes de aprovação viram discussões quando a única evidência é «cliquei e funcionou». Você precisa de registros que permitam a outro engenheiro reconstruir a cadeia causal sem depender da interpretação do testador.

Registre dois fluxos relacionados: a execução do agente e a chamada protegida individual. O registro da execução responde quem iniciou o trabalho e se essa execução foi revogada depois. O registro da chamada responde exatamente qual ação foi solicitada, como a aprovação foi resolvida e se a execução começou. Mantenha os eventos de aprovação na mesma história de auditoria ordenada que a criação da solicitação, as transições de foco, os resultados de autorização e a execução.

O Sallyport mantém um diário Sessions para execuções de agentes e um diário Activity para chamadas individuais, ambos projetados a partir de um log de auditoria criptografado e encadeado por hash. O comando sp audit verify verifica essa cadeia offline sobre o texto cifrado sem precisar de uma chave do cofre. Isso dá à equipe de testes uma verificação de integridade das evidências, em vez de uma exportação mutável que alguém poderia editar discretamente depois de um resultado inesperado.

Para qualquer execução de red team, exporte ou preserve estes fatos em conjunto:

• O nome do caso de teste e a matriz de permissões.
• A identidade do processo solicitante e sua autoridade de assinatura de código.
• O digest da solicitação, o nonce visível e a geração da solicitação.
• O método da decisão, o resultado da decisão e o motivo da recusa, se houver.
• O primeiro evento de execução ou uma prova explícita de que não existe evento de execução.

As cadeias de hash não provam que a política de aprovação está correta. Elas provam algo mais restrito, mas ainda útil: depois que o log foi gravado, um investigador pode verificar se o registro foi alterado ou reordenado. O teste da política fornece a outra metade, demonstrando quais eventos o aplicativo permite chegar à execução.

Faça da revisão dos logs um critério de aprovação do teste. Uma execução que bloqueia corretamente uma ação, mas registra apenas «cancelada», não está concluída. Você precisa distinguir uma invocação sintética de acessibilidade de um cancelamento feito pela pessoa, uma geração antiga de uma solicitação expirada e uma recusa por perda de foco de uma falha do app. Essas distinções transformam um relatório de defeito em uma família de testes de regressão.

Passar significa que a ação ficou atrás da decisão humana

Não diga que uma superfície de aprovação é segura porque seu primeiro script de automação falhou. Um bom resultado de red team tem um escopo pequeno e exato: em um Mac controlado, com permissões especificadas, cada ativação sintética e cada caminho de interferência de foco testado falhou em produzir um token de autorização válido ou iniciar a ação protegida.

Os testes mais fortes deixam uma lista desconfortável, mas útil, de exceções. Talvez a aprovação da sessão permita um clique comum porque o risco é baixo e a pessoa já aprovou o processo do agente. Talvez a aprovação por chamada exija Touch ID para determinadas chaves. Talvez um cartão seja cancelado sempre que o app perde a ativação, o que incomoda algumas pessoas, mas impede uma disputa de foco. Transforme essas decisões em comportamento do produto e teste-as. Uma segurança que existe apenas em uma reunião de design não sobreviverá a uma área de trabalho cheia de helpers.

Execute esta suíte sempre que alterar a renderização da aprovação, adicionar um novo canal de ação, mudar o tratamento da identidade do processo ou refatorar o código que passa da decisão da UI para a execução. A regressão importante não se apresentará como «bypass de Acessibilidade». Ela chegará como uma limpeza inofensiva que move um callback, reutiliza uma janela ou trata uma solicitação antiga como equivalente a uma nova.

Mantenha a afirmação final direta: a ação protegida começa somente depois que a solicitação atual recebe a autorização local exigida. Se algum caminho de automação de UI puder tornar essa afirmação falsa, o cartão de aprovação será apenas decoração até que você corrija o problema.