Compreender o problema do representante confuso
O “problema do representante confuso” permite explicar a intensificação de privilégios no contexto da cibersegurança. Descreve um cenário no qual um programa, que designaremos de “representante”, possui determinadas permissões que são exploradas por um interveniente de má índole, o que faz com que o programa bem-intencionado aja em nome do invasor. Embora tenha sido criado para realizar funções legítimas, o programa fica “confuso” quando é incitado a usar seus privilégios indevidamente, o que resulta em ações não autorizadas.
A importância dos Grandes Modelos de Linguagem
Se analisarmos os Grandes Modelos de Linguagem (LLMs) nesta perspectiva, conseguimos notar os motivos que poderão levá-los a agir como representantes confusos. Se forem concedidos muitos privilégios aos LLMs, existe a possibilidade de que eles se tornem, inadvertidamente, uma ferramenta de execução de comandos ou de acesso a decisões de controle que beneficie o invasor. Esse risco realça a importância de gerenciar atentamente os privilégios concedidos aos LLMs, garantindo que eles funcionem em um ambiente seguro e controlado.
Os perigos do tratamento inseguro de resultados
Após a análise do problema do representante confuso, nós agora nos focaremos no tratamento inseguro de resultados no contexto dos modelos de linguagem (LLMs). Na terceira parte da nossa série sobre o top 10 do OWASP relativamente aos aplicativos LLM, destacamos a necessidade de estabelecer proteções contra o uso indevido dos resultados dos LLM. Tendo em conta que o conteúdo gerado pelos LLMs se baseia em prompts dos usuários, ele oferece aos mesmos uma forma de acesso indireto às funções subjacentes. Se não forem adequadamente validados e avaliados, esses resultados podem funcionar como uma porta de entrada para diversos tipos de ataques, como o XSS e o CSRF, ou ataques mais graves que têm como alvo sistemas de back-end, por exemplo, a execução de código remota e a intensificação de privilégios.
Analisar os riscos de segurança através de exemplos do mundo real
- A entrada direta de resultados gerados por LLM em comandos ou funções de sistemas, tais como “exec” ou “eval”, pode levar à execução de código remota não autorizada. Para que se compreenda melhor essa questão, vamos imaginar uma situação na qual um LLM é usado como assistente de execução de código. Um usuário incauto solicita o fornecimento de um trecho de código para realizar uma tarefa. Se a resposta do LLM incluir comandos a nível do sistema e o usuário inseri-los, inconscientemente, em sua linha de comando ou script, isso pode desencadear ações que comprometam a segurança do sistema.
- A criação de JavaScript ou Markdown por parte do LLM que, quando reenviados para o usuário, podem ser executados pelo navegador e causar, potencialmente, ataques de Cross-Site Scripting (XSS). Tomemos como exemplo um cenário no qual um usuário pede ajuda ao LLM no âmbito da realização de tarefas de desenvolvimento para a Web. Assim, o LLM cria um trecho de JavaScript ou Markdown. Se esse código contiver scripts maliciosos e o usuário integrá-los em seu aplicativo da Web, os referidos scripts poderão ser executados pelos navegadores de outros usuários, o que pode conduzir a uma violação de segurança. Além disso, podem ocorrer outras ações maliciosas, tais como o roubo de cookies, tokens de sessão ou, inclusive, a alteração da aparência de sites.
- Quando os plug-ins de terceiros se descuidam com a validação dos resultados, eles estão contribuindo para aumentar a probabilidade de ocorrência de problemas de segurança. Por exemplo, pensemos em um plug-in que formata comentários de usuários em um fórum. Se um LLM gerar uma resposta que contenha código executável e o plug-in não proceder à verificação do mesmo, existe a possibilidade de que o código seja divulgado. Uma vez publicado no fórum, o código poderá ser executado se for lido pelos usuários, resultando, eventualmente, no roubo de informações ou na adulteração de dados, o que comprova que esses plug-ins devem investir na avaliação rigorosa dos resultados, de modo a evitar violações de segurança.
O diagrama abaixo tem como objetivo dar a conhecer os caminhos que o invasor pode seguir no sentido de explorar essa vulnerabilidade específica no âmbito do funcionamento de um aplicativo corporativo. Preste atenção à seção “LLM02: tratamento inseguro de resultados” destacada no referido diagrama.
Medidas proativas e melhores práticas
- Trate todas as interações com o modelo com ceticismo, implementado uma política de confiança zero que assume que nenhum usuário, sistema ou processo (incluindo o modelo) seja inerentemente seguro. Esmiúce todos os resultados fornecidos pelo modelo recorrendo a processos de validação cuidadosos para detectar antecipadamente e neutralizar riscos de segurança antes de que eles afetem as funções do sistema.
- O Padrão de Verificação de Segurança de aplicativos (ASVS) do OWASP é um conjunto de parâmetros de referência de segurança concebido para fortalecer softwares através do estabelecimento de práticas de validação e proteção. Consulte estas diretrizes para codificar os resultados dos modelos, um procedimento indispensável para garantir proteção contra a execução de JavaScript ou Markdown indesejados por parte dos navegadores dos usuários. O ASVS disponibiliza estratégias de codificação detalhadas, destinadas a garantir a funcionalidade e a segurança dos dados dos usuários.
Um resumo e o que está por vir
No âmbito da análise do “problema do representante confuso” e do tratamento inseguro de resultados nos LLMs, realçamos a importância das permissões controladas e da gestão diligente dos resultados para evitar ações não autorizadas. Demonstramos, através de exemplos práticos, formas através das quais os LLMs podem ser usados como armas, caso eles não sejam devidamente protegidos.
Nesta série sobre a segurança dos aplicativos LLM, descrevemos duas das vulnerabilidades do OWASP e, nos próximos artigos, continuaremos a abordar esse tema vital, analisando as restantes vulnerabilidades e reforçando nossas defesas cibernéticas. Fique atento à próxima parte da nossa série referente às preocupações cibernéticas relacionadas com os aplicativos LLM.
