Análise de Segurança Baseada em Roles para Fábricas de Software

09/09/2019 ∙ by Miguel Loureiro, et al. ∙ 0

Most software factories contain applications with sensitive information that needs to be protected against breaches of confidentiality and integrity, which can have serious consequences. In the context of large factories with complex applications, it is not feasible to manually analyze accesses to sensitive information without some form of safety mechanisms. This article presents a static analysis technique for software factories, based on role-based security policies. We start by synthesising a graph representation of the relevant software factories, based on the security policy defined by the user. Later the graph model is analysed to find access information where the security policy is breached, ensuring that all possible execution states are analysed. A proof of concept of our technique has been developed for the analysis of OutSystems software factories. The security reports generated by the tool allows developers to find and prioritise security breaches in their factories. The prototype was evaluated using large software factories, with strong safety requirements. Several security flaws were found, some serious ones that would be hard to be detected without our analysis.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introdução

Na informática, a segurança é uma área em constante evolução, de importância cada vez maior à medida que a nossa sociedade se vai tornando cada vez mais avançada e dependente em infraestructuras como a internet. Relatórios de segurança recentes111Relatórios de segurança da Symantec 2017 e 2018: https://www.symantec.com/content/dam/symantec/docs/reports/istr-22-2017-en.pdf e https://www.symantec.com/security-center/threat-report mostram que em 2017 houve um aumento de 13% no número de vulnerabilidades de segurança encontradas. Outro relatório de segurança222Relatório de seguraça Trustwave 2017: https://www2.trustwave.com/2017-Trustwave-Global-Security-Report.html/ mostra que mais de metade das vulnerabilidades de segurança encontradas em aplicações web fazem parte da categoria de fugas de informação.

Vulnerabilidades de segurança, nomeadamente fugas de informação, têm repercussões negativas tanto para clientes como para empresas. Expor a informação pessoal de um indivíduo pode ter efeitos graves. Por exemplo, se a informação bancária de um cliente for exposta publicamente, é um alvo para roubo, ou se informação pessoal sensível for exposta pode ser vítima de roubo de identidade. Ao nível empresarial, fugas de informação reduzem o nível de confiança dos clientes, afetam o seu valor de mercado, e criam complicações legais.

Este trabalho foi desenvolvido com o objetivo de melhorar a segurança de fábricas de software, i.e., um conjunto de aplicações que podem estar relacionadas e nas quais pode existir troca de informação. Em fábricas de software compostas por um número elevado de aplicações web que trabalhem com informação sensível, torna-se difícil assegurar que não existem falhas de segurança. Devido à quantidade de aplicações e à complexidade de cada uma delas, é complicado determinar que informação é exposta para cada um dos roles em cada entrypoint (e.g., ecrãs, endpoints REST). Assim, torna-se difícil colocar os devidos mecanismos de segurança para proteger informação sensível, e ainda mais difícil determinar à posteriori onde faltam estes mecanismos de segurança.

Surge assim um problema para equipas que desenvolvam fábricas de software de grandes dimensões. É inevitável que, por vezes, os programadores se esqueçam de proteger informação sensível com mecanismos de segurança. Assim, existe uma propagação de falhas de segurança, que dificilmente será manualmente detetadas posteriormente. Portanto, é inexequível garantir a segurança de uma fábrica de software sem uma análise de segurança que detete falhas.

As contribuições chave apresentadas neste artigo são uma técnica de análise estática de segurança para fábricas de software compostas por várias aplicações web com um modelo de controlo de acesso baseado em roles. A análise recebe uma política de segurança que associa recursos a roles e encontra, analisando todas as aplicações da fábrica, entrypoints e sub-rotinas chamadas, onde a política é quebrada.

A técnica foi implementada numa ferramenta proof of concept direcionada para fábricas de software OutSystems. Depois de detetar falhas de segurança numa fábrica, a ferramenta gera um relatório de segurança que, ao dar visibilidade a estas falhas, ajuda o utilizador a encontrar e prioritizar falhas na sua fábrica de software.

O resto do documento está estruturado da seguinte forma. Na Secção 2 é feita a descrição geral da técnica de análise. Na Secção 3 é apresentada a descrição da implementação da técnica numa proof of concept. A descrição da avaliação à técnica desenvolvida é apresentada na Secção 4. De seguida, a Secção 5 descreve o trabalho relacionado à técnica desenvolvida. Por último, a Secção 6 apresenta as conclusões e observações finais.

2 Visão Geral da Análise

Nesta secção é feita uma descrição geral da técnica de análise estática desenvolvida. São feitas as seguintes assunções sobre a arquitetura duma aplicação web genérica que utilize um modelo de controlo de acessos baseado em roles:

  • Os utilizadores do sistema têm um ou mais roles atribuídos;

  • O acesso a cada entrypoint pode estar limitado a um ou mais roles;

  • O modelo contém primitivas para atribuir, remover e verificar roles.

A nossa técnica de análise tem por base numa política de segurança definida pelo utilizador. Cada uma das regras da política de segurança consiste num recurso (e.g., uma tabela de uma base de dados) e nos conjuntos de roles com acesso de leitura e de escrita. A Figura 1 mostra um exemplo duma política de segurança, que define que o recurso (entidade) Client pode ser lido e escrito pelos roles Admin e Lawyer, e pode ser lido pelo role Customer.

Figura 1: Exemplo de uma política de segurança

O processo de análise começa por produzir uma síntese da fábrica de software com base na política de segurança recebida. Tendo em conta a dimensão das fábricas de software e à quantidade de elementos diferentes e complexos que cada fábrica pode ter, é importante construir um modelo sintetizado, só com informação relevante, sob o qual se pode realizar a análise.

O modelo sintetizado duma fábrica de software é construído num call graph, um grafo que representa as relações de chamada entre sub-rotinas dum programa. Este call graph contém:

  • Os entrypoints das várias aplicações da fábrica;

  • As sub-rotinas chamadas por cada entrypoint da fábrica;

  • As primitivas de leitura e escrita de recursos da fábrica;

  • Os recursos da fábrica.

Um call graph apenas com esta informação já daria resultados úteis, mas devido à falta de alguma informação relevante – como as chamadas de primitivas que atribuem, retiram ou verificam os roles de um utilizador – ia resultar num elevado número de falsos positivos. Como tal, os nós do call graph associados a sub-rotinas guardam também o control flow graph (CFG) dessa sub-rotina.

Depois de construir o modelo sintetizado, o modelo é analisado à procura de falhas de segurança. Esta análise é composta por três passos:

  1. Procurar potenciais falhas de segurança no call graph;

  2. Expandir o call graph de cada potencial falha, usando os CFGs das sub-rotinas;

  3. Analisar o CFG de cada potencial falha, para validar a existência de uma falha.

O primeiro passo consiste em utilizar o call graph para encontrar todas as potenciais falhas de segurança. Uma potencial falha é um caminho entre um recurso X que faça parte da política de segurança e um entrypoint Y que permita o acesso a um utilizador com um role que não faça parte da política de X. É de notar que não é possível determinar de forma definitiva que os caminhos identificados representam falhas reais, pois o call graph não tem informação completa, como primitivas que verificam se o utilizador atual possuí um role (check role). A Figura 2 mostra um exemplo da utilização de uma verificação de role para proteger o acesso a um recurso – só se o utilizador tiver o role Admin é que a operação de escrita DeleteLegalCase vai ser chamada. Se um recurso identificado como uma potencial falha estiver protegido por um check role usado num bloco condicional, então trata-se dum falso positivo. Para encontrar todas as potenciais falhas, é utilizado um algoritmo de pesquisa em profundidade.

O segundo passo consiste em expandir o call graph de cada potencial falha com o CFG interno de cada sub-rotina. Obtém-se assim um CFG, com mais informação em relação ao call graph.

O terceiro passo consiste em analisar o CFG resultante do segundo passo para validar a potencial falha encontrada. Esta análise é feita com um algoritmo de pesquisa em profundidade eficiente333Não percorre caminhos redundantes.. A análise dum CFG começa no nó do entrypoint e é mantido um estado durante a análise de cada caminho. Este estado vai conter os roles que o utilizador pode ter e os roles que o utilizador tem.

O estado inicial é determinado a partir do conjunto de roles com acesso ao entrypoint, sendo atualizado durante a travessia com as primitivas que atribuem, retiram ou verificam um role ao utilizador. Um dos mecanismos de segurança usados consiste na utilização da primitiva check role dentro de um bloco condicional. O estado vai ser alterado para cada ramo do bloco condicional, consoante a condição usada. Ao passar por um nó dum recurso que pertença à política de segurança, verifica-se o estado para determinar se existe uma falha de segurança. Se o utilizador não possuir um dos roles da política, e puder ter um role que não faça parte da política, trata-se duma potencial falha de segurança que deve ser reportada.

O resultado da análise é um conjunto de entrypoints com falhas de segurança, as sub-rotinas chamadas por cada entrypoint com falhas de segurança, e os caminhos tanto no call graph como no control flow graph de cada falha encontrada.

Na próxima secção é descrito como é que os resultados da análise são usados para ajudar o utilizador final a visualizar e a prioritizar as falhas encontradas.

3 Ferramenta de Análise e Relatórios de Segurança

Nesta secção é descrita a implementação da técnica de análise de segurança e a geração de relatórios com o resultado da análise. A implementação da técnica foi direcionada a fábricas de software OutSystems, e para tal foi feito um mapeamento dos elementos do modelo genérico da análise para elementos do modelo OutSystems.

A OutSystems444https://www.outsystems.com/ é uma plataforma que permite o desenvolvimento rápido de aplicações web e mobile. As aplicações OutSystems podem ter vários entrypoints, e.g., ecrãs, endpoints REST, endpoints SOAP. Um ecrã é um elemento do modelo OutSystems que contém uma interface para utilizador final interagir com a aplicação e que é usado como entrypoint da aplicação.

Para simplificar, a nossa análise só contempla ecrãs como entrypoints de aplicações. Um ecrã em OutSystems tem um conjunto de permissões, ou seja, um conjunto de roles com acesso ao ecrã. Em OutSystems, os dados (sensíveis ou não) duma aplicação estão armazenados em entidades. Pode-se assumir que uma entidade OutSystems é uma tabela numa base de dados SQL. O modelo OutSystems possuí três primitivas de RBAC – GrantRole, RevokeRole e CheckRole – que respetivamente atribuem um role ao utilizador, retiram um role ao utilizador, e verificam se o utilizador tem um role.

Figura 2: Exemplo de CheckRole a proteger o acesso de escrita a uma entidade LegalCase

Em OutSystems é comum utilizar a primitiva CheckRole para proteger o acesso a entidades. A Figura 2 contém um exemplo dum CheckRole dentro dum bloco condicional a garantir que o acesso à entidade LegalCase é restrito a utilizadores com o role Admin.

O caminho duma potencial falha de segurança começa num ecrã e termina numa entidade. Um ecrã possuí ações que podem aceder a entidades, ou podem chamar outras ações que eventualmente acedem a uma entidade. Mais precisamente, uma potencial falha de segurança consiste num caminho entre uma entidade que faz parte da política de segurança, um ecrã que permite a entrada a roles que não fazem parte da política de segurança da entidade, e um caminho sem mecanismos de segurança até à entidade.

No desenvolvimento da ferramenta foi implementada uma interface para ajudar os utilizadores a definirem as suas políticas de segurança. A interface mostra uma lista de todas as entidades e roles da fábrica de software e permite o utilizador definir que roles têm acesso de leitura e escrita a cada entidade. Cada regra duma política de segurança associa a cada entidade dois conjuntos de roles, os roles com acesso de leitura e os roles com acessos de escrita.

Após a definição da política de segurança, pode-se executar a análise, cujo resultado vai ser uma coleção de ecrãs com (potenciais) falhas de segurança, cada um com uma coleção de ações com falhas, mais os respetivos caminhos do call graph e CFG.

Figura 3: Relatório de segurança

Para que resultados da análise sejam úteis para o utilizador final, a ferramenta constrói também um relatório de segurança. O relatório vai mostrar todas as falhas encontradas, ordenando-as por risco de modo a ajudar a sua prioritização. A Figura 3 mostra um relatório de segurança produzido pela ferramenta. Este relatório começa por listar todos os módulos de aplicação com potenciais falhas de segurança. Em cada entrada do relatório é também mostrado o número de falhas encontradas e que roles é que quebraram a política de segurança. Ao selecionar uma entrada do relatório, essa é expandida e são mostrados todos os ecrãs desse módulo que contêm falhas. Um entrada dum ecrã também pode ser expandida, mostrando todas as ações com falhas encontradas nesse ecrã. A Figura 3 mostra que foram encontradas falhas no módulo “LaywerExample”, mais especificamente no seu ecrã “SecretAdminPage”. Neste ecrã, para cada um dos roles Registered, Anonymous e Client, foram encontradas duas potenciais falhas de segurança, onde utilizadores com esses roles podem ter acesso indevido a uma entidade.

Nas entradas de ecrãs e ações, é também possível selecionar no botão “Inspect Call Graph”, que vai mostrar o call graph da(s) falha(s) encontradas naquele ecrã/ação. A Figura 4 mostra esta funcionalidade do relatório de segurança.

Figura 4: Relatório de segurança, com call graph expandido

4 Avaliação

Esta secção descreve a avaliação empírica da ferramenta que implementa a análise para fábricas de software OutSystems, descrita na Secção 3.

Para a avaliação foram utilizadas três fábricas de software. A primeira fábrica é um mock-up que consiste num exemplo simples dum sistema de gestão para uma firma de advogados. As outras duas fábricas utilizadas, A e B, são fábricas de clientes da OutSystems 555Não revelados por motivos de privacidade.. A utilização de uma fábrica mock-up é útil porque é possível introduzir falhas de segurança e verificar se a análise é capaz de as detetar. No entanto não é suficiente, não só devido à sua reduzida dimensão mas também porque numa fábrica real podem-se encontrar falhas que dificilmente seríamos capazes de reproduzir.

A fábrica mock-up tem dois módulos, um para a UI da aplicação e outro para o modelo de dados. O modelo de dados é simples e contém três entidades: Client, Lawyer e LegalCase. Client representa os clientes da firma de advogados, Lawyer representa os advogados da firma, e LegalCase representa os processos legais da firma. Cada processo está associado a um cliente e a um advogado.

Nesta fábrica foram introduzidas algumas falhas de segurança, por exemplo, ecrãs (entrypoints) que dão acesso a roles que não deviam e que chamam ações (sub-rotinas) que acedem a entidades sensíveis sem checks de segurança.

Em relação às fábricas de software dos clientes, a fábrica A é de tamanho médio, com cerca de 30 módulos, tendo mais de 200 ecrãs (entrypoints), 200 entidades e 35 roles. Esta fábrica contém várias aplicações usadas internamente por uma empresa.

A fábrica B é uma das maiores fábricas existentes em OutSystems. Contém mais de 700 módulos de aplicação, com mais de 2000 entidades, 2500 ecrãs e 321 roles. A fábrica B contém um sistema semelhante ao mock-up da firma de advogados, mas direcionado para uma área profissional diferente. Esta fábrica vai ser o nosso benchmark para performance e escalabilidade. Ou seja, se a nossa técnica tiver boa performance com esta fábrica podemos assumir que a sua performance também será boa para a maioria das fábricas de software existentes.

4.1 Validação

Para validar a nossa técnica, testámos-la com as três fábricas de software. Utilizando a nossa política de segurança para a fábrica mock-up, os resultados obtidos foram todos corretos. A análise foi capaz de detetar todas as falhas de segurança introduzidas, sem falsos positivos nem falsos negativos.

Em relação às fábricas de software A e B, seria virtualmente impossível validá-las completamente, devido às suas dimensões, falta de contexto, complexidade de políticas de segurança e quantidade de resultados em cada relatório. Foi feita uma amostragem de resultados de análises às fábricas A e B, que foi validada manualmente.

Para validar a nossa análise das fábricas A e B, obtivemos algumas políticas de segurança dos clientes, e também definimos algumas políticas nossas. Para as regras que definimos, escolhemos entidades que incluíam informação sensível e declaramos que os roles públicos não devem ter acesso a estas entidades. Note-se que todos os utilizadores com uma conta têm por defeito o role Registered e todos os utilizadores têm por defeito o role Anonymous. Estes dois roles vão ter a maior pool de utilizadores, por esse motivo entidades sensíveis não devem ser acedidas por utilizadores que só possuam roles atribuídos por defeito.

Ecrãs Ecrãs Falhas Falsos % de falhas
com falhas validados reais positivos reais
Política 1 5 5 0 5 0%
Política 2 9 9 9 0 100%
Tabela 1: Validação dos resultados da fábrica de software A

Da fábrica A foram usadas duas políticas de segurança fornecidas pelos donos da fábrica. Executámos a análise e obtemos dois relatórios. Do que observámos, a fábrica A parece estar bem protegida, pois os dois relatórios são pequenos (quando comparados com os da fábrica B). A Tabela 1 contém os resultados da nossa validação à fábrica A.

As políticas de segurança usadas para a fábrica A foram:

  • A entidade da Política 1 contém informação relacionada com uma aplicação de feedback de empregados, e restringe acesso a utilizadores que tenham apenas os roles por defeito do sistema.

  • A entidade da Política 2 contém informação relacionada com o sistema de gestão financeira duma empresa. Esta entidade só deve ser acedida pelos roles de administrador, back-office ou de gestor financeiro.

O relatório obtido com a política 1 mostrou 5 ecrãs com falhas de segurança. Todas as 5 falhas reportadas eram falsos positivos, causados por uma limitação na nossa análise. A questão é que a equipa de desenvolvimento da fábrica A utilizam outros mecanismos de segurança para além das primitivas CheckRole. Nestes casos o resultado duma query estava a ser filtrado pelo identificador do utilizador.

O relatório obtido com a política 2 mostrou 9 ecrãs com falhas de segurança. Os 9 ecrãs foram validados e continham falhas de segurança. Estes ecrãs não tinham os roles corretos nas suas permissões e não possuíam nenhum mecanismo de segurança nas ações que invocavam.

Da fábrica B foram usadas 5 políticas de segurança, cada uma relacionada com uma entidade na fábrica:

  • A entidade da Política 1 contém informação pessoal sobre os clientes da empresa, e proíbe o seu acesso a utilizadores que só tenham os roles por defeito do sistema;

  • A entidade da Política 2 contém informação sobre o sistema de biométrica da empresa, e proíbe o seu acesso a utilizadores que só tenham os roles por defeito do sistema;

  • A entidade da Política 3 contém informação específica sobre empregados da empresa, e proíbe o seu acesso a utilizadores que só tenham os roles por defeito do sistema;

  • A entidade da Política 4 contém informação sobre o stock dum produto utilizado na empresa, e proíbe o seu acesso a utilizadores que só tenham os roles por defeito do sistema;

  • A entidade da Política 5 contém informação específica sobre alguns clientes da empresa, e proíbe o seu acesso a utilizadores que só tenham os roles por defeito do sistema.

A Tabela 2 contém os resultados da nossa validação da fábrica B. Alguns dos relatórios não foram completamente validados, pois tinham muitas entradas ou a complexidade de algumas ações era demasiada alta para conseguir validar sem ter contexto da fábrica de software.

Ecrãs com Ecrãs % ecrãs Falhas Falsos % falhas
falhas validados validados reais positivos reais
Política 1 280 20 7% 18 2 90%
Política 2 1 1 100% 1 0 100%
Política 3 9 9 100% 9 0 100%
Política 4 14 7 50% 7 0 100%
Política 5 42 8 19% 8 0 100%
Tabela 2: Validação dos resultados da fábrica de software B

Dos 45 ecrãs com falhas reportadas que validámos, mais de 95% tinham falhas que necessitaram de ser corrigidas. Estes resultados são muito positivos e mostram que a nossa análise é capaz de encontrar falhas relevantes em fábricas de software.

A maioria das falhas encontradas foram casos triviais em que um ecrã não tinha as permissões corretas e as ações que chamava não tinham mecanismos de segurança. Estas falhas são fáceis de corrigir, assim que detetadas, mas tendo em conta a dimensão da fábrica B a sua deteção manual não é exequível. Assim sendo, a nossa análise é essencial para as equipas de desenvolvimento assegurarem a segurança nas suas fábricas de software.

Para exemplificar a gravidade de algumas das falhas encontradas, a falha que encontrámos usando a política 2 comprometia a segurança do sistema de biométrica da fábrica. Um dos ecrãs que permitia utilizadores criarem ou alterarem as impressões digitais no sistema não estava restrito ao conjunto certo de roles e não existia nenhum mecanismo de segurança nas suas ações. Isto permitia que um atacante inserisse a sua própria impressão digital no sistema, ou até que removesse ou alterasse a de outro utilizador, fazendo-se passar por ele. Validámos esta falha de segurança com os donos da fábrica, que confirmaram a sua gravidade e o desconhecimento da sua existência.

Os 2 falsos positivos detetados devem-se a limitações da nossa análise, referidas na Secção 2. Nestas entradas do relatório estão a ser usados outros mecanismos de segurança que ainda não são contemplados pela nossa análise.

A análise possui algumas limitações. Nomeadamente, outros mecanismos de segurança para além de check roles com condicionais podem ser usados, e a análise ainda não os deteta, resultando em falsos positivos. Outra limitação consiste em situações onde a condição dentro dum bloco condicional contém um check role em disjunção com outra expressão. Condições com disjunções não são triviais e é difícil inferir os roles do utilizador em cada ramo do bloco condicional. Nesta situação, a nossa análise segue uma abordagem conservadora, que pode resultar em falsos positivos. Apesar disto, falsos positivos são uma característica comum em análises estáticas, e a existência deles não tira valor às falhas encontradas com sucesso.

4.2 Performance e Escalabilidade

Para avaliar a performance da nossa análise, gerámos 20 relatórios utilizando várias políticas de segurança na fábrica B. Para avaliar a performance da nossa análise combinamos políticas definidas especificamente para a avaliação com políticas fornecidas pelos donos da fábrica.

Fábrica
Application
Objects
Tamanho
(Módulos)
Tamanho
(MB)
Gerar
grafo (s)
Nós
grafo
Arcos
grafo
Mock-up 28 2 2 <1 83 220
A 772 34 24 101 3581 10352
B 9476 691 517 278 48455 250122
Tabela 3: Resultados de carregar e gerar 3 diferentes fábricas de software
Fábrica Tamanho (Módulos) Tamanho (MB) Espaço em memória (MB)
Mock-up 2 2 90
A 34 25 150
B 691 517 1024
Tabela 4: Espaço em memória de 3 diferentes fábricas de software

O tempo de execução médio foi de cerca de 5 minutos, com os piores casos por volta dos 14 minutos. O objetivo desta técnica é gerar um relatório de segurança depois de executar a análise, o qual será posteriormente inspecionado. Como tal, tempos de execução mais longos não são problemáticos

Em termos de escalabilidade, medimos o tempo de carregar e gerar o modelo sintetizado das 3 fábricas, o tamanho resultante dos grafos, e o espaço ocupado em memória pelos modelos sintetizados de cada fábrica. As Tabelas 3 e 4 contém os resultados destas observações. Na segunda coluna da Tabela 3, o termo Application Objects é uma métrica usada em OutSystems, que conta o número de páginas e tabelas existentes numa fábrica666https://success.outsystems.com/Support/Enterprise_Customers/Licensing/Overview/Application_Object_count.

Os resultados da nossa análise foram representativos e atingiram os objetivos a que nos propusemos. Escalabilidade não foi um problema, mesmo ao analisar um fábrica com as dimensões da B. Em ambas as fábricas foram encontradas falhas graves, com um número reduzido de falsos positivos. Ainda que graves, a correção da maioria das falhas é trivial, sendo o maior desafio a sua deteção manual.

A análise possuí valor, pois vai ajudar as equipas de desenvolvimento a assegurarem a segurança nas suas fábricas de software, reduzindo o tempo despendido no processo de deteção manual de falhas de segurança. Estas equipas de desenvolvimento trabalham sobre plataformas low-code, onde podem faltar ferramentas para fazerem testes extensivos. Além disso, mesmo com bons testes é possível não apanhar todas as falhas, logo uma análise estática como a que apresentamos é útil. e Os clientes que forneceram as fábricas mostraram interesse na análise e esperam poder integrar a análise no processo de desenvolvimento de aplicações.

5 Trabalho Relacionado

O modelo de Role-Based Access Control (RBAC) [sandhu1998role] proposto por Sandhu simplifica a atribuição de permissões a utilizadores dum sistema. Em vez de se atribuírem permissões a utilizadores individuais, criam-se roles e atribuem-se roles aos utilizadores, e as permissões são dadas a roles em vez de utilizadores.

A nossa análise possuí algumas semelhanças a técnicas de taint analysis [Arzt:2014:FPC:2594291.2594299, newsome2005dynamic, Tripp:2013:AAS:2450312.2450333, Tripp:2009:TET:1543135.1542486], técnicas que detetam caminhos em que informação não confiável consiga chegar a locais sensíveis onde não devia chegar, sem serem desclassificados. É possível fazer uma analogia destes caminhos com aqueles que nossa análise deteta. A diferença é que taint analysis são detetados dados não confiáveis, enquanto a nossa análise deteta roles que acedem a indevidamente recursos protegidos.

Mais semelhantes à nossa análise são as técnicas de Model Checking [clarke2018model, clarke2003counterexample, biere2003bounded, burch1992symbolic, baier2008principles], que exploram todos os estados possíveis dum sistema de modo a verificar se ele cumpre com um dado conjunto de propriedades. A nossa análise verifica se existe algum estado que não cumpra a política de segurança definida. Da mesma forma que a nossa análise começa por usar um call graph para detetar possíveis falhas, a técnica CEGAR [clarke2003counterexample], também começa por utilizar um modelo mais abstrato do sistema, e só quando deteta erros no modelo abstrato é que o refina com mais informação para verificar o erro detetado.

6 Conclusões

Neste artigo apresentámos uma técnica análise de segurança estática que deteta falhas de segurança ao nível de roles em fábricas de software.

A técnica foi implementada para fábricas de software OutSystems e detetou com sucesso falhas de segurança em fábricas de software de clientes, algumas delas graves, que dificilmente seriam detetadas sem uma ferramenta de análise. Estas falhas já estavam presentes nas fábricas há bastante tempo e não tinham sido encontradas manualmente.

Como trabalho futuro, é particularmente importante endereçar outros mecanismos de segurança para além de check roles com condicionais e desta forma reduzir o números de falsos positivos. Planeamos melhorar e aperfeiçoar a ferramenta de modo a que possa ser integrada no ambiente de desenvolvimento OutSystems.

Acknowledgements:

This work was partially supported by NOVA LINCS (UID/CEC/ 04516/2013) and FCT project PTDC/CCI-INF/32081/2017.

Referências