A arquitectura da aplica¸c˜ao est´a dividida em trˆes partes, duas bibliotecas e um m´odulo que usa fun¸c˜oes de uma das bibliotecas para analisar ficheiros e gerar aler- tas. Estas bibliotecas s˜ao a biblioteca de an´alise lexical respons´avel por devolver tokens e a biblioteca de parsing que ´e respons´avel por devolver sequˆencias com vul- nerabilidades associadas. A aplica¸c˜ao criada no ˆambito deste projecto designa-se Athena e usa as bibliotecas aqui desenhadas onde est˜ao implementadas funcionali- dades de integra¸c˜ao e instala¸c˜ao em contexto de empresa.
Figura 3.1: Arquitectura do Athena
Esta aplica¸c˜ao ´e semelhante a um compilador at´e `a fase de an´alise semˆantica. Tem uma fase de an´alise l´exical, onde ´e feita a tradu¸c˜ao do ficheiro nos seus diversos tokens. Esta fase ´e realizada pela biblioteca de an´alise lexical e tem uma fase de parsing, onde ´e feita uma an´alise sint´actica ´a semelhan¸ca de um compilador. A grande diferen¸ca para o compilador ´e que enquanto neste o objectivo ´e analisar se a estrutura segue as regras da linguagem, no Athena o objectivo ´e verificar se a estrutura sint´actica corresponde a um vulnerabilidade ou n˜ao. Esta fase ´e feita pela biblioteca de parsing.
Cap´ıtulo 3. Aplica¸c˜ao Athena 35
3.2.1
Motor de an´alise lexical
O motor de an´alise lexical ´e respons´avel por traduzir os caracteres do ficheiro a analisar em tokens. Por essa raz˜ao apenas disponibiliza a capacidade de devolver o pr´oximo token do ficheiro, sob a forma de um m´etodo p´ublico ”PedirLexemme”. A arquitectura deste motor ´e a representada na figura 3.2.
O ”Lexemme” tal como no compilador refere-se a uma instˆancia espec´ıfica de um token. Como tal tem associado um token, uma linha e coluna e pode ter ou n˜ao um texto associado.
Quando um ficheiro ´e analisado, a primeira opera¸c˜ao ´e a extrac¸c˜ao dos seus tokens. Para fazer esta opera¸c˜ao foi desenhado um motor que cont´em uma lista de contextos. Estes contextos s˜ao necess´arios para ditar o comportamento do mo- tor em diferentes ambientes de execu¸c˜ao, isto porque os caracteres tˆem significados diferentes em contextos diferentes. A cada um destes contextos est˜ao associadas express˜oes. Estas express˜oes tˆem express˜oes regulares que ao serem emparelhadas com os caracteres do ficheiro v˜ao desencadear ac¸c˜oes. Estas ac¸c˜oes s˜ao aquelas que dizem ao motor a opera¸c˜ao que deve fazer. Dado que o prop´osito deste motor ´e a extrac¸c˜ao de tokens, uma das principais ac¸c˜oes ´e a de devolver um token. Esta ´e a ac¸c˜ao que permite extrair o primeiro token que existe no ficheiro. O token a ser devolvido depende do nome do token que ´e associado `a a¸c˜ao ”devolver token”. Para al´em desta ac¸c˜ao foi necess´ario desenvolver mais algumas ac¸c˜oes. Nomeadamente uma que permitisse indicar ao motor que deveria saltar de um contexto para outro, para que o motor fosse capaz de aplicar outras express˜oes regulares e devolver di- ferentes tokens em contextos diferentes. Nomeadamente, uma primeira que desse a capacidade de associar textos a um token, uma segunda que permitisse especificar que parte de um texto a ser reconhecido se pretende associar, outra que permitisse n˜ao realizar qualquer opera¸c˜ao para que o motor avan¸ca-se para o conjunto de ca- racteres a analisar, e finalmente uma ac¸c˜ao que permitisse sair do contexto actual e voltar ao principal.
Cap´ıtulo 3. Aplica¸c˜ao Athena 37
3.2.2
Motor de parsing
Este motor ´e respons´avel por devolver as sequˆencias que s˜ao vulner´aveis do ficheiro. Tal como o motor de an´alise l´exical disponibiliza apenas um m´etodo p´ublico. Este m´etodo devolve a informa¸c˜ao sobre a primeira vulnerabilidade que encontrou no ficheiro que est´a a ser analisado. Para isso utiliza sequˆencias de tokens indicadas como vulner´aveis para a linguagem a ser analisada. Estas sequˆencias de tokens s˜ao populadas pelos tokens que o motor de an´alise l´exical ´e capaz de devolver. A arquitectura deste motor est´a ilustrada na figura 3.3
Figura 3.3: Arquitectura do motor de parsing
A primeira tarefa do motor de parsing ´e criar uma lista de todos os tokens do ficheiro. Como tal, come¸ca por usar a fun¸c˜ao disponibilizada pela motor de an´alise l´exical para obter todos os tokens do ficheiro.
O passo seguinte ´e percorrer os tokens do ficheiro e tentar emparelhar as sequˆencias de tokens que existem. A estas sequˆencias de tokens est˜ao associadas ac¸c˜oes. Estas
ac¸c˜oes devem ser executadas quando a sequˆencia de tokens ´e emparelhada correc- tamente com os tokens do ficheiro. As sequˆencias a serem emparelhadas podem variar consoante o contexto, por exemplo numa fun¸c˜ao espec´ıfica pode existir uma vulnerabilidade que corresponde a uma sequˆencia espec´ıfica de tokens. Esta mesma vulnerabilidade pode n˜ao fazer sentido noutras fun¸c˜oes. Logo, o motor de parsing tem uma lista de contextos que tem sequˆencias de tokens associadas para aplicar aos diferentes contextos.
Existem, tal como no motor de an´alise l´exical, v´arios tipos de ac¸c˜oes que podem ser executadas quando o motor emparelha as sequˆencias de tokens correctamente. Foram criadas 5 nomeadamente :
• Uma ac¸c˜ao que permite devolver uma sequˆencia que tem uma vulnerabilidade associada. Esta recebe uma vulnerabilidade que fica associada `a sequˆencia que ´
e devolvida.
• Uma ac¸c˜ao que permite fazer o motor saltar de um contexto para outro. • Uma ac¸c˜ao que permite ao motor sair do contexto em que est´a, para o principal. • Uma ac¸c˜ao que permite ao motor ignorar a sequˆencia e avan¸car.
• Uma ac¸c˜ao que permite armazenar a informa¸c˜ao do contexto que est´a a ser analisado numa pilha
• Uma ac¸c˜ao que permite voltar ao contexto anterior.
Para minimizar o tempo que poderia demorar a percorrer a sequˆencia de tokens dos ficheiros foi associado a cada token um c´odigo. S˜ao estes c´odigos que o motor de parsing usa para representar o ficheiro, assim como as sequˆencias que vˆem do ficheiro de regras.
Tendo em conta o n´umero de tokens que est˜ao associados `a linguagem, ´e cal- culado o n´umero m´ınimo de caracteres diferentes de A-Z que s˜ao necess´arios para o representar. Ou seja, se foram declarados 26 tokens diferentes, ent˜ao cada token pode ser associado a uma letra diferente do abeced´ario. Se forem declarados mais do que 26 e menos que 676, ent˜ao s˜ao necess´arios dois caracteres.
Esta tradu¸c˜ao reduz bastante o tempo de an´alise, porque em vez do motor ter que percorrer o n´umero de caracteres que est´a associado a cada token, tem que percorrer apenas uma quantidade determinada de caracteres no ficheiro para descobrir um token. Na maior parte dos casos bastam dois caracteres dado que 676 combina¸c˜oes ´e mais do que suficiente para representar os tokens todos de uma qualquer linguagem. Na figura 3.4 mostra-se o exemplo do resultado da tradu¸c˜ao das express˜oes (ta- bela superior) e dos tokens nos seus respectivos c´odigos (tabela inferior). Na ´ultima coluna da tabela inferior indica-se o tamanho que a express˜ao codificada e n˜ao codi- ficada ocuparia no buffer. Os @ s˜ao apenas usados pelo motor para perceber quando come¸ca um novo token, logo n˜ao s˜ao relevantes para a contagem. Verifica-se que a diferen¸ca de tamanho ´e bastante significativa.
Cap´ıtulo 3. Aplica¸c˜ao Athena 39
Figura 3.4: Exemplo de convers˜ao de tokens
A redu¸c˜ao do tamanho do buffer do ficheiro com e sem os c´odigos dos tokens ´e ainda mais significativa para ficheiros grandes. Para um ficheiro da empresa Escrita Digital com 3906 linhas e 14541 instˆancias de tokens diferentes, o tamanho do buffer sem codifica¸c˜ao ´e de 209835 caracteres e com codifica¸c˜ao ´e de 29082 caracteres.
O motor vai de seguida percorrer o ficheiro de regras e tentar emparelhar os v´arios padr˜oes que est˜ao associados a cada contexto come¸cando, tal como no l´exico, pelo contexto principal. Antes de emparelhar os v´arios padr˜oes com a sequˆencia de c´odigos de tokens do ficheiro, ´e feita a convers˜ao dos tokens dos padr˜oes nos respectivos tokens. A fun¸c˜ao que ´e respons´avel por fazer esta opera¸c˜ao ´e a ”pedirSe- quencia()”. Esta fun¸c˜ao ´e a ´unica disponibilizada pelo motor de parsing. Tal como a fun¸c˜ao pedirLexemme, esta devolve a pr´oxima sequˆencia vulner´avel.
3.2.3
Athena
O Athena ´e uma aplica¸c˜ao de linha de comandos, respons´avel por usar o motor de
parsing e an´alise lexical para analisar ficheiros. Esta aplica¸c˜ao recebe os argumentos que definem o seu comportamento. Tem uma op¸c˜ao que permite limpar o que resulta dos ficheiros de an´alise. Permite tamb´em a sua instala¸c˜ao e a desinstala¸c˜ao.
Para que fosse poss´ıvel tornar a aplica¸c˜ao adapt´avel a qualquer linguagem, s˜ao utilizados ficheiros de configura¸c˜ao que ditam o comportamento do motor de an´alise l´exical e parsing para as v´arias linguagems. Na sec¸c˜ao 3.3 ´e detalhada a estrutura dos ficheiros de configura¸c˜ao e o efeito dos v´arios atributos nos motores.