Ricardo Silveira Moreira

(1)

UNIVERSIDADE DE LISBOA FACULDADE DE CIˆENCIAS DEPARTAMENTO DE INFORM ´ATICA

Aplica¸

c˜

ao para dete¸

c˜

ao de c´

odigo vulner´

avel

atrav´

es de an´

alise est´

atica

Ricardo Silveira Moreira

Mestrado em Seguran¸

ca Inform´

atica

Trabalho de projeto orientado por:

Prof. Doutor Naercio David Pedro Magaia

(2)

(3)

Agradecimentos

O trabalho apresentado nesta tese foi desenvolvido na empresa Escrita Digital. A sua concretiza¸cão não teria sido poss´ıvel sem o apoio incondicional do seu diretor Tomé Gil que acreditou no meu projecto e autorizou a utiliza¸cão de recursos desta empresa.

Expresso também a minha gratidão ao director de desenvolvimento António Or-lando, meu orientador na empresa. A sua constante disponibilidade para esclarecer todas as minhas dúvidas e as valiosas sugestões nos temas relevantes para esta tese foram determinantes ao longo do desenvolvimento desta aplica¸cão.

Ao meu orientador no Departamento de Informática da FCUL, professor Naércio Magaia, agrade¸co a sua orienta¸cão na estrutura¸cão deste trabalho, no apontar de vias de desenvolvimento e na escrita da tese que melhoraram muito este manuscrito. Agrade¸co ainda o incentivo para a publica¸cão dos resultados aqui apresentados.

Quero expressar também um agradecimento aos meus amigos e colegas de mes-trado e trabalho Guilherme Antunes e Inês Afonso, que tornaram a realiza¸cão da tese mais fácil nas alturas mais dif´ıceis.

Um grande obrigado `a minha fam´ılia por me terem ajudado e apoiado incondi-cionalmente durante todo o meu percurso escolar.

Finalmente, um obrigado especial `a minha namorada Margarida Monteiro por me ter dado for¸ca quando precisava e por estar sempre ao meu lado.

(4)

(5)

Resumo

Em empresas de desenvolvimento de software é cada vez mais necessário incluir valida¸cões de seguran¸ca no fluxo de desenvolvimento. A falta destas pode ter con-sequências danosas a n´ıvel de custos, isto porque a seguran¸ca é um requisito que é cada vez mais importante para clientes. Com este projecto propõe-se a cria¸cão de uma aplica¸cão de análise de código estático e a sua integra¸cão no ciclo de desenvol-vimento na empresa Escrita Digital (ED). Apesar de existirem diversas solu¸cões no mercado para a deteçcão de vulnerabilidades, nenhuma das existentes actualmente é adequada para os problemas que existem na ED. Em primeiro lugar devido aos eleva-dos custos envolvieleva-dos numa solu¸cão deste tipo. Em segundo lugar por não existirem no mercado muitas aplica¸cões capazes de analisar a linguagem ASP, linguagem que é usada para desenvolver alguns dos produtos que a ED comercializa. Para isso, criou-se a aplica¸cão Athena com a capacidade de analisar qualquer linguagem, desde que escritas as regras e léxico para a mesma. O Athena requer a indica¸cão dos padrões de código potencialmente vulneráveis pelo programador, colocando assim sobre ele a responsabilidade de identificar essas vulnerabilidades.

As regras e o léxico são descritas recorrendo a ficheiros de configura¸cão de Ex-tensible Markup Language (XML), que vão alimentar o motor, ditando as opera¸cões que este deve fazer. No léxico estão descritos os vários tokens que compõem a lin-guagem a ser analisada. Este ficheiro é utililizado pelo motor de análise léxical para extrair os tokens do ficheiro. Nas regras estão as descri¸cões dos vários padrões que correspondem a vulnerabilidades e a fun¸cões seguras. Padrões esses que são cons-truidos a partir dos tokens declarados no ficheiro de léxico. Este ficheiro de regras vai alimentar o motor de parsing sendo este responsável por devolver sequências de tokens que têm uma vulnerabilidade e uma localiza¸cão no ficheiro associada. O Athena usa estas duas bibliotecas para analisar ficheiros e devolver as várias vulnera-bilidades. Realizaram-se diversos testes tendo como objectivo evidenciar a vantagem da utiliza¸cão da aplica¸cão Athena, quantificar a eficácia da solu¸cão na deteçcão de vulnerabilidades e comparar os tempos envolvidos nessa mesma deteçcão. Os testes revelaram que a aplica¸cão Athena apresenta claras vantagens face a uma análise manual ou mesmo recorrendo ao YASCA.

Palavras-chave: an´alise est´atica, an´alise lexical, vulnerabilidades, compiladores

(6)

(7)

Abstract

In software development companies, it is increasingly necessary to include secu-rity validations in the development flow. The lack of these can have very harmful consequences in terms of costs because security is a requirement that is increasingly important for customers. Thus, security is a fundamental aspect to take into ac-count when developing software. However, older companies find it more difficult to change and insert these validations and considerations into their software develop-ment process, as they will always cause a delay in the delivery of new versions. This project aims the creation of a static code analysis application and its integration in the development cycle at Escrita Digital (ED). Although there are several solu-tions on the market for the detection of vulnerabilities, none of the existing ones is currently adequate for the problems that exist in ED. Firstly, due to the high costs involved in such a solution and secondly, because there are not many applications on the market capable of analyzing ASP, a language that is used to develop some of the products that ED commercializes. To solve this problem, the Athena application was developed with the ability to analyze any language, as long as the rules and lexicon for it are written. Athena requires the programmer to indicate potentially vulnerable code patterns, thus placing on him the responsibility to identify those vulnerabilities.

The rules and the lexicon are described using XML configuration files, which will feed the engine, dictating the operations it must do. The lexicon describes the various tokens that make up the language to be analyzed. This file is used by the lexical analysis engine to extract the tokens from the file. In the rules are descriptions of the various standards that correspond to vulnerabilities and secure functions. These patterns are built from the tokens declared in the lexicon file. This rules file will feed the parsing engine, which is responsible for returning code sequences that have a vulnerability and a location in the associated file. Athena uses these two libraries to analyze files and to return the various vulnerabilities that are found by the parsing engine.

In the final part of the thesis, several tests were carried out with the objective of highlighting the advantage of using the Athena application, quantifying the solu-tion’s effectiveness in detecting vulnerabilities and also comparing the times involved in that detection. The comparison was made with manual analysis and with YASCA [15], a free use application. The tests revealed that the Athena application has clear advantages over a manual analysis or even using YASCA.

(8)

(9)

(10)

(11)

Conte´

udo

Lista de Figuras xiii

Lista de Tabelas xv 1 Introdu¸cão 1 1.1 Motiva¸cão . . . 1 1.2 Objectivos do trabalho . . . 2 1.3 Estrutura do documento . . . 2 1.4 Institui¸cão de acolhimento . . . 3 1.5 Contribui¸cões . . . 3

2 Contexto e trabalho relacionado 5 2.1 Vulnerabilidades em aplica¸c˜oes web . . . 6

2.1.1 Injection . . . 6

2.1.2 Cross-Site Scripting . . . 8

2.1.3 Utiliza¸c˜ao de Componentes com Vulnerabilidades Conhecidas . 9 2.1.4 Broken Authentication . . . 9

2.1.5 Sensitive Data Exposure . . . 10

2.1.6 XML Eternal Entities . . . 10

2.1.7 Broken Access Control . . . 10

2.1.8 Security Misconfiguration . . . 10

2.1.9 Insecure Desserialization . . . 10

2.1.10 Insufficient Logging & Monitoring . . . 10

2.1.11 Injection . . . 11

2.1.12 Cross-Site Scripting . . . 13

2.1.13 Utiliza¸cão de Componentes com Vulnerabilidades Conhecidas . 14 2.2 Métodos de Análise . . . 14

2.2.1 An´alise Dinˆamica . . . 14

2.2.2 An´alise Est´atica . . . 15

2.2.3 An´alise Manual . . . 15

2.2.4 Discuss˜ao . . . 16

2.3 Ferramentas análise estática de código . . . 17

2.3.1 An´alise lexical . . . 18

2.3.2 Parsing . . . 23 ix

(12)

2.4 Redes neuronais . . . 28

2.4.1 Motiva¸c˜ao . . . 28

2.4.2 Vantagens e desvantagens . . . 29

2.5 Ferramentas . . . 29

2.5.1 An´alise lexical . . . 29

2.5.2 Parsing . . . 30

2.5.3 An´alise est´atica . . . 30

2.5.4 Compara¸c˜ao . . . 31

3 Aplica¸c˜ao Athena 33 3.1 Tecnologias utilizadas . . . 33

3.2 Arquitectura . . . 34

3.2.1 Motor de an´alise lexical . . . 35

3.2.2 Motor de parsing . . . 37

3.2.3 Athena . . . 39

3.3 Ficheiros de configura¸c˜ao . . . 39

3.3.1 Schema dos ficheiros de configura¸c˜oes . . . 40

3.3.2 L´exico . . . 41

3.3.3 Regras . . . 45

3.4 Funcionamento . . . 48

3.4.1 Motor de an´alise lexical . . . 48

3.4.2 Motor de parsing . . . 50

3.5 Decis˜oes Tomadas . . . 52

3.6 Integra¸c˜ao na empresa . . . 52

3.7 Problemas encontrados . . . 52

4 Avalia¸c˜ao 55 4.1 Metodologia de avalia¸c˜ao . . . 55

4.1.1 Ferramentas usadas para fazer testes . . . 56

4.1.2 Padr˜oes de vulnerabilidades . . . 56

4.1.3 Ficheiros de regras xml para testes . . . 59

4.1.4 M´etricas de testes . . . 59

4.2 Procedimento de An´alise . . . 60

4.2.1 A aplica¸c˜ao Athena versus a an´alise manual . . . 60

4.2.2 Identifica¸c˜ao de vulnerabilidades . . . 61

4.2.3 Tempo de análise e correçcão . . . 61

4.3 Resultados de Testes . . . 61

4.4 Discuss˜ao dos resultados . . . 65 x

(13)

5 Conclus˜oes e trabalho futuro 67

5.1 Conclus˜oes . . . 67

5.2 Trabalho futuro . . . 67

5.2.1 Integra¸c˜ao no visual studio . . . 68

5.2.2 Melhorias no motor . . . 68

Gloss´ario 71

Siglas 73

Bibliografia 77

(14)

(15)

Lista de Figuras

2.1 Representa¸c˜ao de alto n´ıvel de um compilador . . . 17

2.2 Representa¸cão de alto n´ıvel de uma ferramenta de análise estática de código . . . 18

2.3 Diagrama de estados para reconhecimento de um identificador . . . . 20

2.4 M´aquina de estados que reconhece a express˜ao abc(a|b|c)*a . . . 22

2.5 Máquina de estados simplificada que reconhece a expressão abc(a|b|c)*a 22 2.6 Máquina de estados que reconhece a expressão abc(a|b|c)*a . . . 23

2.7 Rela¸c˜ao entre a an´alise lexical e o parser . . . 24

2.8 Arvore de parsing da express˜ao (1 + 4) ∗ 5 + 3 . . . 27

3.1 Arquitectura do Athena . . . 34

3.2 Motor de an´alise l´exical . . . 36

3.3 Arquitectura do motor de parsing . . . 37

3.4 Exemplo de convers˜ao de tokens . . . 39

3.5 Exemplo de funcionamento do motor de an´alise l´exical . . . 49

3.6 Exemplo de funcionamento de motorParsing . . . 51

3.7 Menu de contexto . . . 52

4.1 Histograma do n´umero de vulnerabilidades encontradas pelo Athena e pelo Yasca (tabela 4.3) . . . 63

4.2 Resultado da análise no número de vulnerabilidades em fun¸cão do tempo . . . 64

(16)

(17)

Lista de Tabelas

2.1 Tabela de s´ımbolos . . . 19 2.2 Regras de produ¸cão para opera¸cões aritméticas . . . 24 2.3 Tradu¸cão de regras de produ¸cão para regras de semantica . . . 26 2.4 Ferramentas existentes no mercado para análise de código ASP . . . . 31 4.1 Significado dos resultados no contexto de vulnerabilidades . . . 59 4.2 Número de vulnerabilidades encontradas pelo Athena face às manuais. 62 4.3 Número de vulnerabilidades encontradas pelo Athena e pelo YASCA. 63 4.4 Métricas calculadas para as aplica¸cões Athena e YASCA . . . 63 4.5 Tempos de análise mais corre¸cão das vulnerabilidades acusadas. . . . 64

(18)

(19)

Cap´ıtulo 1

Introdu¸

c˜

ao

1.1 Motiva¸

c˜

ao

Temos assistido nos últimos anos a um aumento na preocupa¸cão, investimento de dinheiro e recursos humanos na seguran¸ca informática de aplica¸cões web, isto de-vido ao crescimento no número de ataques informáticos a empresas, motivado pela grande quantidade de informa¸cão a que estas aplica¸cões web muitas vezes tem acesso. Apesar desta crescente preocupa¸cão e da evolu¸cão de linguagens de programa¸cão as-sim como frameworks para o desenvolvimento de aplica¸cões web, vulnerabilidades derivadas de má programa¸cão continuam a existir.

Estas vulnerabilidades estão bem documentadas e são bem conhecidas no mundo informático. A organiza¸cão Open Web Application Security Project (OWASP) [28] documenta vulnerabilidades de aplica¸cões web, desenha solu¸cões de suporte à de-teçcão e técnicas para as resolver. Ela publica ainda relatórios onde reúne vulne-rabilidades cr´ıticas. Nestes relatórios estão documentadas as dez vulnerabilidades mais cr´ıticas presentes em aplica¸cões web. No relatório de 2017 [29], vulnerabilida-des como Structured Query Language (SQL) injection e Cross-site scripting (XSS) continuavam a fazer partes das 10 maiores vulnerabilidades, podendo contudo ser de-tectadas facilmente na fase de desenvolvimento do código. São muitas vezes também aquelas que surgem derivadas do fluxo de desenvolvimento normal duma empresa e que, tal como o relatório indica, podem ter impactos muito danosos para a mesma empresa.

Em empresas de desenvolvimento de software, o conhecimento e a forma¸cão passada entre programadores levam ao aparecimento de um padrão de produ¸cão de código. Isto aliado a um certo desleixe quanto a questões de seguran¸ca, derivado muitas vezes de alguma pressa em colocar funcionalidades em produ¸cão por falta de tempo, leva a que muitas vulnerabilidades se repitam. A desvantagem disto é a grande prolifera¸cão de vulnerabilidades que derivam do mesmo padrão. Isto pode ser contudo uma vantagem, se o padrão for identificado numa fase embrionária, sendo poss´ıvel alertar o programador para corrigir esta vulnerabilidade.

Por exemplo, a Escrita Digital, cujo foco é o desenvolvimento destes produtos de software na forma de aplica¸cões web, é v´ıtima disto. Nesta existe um vazio no

(20)

que diz respeito a cuidados de seguran¸ca, tanto no decorrer do desenvolvimento de funcionalidades como na fase de testes. Tipicamente as aplica¸cões nesta empresa são desenvolvidas em C#.NET e Activer Server Pages (ASP) (clássico). O C#.NET é uma linguagem compilada à semelhan¸ca do JAVA, e o ASP (clássico) uma linguagem interpretada à semelhan¸ca do PHP. Ambas as linguagens, tal como qualquer outra, são propensas ao surgimento de vulnerabilidades, contudo de maneiras diferentes.

1.2 Objectivos do trabalho

Nesta tese é apresentado o processo de desenvolvimento de uma solu¸cão de análise de código estático para a deteçcão de código C#.NET e ASP (clássico) vulnerável e com possibilidade de ser estendido para outras linguagens. A necessidade do desenho de uma nova solu¸cão prende-se, essencialmente com dois factores: i) o facto de as solu¸cões já existentes não serem adequadas para a empresa, e terem custos muito elevados; ii) Algum facilitismo com vulnerabilidades existentes nas aplica¸cões da empresa Escrita Digital.

A aplica¸cão proposta é a de análise de código estático e vai ser introduzida numa nova fase para valida¸cão de seguran¸ca. Esta aplica¸cão não descura a análise manual mas complementa-a. O seu propósito é fornecer um aux´ılio ao programador e alertar contra código potencialmente vulnerável.

1.3 Estrutura do documento

A estrutura ´e a seguinte:

• No Cap´ıtulo 2 são abordados os conceitos teóricos necessários para a realiza¸cão da aplica¸cão de deteçcão de vulnerabilidades assim como o contexto do traba-lho. São apresentadas e discutidas as várias categorias de aplica¸cões de análise de seguran¸ca. São explicadas as várias fases de análise de uma ferramenta de código estática, assim como os métodos que esta usa para fazer a deteçcão de vulnerabilidades. Finalmente são apresentadas ferramentas já existentes para análise e são definidas métricas para análise da aplica¸cão aqui apresentada. • No Cap´ıtulo 3 é apresentada a arquitectura do motor de análise léxical e

motor de parsing, os ficheiros de configura¸cão, a forma como os ficheiros de configura¸cão influenciam o comportamento dos motores, decisões que foram tomadas, o processo de integra¸cão na empresa e finalmente os problemas en-contrados durante o desenvolvimento da aplica¸cão. Dado que os ficheiros de configura¸cão são a parte mais relevante do trabalho, optou-se por explicar primeiro o que compõe os ficheiros de configura¸cão. A motiva¸cão para a sua organiza¸cão e o efeito que tem nos motores. É apresentado a arquitectura dos dois motores. Finalmente é apresentado o processo de integra¸cão na empresa e os vários problemas encontrados

(21)

Cap´ıtulo 1. Introdu¸c˜ao 3

• No Cap´ıtulo 4 é apresentado a metodologia de testes e o resultados destes. Os testes apresentados tinham como objectivo mostrar a validade da aplica¸cão desenvolvida, a mais valia de usar a ferramenta face a uma análise manual e finalmente é feita uma compara¸cão dos tempos com o YASCA, uma análise manual e a aplica¸cão com diferentes ficheiros de configura¸cão.

• No Cap´ıtulo 5 são feitas as conclusões finais sobre o trabalho desenvolvido e são feitas propostas de trabalho futuro.

1.4 Institui¸

c˜

ao de acolhimento

Este projecto foi desenvolvido ao abrigo da empresa Escrita Digital. Esta empresa foi fundada em Outubro de 2001 e tem como objectivo desenvolver produtos de software que facilitem o trabalho e gestão de empresas. Os seus produtos são desenvolvidos na forma de aplica¸cões web.

1.5 Contribui¸

c˜

oes

(22)

(23)

Cap´ıtulo 2

Contexto e trabalho relacionado

A primeira versão da web, a web 1.0, surgiu na década de 90. Esta consistia ape-nas em websites estáticos, porque estes funcionavam apenas como repositórios de informa¸cão. Nestes websites não existia qualquer tipo de interaçcão e as páginas serviam apenas para ir buscar informa¸cão a um servidor. As vulnerabilidades de websites estáticos existem apenas do lado do servidor, porque a informa¸cão era a mesma para cada cliente e este não tinha forma de interagir com ele. Actualmente, o mesmo não acontece e grande parte dos websites são na realidade aquilo a que se chamam de aplica¸cões web.

Estas aplica¸c˜oes web funcionam num paradigma em que existe um cliente, tipi-camente um brower e um servidor que fornece algum tipo de servi¸co. O servidor providencia este servi¸co sob a forma de uma aplica¸c˜ao web, que escreve c´odigo

Hy-perText Markup Language (HTML) que depois vai ser interpretado pelo browser.

Estas aplica¸cões são desenvolvidas com recurso a linguagens web (i.e., PHP, ASP) ou através de alguma web framework (i.e., .NET, JSF, Spring MVC).

O funcionamento de grande parte destas aplica¸cões web é feito através da sub-missão de formulários para um servidor. Estes formulários são páginas web que tipicamente têm campos de entrada que o cliente consegue popular com valores. Os valores dos campos de entrada vão ser depois submetidos para o servidor através de pedidos HTTP. O servidor vai receber estes valores e vai utiliz´a-los em servi¸cos que irão devolver respostas.

O problema de seguran¸ca surge quando não é feita a correcta sanitiza¸cão destes valores quando estão a ser submetidos para o servi¸co; ou então quando não é feita a sua codifica¸cão quando estão a ser devolvidos na resposta. A incorrecta, ou falta de sanitiza¸cão ou codifica¸cão pode permitir a um cliente malicioso a altera¸cão do comporamente normal da aplica¸cão, permitindo que esta tenha comportamentos diferentes daquele para a qual foi desenhada.

Outro tipo de vulnerabilidades recorrentes advém da implementa¸cão incorrecta de mecanismos de autentica¸cão, ou da inclusão de componentes que contêm eles próprios vulnerabilidades.

As vulnerabilidades acima descritas, que aparecem no relat´orio referenciado ante-riormente [28] s˜ao: SQL Injection, Broken Authentication, Sensitive Data Exposure,

(24)

XXE injection, Broken Access Control, Security Miscofiguration, Cross-site scripting (XSS), Insecure Deserialization, utiliza¸c˜ao de componentes com vulnerabilidades co-nhecidas e falta de monitoriza¸c˜ao e registo de logs.

Na próxima seçcão são descritas, com maior detalhe, algumas vulnerabilidades, nomeadamente XSS, SQL injection e utiliza¸cão de componentes com vulnerabilida-des conhecidas, consideradas mais relevantes no contexto vulnerabilida-deste projecto.

Devido ao processo natural de desenvolvimento de uma aplica¸cão e de funciona-lidades, as vulnerabilidades surgem naturalmente, existindo portanto a necessidade de validar as páginas, utilizando métodos de análise de seguran¸ca.

Podemos distinguir três tipos de análise: análise dinâmica, análise estática e análise manual. Na análise dinâmica são efectuados os testes contra a aplica¸cão enquanto esta está a correr. Na análise de código estático é poss´ıvel identificar situa¸cões que potencialmente vão dar origem a vulnerabilidades. Todas as aplica¸cões de análise de código estática recorrem a técnicas de compiladores para analisar código e muitas vezes usam mais do que uma técnica para o fazer: análise de fluxo de dados, análise de controlo de fluxo, an´alise lexical, taint analysis e pattern matching. Por ´

ultimo, a análise manual, em que é feita a análise ao código sem recorrer a qualquer tipo de ferramenta.

2.1 Vulnerabilidades em aplica¸

c˜

oes web

As vulnerabilidades aqui apresentadas em primeiro lugar e em maior detalhe são aquelas em que a aplica¸cão desenvolvida é capaz de ajudar a detectar e prevenir. As outras, apesar de fugirem ao âmbito deste projecto, são apresentadas de forma resumida. É explicada a sua origem, assim como a razão pela qual não podem ser detectadas com este tipo de aplica¸cões.

2.1.1 Injection

Vulnerabilidades de Injection existem quando ´e poss´ıvel um utilizador malicioso enviar conteúdo malicioso para um interpretador. A superf´ıcie de ataque desta vulnerabilidade pode incluir variáveis de ambiente, parâmetros, servi¸cos externos e internos e tipos de utilizadores. Podemos distinguir vários tipos de vulnerabilidades dentro desta, SQL, Lightweight Directory Access Protocol (LDAP), Non relational

SQL (NoSQL), Operating System (OS) Injection. Na pr´oxima seçcão será fornecido mais informa¸cão sobre este tipo de vulnerabilidade.

SQL Injection

Em aplica¸cões web são utilizadas bases de dados para guardar informa¸cão. O tipo de informa¸cão que é guardada varia de acordo com o tipo de aplica¸cão e com as funcio-nalidades que oferece. Estas bases de dados são manipuladas através de linguagens descritivas tal como o SQL.

(25)

Cap´ıtulo 2. Contexto e trabalho relacionado 7

O SQL permite fazer pedidos as tabelas para alterar e listar informa¸c˜ao. O exemplo mais simples disto ´e

-- Query para listar todas as colunas e todas as linhas da tabela utilizadores

select * from utilizadores

Na query acima ´e feito um pedido para listar todas as linhas na tabela utiliza-dores.

SQL injection é uma vulnerabilidade que já existe há muitos anos e continua a fazer parte das mais perigosas em aplica¸cões web. É um tipo de vulnerabilidade que explora inputs que constroem querys baseadas no seu conteúdo ou usam o input como parâmetro de um procedimento. Nesta vulnerabilidade um utilizador malicioso injecta código SQL no input que ao ser utilizado vai levar a que a uma funcionalidade efectue opera¸cões para as quais não foi pensada. Esta vulnerabilidade pode ser prevenida através de sanitiza¸cão do conteúdo que é usado para construir a query ou procedimento. A sanitiza¸cão pode ser feita de várias formas, uma delas é a subsitui¸c˜ao de caracteres que terminem strings em SQL por caracteres que transformem a express˜ao inteira a ser passada numa string. O car´acter depende da linguagem de SQL. Este problema n˜ao se prende apenas com inputs. Se um URL de uma página tiver parâmetros que são usados directamente num procedimento ou para construir uma query, sem que seja feita a correcta sanitiza¸cão o problema vai ser o mesmo.

<%

nome = request.queryString["nome"]

objdb.query("select * from utilizadores where nome=" & nome) %>

No exemplo acima temos um caso de código vulnerável em que um parâmetro da query string é passado directamente para uma query. O parˆametro é o nome do utilizador e vai listar todas as linhas que tenham um nome igual ao do valor passado. Esta opera¸cão é feita sem que ocorra qualquer tipo de sanitiza¸cão. Neste caso, um utilizador malicioso pode usar o parâmetro nome para modificar o conte´udo da query [43].

Por exemplo, o utilizador malicioso poderia terminar a query e colocar uma tau-tologia, isto é uma condi¸cão que é sempre correcta, por exemplo, 1 = 1, para isso bastaria colocar um parˆametro que fosse ” or0₁0 ₌ 0₁0 _{o resultado disso seria:}

select * from utilizadores where nome="" or ’1’=’1’

(26)

indiscri-minadamente. A sanitiza¸cão neste caso deveria ser feita através da subsitui¸cão das plicas por duas plicas, de modo a tornar toda a expressão que é passada para a

query numa string.

NoSQL Injection

NoSQL é um tipo de base de dados não relacional, onde não existe o conceito de tabelas como nas bases de dados clássicas. Numa base de dados não relacional os valores são guardados em registos, que podem ser organizados de várias formas,como grafos, pares chaves-valor, documento, entre outros. Este tipo de bases de dados oferece algumas vantagens em rela¸cão às bases de dados tradicionais, nomeadamente na escalabilidade e desempenho.

O tipo de ataques que são feitos a este tipo de base de dados podem inclusive-mente ser mais danosos do que numa base de dados tradicional, porque os ataques ocorrem numa linguagem que não é declarativa.

Isto faz com que seja poss´ıvel potencialmente executar ataques na camada apli-cacional, enquanto que no SQL Injection os ataques est˜ao limitados `a camada da base de dados.

LDAP Injection

O LDAP é um protocolo de aplica¸cão que permite manter e aceder a directórios de servi¸cos de informa¸cão distribu´ıdos. Essencialmente, é uma forma de organizar informa¸cão de utilizadores, grupos ou outro tipos de entidades. Esta organiza¸cão é feita através de hierarquias e permite definir atributos que caracterizam instâncias de cada um dos tipos de entidades.

O tipo de ataques que é feito aqui consiste, à semelhan¸ca com outro tipo de ataques da mesma classe, na introdu¸cão de conteúdos que vão modificar as querys LDAP. Neste caso vai permitir potencialmente a altera¸cão de comandos que levem `

a altera¸cão de permissões e do conteúdo que está na árvore LDAP.

2.1.2 Cross-Site Scripting

Ocorre quando é poss´ıvel a um utilizador enviar scripts maliciosos para outro uti-lizador, utilizando os campos de entrada da aplica¸cão. As consequência podem ser várias, por exemplo o acesso a cookies de sessão que podem permitir ao atacante roubar a sessão de outro utilizador. Pode também servir como método para levar o utilizador a fazer o download de ficheiros potencialmente maliciosos. Isto deve-se à ausência de uma correcta sanitiza¸cão ou codifica¸cão destes inputs ou parâmetros de um url.

Podemos distinguir dois tipos de XSS: client XSS e server XSS

O client XSS ocorre quando s˜ao usados dados de campos de entrada do lado do cliente para a actualiza¸cão de conteúdo do Document Object Model (DOM) sem que seja feita codifica¸cão. Este conteúdo pode estar a ser usado directamente na

(27)

página, através de JavaScript, para a constru¸cão de elementos no DOM, podendo levar à execu¸cão de código potencialmente vulnerável.

document.write("<div>document.getElementById("#nome").val()</div>"); </script>

O caso acima constitui um exemplo . Nele temos um script que est´a a desenhar um

div directamente no DOM,e se houver conteúdo malicioso no input nome ent˜ao será colocado no div através da chamada de javascript que é feita.

O server XSS ocorre quando s˜ao usados dados que vêm do servidor directamente na página, porque o servidor não está a fazer nenhuma sanitiza¸cão ou codifica¸cão.

O exemplo acima ´e um dos casos mais simples de server XSS, onde temos o valor que vem da base de dados que ´e colocado directamente no DOM. No caso de um utilizador malicioso alterar o seu nome para, por exemplo, < script >

alert(”Conteudomuitomau”); < /script >, faria com que o conteudo a ser

exe-cutado fosse o que abaixo se mostra.

<div ID="nome"><script>alert("Conteudo muito mau");</script></div>

2.1.3 Utiliza¸

c˜

ao de Componentes com Vulnerabilidades

Co-nhecidas

Estas vulnerabilidades surgem quando são inclu´ıdos componentes que têm, eles próprios, vulnerabilidades. Estas são muitas vezes algumas das acima. O problema surge quando são adicionados componentes sem que seja feita a análise devida so-bre as vulnerabilidades que estes podem conter. Estas são mais predominante em empresas cujo desenvolvimento de software seja maioritariamente dependente de bi-bliotecas externas, sem que estas sejam actualizadas ou verificadas da forma correcta antes de serem utilizadas.

2.1.4 Broken Authentication

Broken authentication [30] ´e uma vulnerabilidade que resulta de mecanismos de autentica¸cão que não estão implementados da forma correcta, ou seja, apesar de poderem estar correctamente programados, usam técnicas de design fracas, tais como a aplica¸cão de protocolos de hash que já foram quebrados, regras de cria¸cão de passwords pouco exigentes, entre outros.

(28)

2.1.5 Sensitive Data Exposure

Sensitive Data Exposure [31] ´e uma vulnerabilidade que resulta da falta de utiliza¸cão de protocolos de cifra em dados sens´ıveis de utilizadores, da utiliza¸cão de protocolos de cifra e/ou de hash, de mecanismos de gestão e gera¸cão e/ou de chaves que são fracos e portanto facilmente quebráveis. Mais uma vez esta não pode ser validada através do código fonte.

2.1.6 XML Eternal Entities

XXE injection[32] tˆem origem na utiliza¸cão de processadores antigos de XML. Este tipo de vulnerabilidades devem-se à possibilidade de injeçcão de ficheiros de XML de fontes externas ou da inclusão de conteúdo malicioso em documentos XML, permi-tindo explorar código vulnerável, dependências ou integra¸cões. Esta vulnerabilidade, dada a sua natureza, também não pode ser detectada com uma ferramenta de análise de código estática.

2.1.7 Broken Access Control

O Broken Access Control [33] ´e uma vulnerabilidade que advém do incumprimento da regra de negar o acesso por defeito, que deriva do design incorrecto de princ´ıpios de separa¸cão de privilégios em aplica¸cões web. Esta vulnerabilidade só pode ser validada através de testes de funcionalidade. Apesar de poder ser detectada por alguns tipos de ferramentas de análise estática que fa¸cam análise de fluxo não pode ser detectada pela ferramenta aqui apresentada.

2.1.8 Security Misconfiguration

Security Misconfiguration [34] tal como o nome indica, surge da configura¸c˜ao in-correcta de servi¸cos, podendo consistir, por exemplo, em contas configuradas pelo fabricante de um servi¸co, que nunca são alteradas. Esta também não pode ser detectada através de uma ferramenta de análise de código estática.

2.1.9 Insecure Desserialization

Insecure Desserialization [35] surge quando uma aplica¸c˜ao aceita objectos serializa-dos de fontes desconhecidas ou permite tipos de daserializa-dos não primitivos. São vulnera-bilidades dif´ıceis de encontrar e validar e a sua deteçcão implica ferramentas capazes de detectar falhas ao desserializar. Mais uma vez, também não pode ser detectada por uma ferramenta de análise de código estático.

2.1.10 Insufficient Logging & Monitoring

Insufficient Logging & Monitoring [36] tal como o nome indica, refere-se a falta de

(29)

web. Isto porque a monitoriza¸cão e registo de logs pode ajudar a minimizar um ataque em curso, ou evitar o mesmo. Esta vulnerabilidade não pode ser detec-tada através de uma aplica¸cão de análise de código estática, mas sim por meio de auditorias de seguran¸ca.

2.1.11 Injection

Vulnerabilidades de Injection existem quando ´e poss´ıvel um utilizador malicioso enviar conteúdo malicioso para um interpretador. A superf´ıcie de ataque desta vulnerabilidade pode incluir variáveis de ambiente, parâmetros, servi¸cos externos e internos e tipos de utilizadores. Podemos distinguir vários tipos de vulnerabilidades dentro desta, SQL, Lightweight Directory Access Protocol (LDAP), Non relational

SQL (NoSQL), Operating System (OS) Injection. Na pr´oxima seçcão será fornecido mais informa¸cão sobre este tipo de vulnerabilidade.

SQL Injection

Em aplica¸cões web são utilizadas bases de dados para guardar informa¸cão. O tipo de informa¸cão que é guardada varia de acordo com o tipo de aplica¸cão e com as funcio-nalidades que oferece. Estas bases de dados são manipuladas através de linguagens descritivas tal como o SQL.

O SQL permite fazer pedidos as tabelas para alterar e listar informa¸c˜ao. O exemplo mais simples disto ´e

-- Query para listar todas as colunas e todas as linhas da tabela utilizadores

select * from utilizadores

Na query acima ´e feito um pedido para listar todas as linhas na tabela utiliza-dores.

SQL injection é uma vulnerabilidade que já existe há muitos anos e continua a fazer parte das mais perigosas em aplica¸cões web. É um tipo de vulnerabilidade que explora inputs que constroem querys baseadas no seu conteúdo ou usam o input como parâmetro de um procedimento. Nesta vulnerabilidade um utilizador malicioso injecta código SQL no input que ao ser utilizado vai levar a que a uma funcionalidade efectue opera¸cões para as quais não foi pensada. Esta vulnerabilidade pode ser prevenida através de sanitiza¸cão do conteúdo que é usado para construir a query ou procedimento. A sanitiza¸cão pode ser feita de várias formas, uma delas é a subsitui¸c˜ao de caracteres que terminem strings em SQL por caracteres que transformem a express˜ao inteira a ser passada numa string. O caractere depende da linguagem de SQL. Este problema n˜ao se prende apenas com inputs. Se um URL de uma página tiver parâmetros que são usados directamente num procedimento ou

(30)

para construir uma query, sem que seja feita a correcta sanitiza¸c˜ao o problema vai ser o mesmo.

<%

nome = request.queryString["nome"]

objdb.query("select * from utilizadores where nome=" & nome) %>

No exemplo acima temos um caso de código vulnerável em que um parâmetro da query string é passado directamente para uma query. O parˆametro é o nome do utilizador e vai listar todas as linhas que tenham um nome igual ao do valor passado. Esta opera¸cão é feita sem que ocorra qualquer tipo de sanitiza¸cão. Neste caso, um utilizador malicioso pode usar o parâmetro nome para modificar o conte´udo da query [43].

Por exemplo, o utilizador malicioso poderia terminar a query e colocar uma tau-tologia, isto é uma condi¸cão que é sempre correcta, por exemplo, 1 = 1, para isso bastaria colocar um parˆametro que fosse ” or010 = 010 o resultado disso seria:

select * from utilizadores where nome="" or ’1’=’1’

Isto faria com que a informa¸cão de todos os utilizadores fosse listada indiscrimi-nadamente. A sanitiza¸cão neste caso deveria ser feita através da substitui¸cão das plicas por duas plicas, de modo a tornar toda a expressão que é passada para a

query numa string.

NoSQL Injection

NoSQL é um tipo de base de dados não relacional, onde não existe o conceito de tabelas como nas bases de dados clássicas. Numa base de dados não relacional os valores são guardados em registos, que podem ser organizados de várias formas,como grafos, pares chaves-valor, documento, entre outros. Este tipo de bases de dados oferece algumas vantagens em rela¸cão às bases de dados tradicionais, nomeadamente na escalabilidade e desempenho.

O tipo de ataques que são feitos a este tipo de base de dados podem inclusiva-mente ser mais danoso do que numa base de dados tradicional, porque os ataques ocorrem numa linguagem que não é declarativa.

Isto faz com que seja poss´ıvel potencialmente executar ataques na camada apli-cacional, enquanto que no SQL Injection os ataques est˜ao limitados `a camada da base de dados.

LDAP Injection

O LDAP é um protocolo de aplica¸cão que permite manter e aceder a directórios de servi¸cos de informa¸cão distribu´ıdos. Essencialmente, é uma forma de organizar

(31)

informa¸cão de utilizadores, grupos ou outro tipos de entidades. Esta organiza¸cão é feita através de hierarquias e permite definir atributos que caracterizam instâncias de cada um dos tipos de entidades.

O tipo de ataques que é feito aqui consiste, à semelhan¸ca com outro tipo de ataques da mesma classe, na introdu¸cão de conteúdos que vão modificar as querys LDAP. Neste caso vai permitir potencialmente a altera¸cão de comandos que levem `

a altera¸cão de permissões e do conteúdo que está na árvore LDAP.

2.1.12 Cross-Site Scripting

Ocorre quando é poss´ıvel a um utilizador enviar scripts maliciosos para outro uti-lizador, utilizando os campos de entrada da aplica¸cão. As consequência podem ser várias, por exemplo o acesso a cookies de sessão que podem permitir ao atacante roubar a sessão de outro utilizador. Pode também servir como método para levar o utilizador a fazer o download de ficheiros potencialmente maliciosos. Isto deve-se à ausência de uma correcta sanitiza¸cão ou codifica¸cão destes inputs ou parâmetros de um url.

Podemos distinguir dois tipos de XSS: client XSS e server XSS

O client XSS ocorre quando s˜ao usados dados de campos de entrada do lado do cliente para a actualiza¸cão de conteúdo do Document Object Model (DOM) sem que seja feita codifica¸cão. Este conteúdo pode estar a ser usado directamente na página, através de JavaScript, para a constru¸cão de elementos no DOM, podendo levar à execu¸cão de código potencialmente vulnerável.

document.write("<div>document.getElementById("#nome").val()</div>"); </script>

O caso acima constitui um exemplo . Nele temos um script que est´a a desenhar um

div directamente no DOM,e se houver conteúdo malicioso no input nome ent˜ao será colocado no div através da chamada de javascript que é feita.

O server XSS ocorre quando s˜ao usados dados que vêm do servidor directamente na página, porque o servidor não está a fazer nenhuma sanitiza¸cão ou codifica¸cão.

O exemplo acima ´e um dos casos mais simples de server XSS, onde temos o valor que vem da base de dados que ´e colocado directamente no DOM. No caso de um utilizador malicioso alterar o seu nome para, por exemplo, < script >

alert(”Conteudomuitomau”); < /script >, faria com que o conteudo a ser

(32)

<div ID="nome"><script>alert("Conteudo muito mau");</script></div>

2.1.13 Utiliza¸

c˜

ao de Componentes com Vulnerabilidades

Co-nhecidas

Estas vulnerabilidades surgem quando são inclu´ıdos componentes que têm, eles próprios, vulnerabilidades. Estas são muitas vezes algumas das acima. O problema surge quando são adicionados componentes sem que seja feita a análise devida so-bre as vulnerabilidades que estes podem conter. Estas são mais predominante em empresas cujo desenvolvimento de software seja maioritariamente dependente de bi-bliotecas externas, sem que estas sejam actualizadas ou verificadas da forma correcta antes de serem utilizadas.

2.2 M´

etodos de An´

alise

Os métodos de análise são utilizados para aumentar a confian¸ca na seguran¸ca da aplica¸cão, através da deteçcão e correçcão de vulnerabilidades. Estes métodos de-vem ser utilizados no ciclo de desenvolvimento das aplica¸cões para que qualquer funcionalidade que é adicionada seja correctamente validada.

Existem várias ferramentas diferentes para este efeito, que variam no tipo de análise que fazem, na linguagem que analisam e no pre¸co. No caso de empresas de menor dimensão o aconselhado é o uso de ferramentas de utiliza¸cão livre ou o desenvolvimento de ferramentas que melhor se adaptem ao respectivo ciclo de desenvolvimento.

2.2.1 An´

alise Dinˆ

amica

Na análise dinâmica a aplica¸cão é analisada em tempo de execu¸c˜ao (i.e., runtime). Este método também ´e conhecido como black-box, porque a aplica¸c˜ao é frequente-mente tratada como uma caixa negra, onde quem está a testar apenas tem acesso `

as entradas e sa´ıdas.

Esta análise utiliza técnicas de fuzzing para testar o comportamento da aplica¸cão quando alvo de inputs inválidos e inesperados[20]. A análise dinâmica oferece uma perspectiva do lado do atacante e permite descobrir métodos para explorar vul-nerabilidades, o que poderia não ser poss´ıvel descobrir com análises estáticas ou manuais.

Por exemplo, durante uma análise interna de seguran¸ca que foi feita a uma das aplica¸cões na Empresa Digital foi utilizada a ferramenta de análise dinâmica wasp zap [37]. Com esta aplica¸cão foi poss´ıvel injectar valores nos parâmetros da página e através da resposta da página perceber se existiam vulnerabilidades ou não.

(33)

2.2.2 An´

alise Est´

atica

Na análise estática, o código fonte é analisado sem que seja feita a sua execu¸cão. Por esta razão ferramentas de análise de código estático são apropriadas em qualquer ciclo de desenvolvimento dado que são capazes de chegar à raiz do problema de seguran¸ca e identificar potenciais problemas muito antes de o código ser executado. Permitem fazer uma análise do código sem o bias do programador e oferecem ainda a capacidade de rever o código legado contra novas vulnerabilidades. Dado que muitas destas ferramentas funcionam directamente sobre o código, oferecem várias vantagens não só em termos de tempo mas também em termos de custos e dão a oportunidade ao programador de aprender a fazer código mais seguro, prevenindo assim potencias vulnerabilidades no futuro [19]. Na secçcão 2.2.4 são discutidas em maior detalhe as vantagens de cada um dos tipos de análise.

Uma ferramenta de análise estática de código deve ser então capaz de identificar blocos de código que são potencialmente vulneráveis e reportar a sua severidade, sendo sempre da responsabilidade do programador ou analista determinar se se trata de um falso positivo ou um verdadeiro positivo.

Dado que a análise estática trabalha com o código fonte, tem um comporta-mento muito similar ao de um compilador. Esta necessita de ser capaz de transfor-mar código numa representa¸cão abstracta para depois conseguir comparar com os padrões que é capaz de reconhecer. Dependendo das capacidades da ferramenta, es-tes padrões podem ser estendidos, oferecendo a possibilidade de serem criados novos padrões ou de não poderem ser alterados. Isto leva potencialmente ao surgimento de falsos negativos, que constituem uma desvantagem já que levam ao surgimento de vulnerabilidades que deveriam ter sido identificadas como erros, mas que não geram nenhum alerta. Esta rela¸cão entre o número de falsos positivos, verdadeiros positivos e falsos negativos é o que permite inferir a qualidade de uma ferramenta de análise estática de código e é o que é usado muitas vezes como métrica.

Todos estes factores acarretam uma série de desafios à constru¸cão de uma ferra-menta de análise de código. Estes são:

• Desenho de um bom modelo de programa que seja capaz de reconhecer a gram´atica da linguagem alvo, de forma coerente, ou pelo menos ser capaz de reconhecer e identificar os potenciais erros.

• Resultados apresentados devem ser f´aceis de interpretar pelo programador. • Ter a capacidade de ser alterada face a novas vulnerabilidades ou de ser

cor-rigida caso seja necess´ario.

2.2.3 An´

alise Manual

Na análise de código manual é feita a análise percorrendo os ficheiros e procurando ”à mão” por vulnerabilidades.

(34)

Este tipo de análise foi feita a uma das aplica¸cões da empresa Escrita Digital, que implicou a análise manual a mais de 3 mil ficheiros.

O grande problema deste tipo de análise é que primeiro que tudo implica a forma¸cão de programadores sobre vulnerabilidade, sobre o que procurar, como cor-rigir e o que não fazer no futuro. É também um trabalho moroso e pode ser poten-cialmente dispendioso em termos financeiros em empresas de pequena dimensão que têm de alocar recursos humanos, i.e., programadores, que de outra maneira estariam a desenvolver novas funcionalidades. Implica também por vezes um conhecimento mais aprofundado da linguagem que se está a analisar.

2.2.4 Discuss˜

ao

Cada um dos métodos acima referidos tem vantagens e desvantagens. Contudo, em qualquer ciclo de desenvolvimento de uma aplica¸cão, a decisão não deve ser sobre que método usar, mas sim que ferramenta usar em cada um dos métodos.

Tal como referido acima, as ferramentas de análise dinâmica operam sobre o programa em execu¸cão e apresentam a grande vantagem de não necessitarem de acesso ao código fonte. Além disso, mostram, na perspectiva do atacante, a forma de explorar vulnerabilidades. Muitas vezes estão integradas com outras ferramentas de auditoria e permitem criar relatórios completos sobre o estado da aplica¸cão, as suas capacidades, e os servi¸cos que estejam desactualizados, entre outros.

A grande desvantagem das ferramentas de análise dinâmica é, por esta não possi-bilitar acesso ao código fonte, tornar dif´ıcil a localiza¸cão da vulnerabilidade quando esta é identificada.

Existe também o problema destas ferramentas muitas vezes não serem capazes de fazer análise de fluxos de dados, podendo dar origem a potenciais falsos negativos. [45]

As ferramentas de análise estática usam o código fonte ou compilado e analisam-no directamente. Têm a vantagem de serem capazes de descobrir vulnerabilidades muito antes de elas se revelarem e são muito mais fáceis de integrar directamente no ambiente de desenvolvimento do que ferramentas de análise dinâmica.

´

E necessário referir que a análise estática de código é um problema de indecidi-bilidade porque, em absoluto, é imposs´ıvel saber com certeza o fluxo de execu¸cão de um programa sem nunca o executar [43][44]. Se os padrões de análise não estiverem correctamente configurados podem surgir falsos positivos ou mesmo falsos negativos. Outro problema das ferramentas de análise estática é o de não serem capazes de validar os casos em que protocolos de autentica¸cão ou criptográficos não estejam correctamente desenhados. Pode também ser dif´ıcil provar se uma vulnerabilidade identificada pode ser explorada ou não. Por exemplo, uma página a que um utiliza-dor não consegue aceder pode estar vulnerável, mas esta poderá nunca ser explorada. Por último temos a análise manual, cujos problemas atrás referidos são óbvios. Não obstante é uma fase necessária e que deve, portanto, complementar as análises estática e dinâmica. No entanto, este tipo de análise é muito suscept´ıvel a erro

(35)

humano.

2.3 Ferramentas an´

alise est´

atica de c´

odigo

Qualquer ferramenta de análise estática de c´odigo recebe como input ficheiros de código fonte ou ficheiros já compilados. Constrói um modelo que representa o pro-grama, analisa-o seguindo uma base de regras e padrões e devolve o resultado ao utilizador.

´

E interessante estabelecer o paralelismo entre o funcionamento de um compilador, representado figura 2.1, e o funcionamento de uma ferramenta de análise estática, representada na figura 2.2, porque grande parte das técnicas usadas em ferramentas de análise estática são retiradas dos compiladores.

Figura 2.1: Representa¸c˜ao de alto n´ıvel de um compilador

Podemos observar que muitas das fases são as mesmas, à excep¸cão das fases finais, porque o propósito de um compilador é gerar um executável enquanto que o de uma aplica¸cão de análise é tirar conclusões sobre o código sem o executar.

A aplica¸cão que será desenvolvida neste projecto não vai conter todas as fases mencionadas na figura 2.2. Dentro da constru¸cão do modelo apenas vai conter a análise lexical e vão ser utilizadas algumas t´ecnicas de parsing. Isto porque para fazer uma ferramenta genérica com mais fases seria necessário fazer a gramática de qualquer linguagem alvo que se quisesse analisar. A vantagem de se fazer apenas a

(36)

Figura 2.2: Representa¸cão de alto n´ıvel de uma ferramenta de análise estática de código

an´alise lexical e parte de um parser ´e que não é necessário especificar a gramática mas apenas é necessário especificar os padrões que queremos identificar na linguagem alvo. A análise vai depois processar-se através do reconhecimento de padrões. Esta fase pode também ser desenvolvida através de redes neuronais, como explorado na seçcão 2.4).

2.3.1 An´

alise lexical

A an´alise lexical tem como objectivo definir tokens e traduzir o c´odigo num conjunto de instˆancias desses tokens. Em compiladores estas instˆancias tˆem o nome de lexemes e a identifica¸c˜ao dos tokens ´e feita recorrendo a express˜oes regulares.

Listing 2.1: C´odigo de exemplo

<%

’’Vai buscar o nome a query string ao parametro name

name = request.queryString["name"]

’’Isto vai imprimir para o ecra o name retirado do url

response.write name %>

Na analise lexical todas as linhas em branco e comentários no bloco de código 2.1 são ignorados. O foco desta análise, neste caso, é apenas o que está no bloco de

(37)

c´odigo 2.2.

Listing 2.2: C´odigo de exemplo sem coment´arios

<%

name = request.queryString["name"] response.write name

%>

Aplicando os padr˜oes dos tokens, s˜ao extra´ıdos v´arios lexemes que v˜ao ser colo-cados na tabela de s´ımbolos.

Tipicamente existem em todas as linguagens palavras reservadas, i.e., keywords, que não podem ser utilizadas como variáveis, nomes de instâncias ou classes, como ´e o caso de if, else, true, f alse, int entre outros. Nestas palavras reservadas n˜ao existem instâncias e portanto a descri¸cão do token é o lexemme em si.

Temos ainda os literais que s˜ao aquilo a que se pode chamar de strings e que est˜ao entre “ ” . Finalmente, temos ainda os lexemes que s˜ao guardados em tabelas de s´ımbolos, juntamente com alguns dados como a linha e/ou a coluna onde apareceu pela primeira vez e ainda outro tipo de informa¸c˜ao.

Do bloco de c´odigo 2.2 podemos ent˜ao extrair os seguintes tokens e lexemmes; ID(name,1) - Lexemme = - Token ID(request,2) - Lexemme . - Token ID(queryString,3) - Lexemme ( - Token LITERAL(”name”) - Lexemme ) - Token ID(response,4) - Lexemme . - Token ID(write,5) - Lexemme ID(name,1) - Lexemme

A tabela de s´ımbolos que extra´ımos desta an´alise est´a representada na tabela abaixo Lexemme Position name 1 request 2 queryString 3 response 4 write 5

Tabela 2.1: Tabela de s´ımbolos

Nesta fase de análise lexical ´e interessante mencionar a ferramenta flex. Esta ferramenta permite especificar padrões através de expressões regulares e escrever

(38)

código que vai ser executado quando uma expressão é reconhecida. Tipicamente a sua açcão ´e retornar um token para uma ferramenta de parsing.

Express˜oes regulares

A maneira mais fácil de reconhecer padrões é através de expressões regulares. Ex-pressões regulares são um conjunto de anota¸cões constru´ıdas a partir de operadores de concatena¸cão, fecho e uni˜ao, assim como tokens que descrevem alfabetos (con-juntos de um ou mais s´ımbolos). A grande vantagem das expressões regulares é a capacidade de poderem descrever qualquer linguagem que pode ser constru´ıda aplicando os operadores aos s´ımbolos de um alfabeto.

Um alfabeto no contexto de expressões regulares é definido como um conjunto finito de s´ımbolos, por exemplo o conjunto {0,1} pode ser definido como o alfabeto binário.

O exemplo mais simples numa linguagem de programa¸cão é a expressão regular que descreve um identificador em linguagem c, neste caso é [ a-zA-Z][ a-ZA-Z0-9]{0,31}.

Esta expressão regular é capaz de identificar qualquer conjunto de s´ımbolos que comece com um underscore ou por uma letra mai´uscula ou minúscula e que seja seguida de uma combina¸c˜ao de underscores, letras mai´usculas ou minúsculas ou números que podem ter entre zero a trinta e um s´ımbolos. Esta expressão regular serviria para identificar então expressões no c´odigo fonte como lexemmes de tokens do tipo identificadores.

A grande vantagem das expressões regulares é serem simplificáveis utilizando os conceitos de alfabetos.

Por exemplo, se definirmos o alfabeto letras como o conjunto [a-zA-Z ] e o alfabeto numeros como o conjunto [0-9], podemos reescrever a regra [ zA-Z][ a-zA-Z0-9]{0,31} como (letras )(letras |numeros){0,31}.

´

E interessante tamb´em mencionar aqui m´aquinas de estado ou FSA(finite state

automaton), atrav´es da qual é poss´ıvel descrever visualmente o comportamento de uma expressão regular. Nas máquinas de estado temos estados que são representados como c´ırculos, transi¸cões que são representados como setas e descrevem açcões me-diante uma condi¸cão. A expressão de cima pode ser traduzida na seguinte máquina de estado:

(39)

A leitura da máquina de estados da Figura 2.3 é feita da seguinte maneira: quando ´e reconhecido um caractere que esteja compreendido no alfabeto letras ´e feita a transi¸cão para o estado 1, quando deste é reconhecido qualquer caractere que esteja compreendido no alfabeto letras ou no alfabeto numeros, a m´aquina permanece no estado 1 até que identifique qualquer outro s´ımbolo (representado pelo alfabeto other ). Nesta fase, termina o reconhecimento de um identificador e pode-se chegar a um estado final representado por um c´ırculo, com um c´ırculo mais pequeno concêntrico. Este tópico será mais aprofundado na seçcão seguinte.

M´aquinas de estado

O reconhecimento interno de ferramentas de análise lexical é feito a partir destas máquinas de estado. Uma máquina de estado ´e o que se chama um aceptor de uma linguagem regular. É um modelo matemático de um computador que potencialmente é capaz de reconhecer qualquer programa, dentro das quais podemos distinguir dois tipos [42]:

• Autómato finito não determin´ıstica (AFND) - não têm restri¸cões quanto aos s´ımbolos nas transi¸cões podendo ter várias transi¸cões com o mesmo s´ımbolo a partir do mesmo estado. Podem ainda ter transi¸c˜oes , que representa um caracter vazio. ´E destas mesmas labels em transi¸c˜oes diferentes que surge o não determinismo porque do mesmo estado com o mesmo s´ımbolo pode-se ir para estados diferentes.

• Autómato finito determinista (DFA),- não podem ter o mesmo s´ımbolo em diferentes transi¸cões a partir de um mesmo estado.

Os programas que são capazes de reconhecer expressões regulares converter in-ternamente a expressão regular para uma destas máquinas de estado, e de seguida alimentam a m´aquina com a string que tˆem a expressão regular a ser reconhecida.

Existem outras variantes destas como o Posix AFND. A grande diferen¸ca desta para a AFND é que no Posix AFND ´e feito backtracking (voltar para um estado anterior para testar uma transi¸cão diferente) até ser descoberta a maior expressão poss´ıvel. Existe também uma variante para o DFA, e existem ainda h´ıbridos que tentam fazer os dois.

M´aquinas de estado n˜ao deterministas (AFND)

Uma máquina de estados não determinista consiste num número finito de estados, um alfabeto que é reconhec´ıvel pela máquina, um fun¸cão de transi¸cão para cada estado (que permite atribuir para cada s´ımbolo um estado seguinte), um estado inicial e um conjunto de estados finais.

Para desenhar uma máquina de estado capaz de reconhecer a expressão regu-lar, ”abc(a|b|c)*a” que corresponde a qualquer expressão que come¸ca com ”abc” e termina com ”a” e que pode ter no meio uma combina¸cão qualquer de a,b ou c, a máquina de estados correspondente seria:

(40)

Figura 2.4: M´aquina de estados que reconhece a express˜ao abc(a|b|c)*a

Se considerarmos que as transi¸c˜oes na figura 2.4 podem ser ignoradas, a máquina de estado acima é trivial. Podemos simplificar a versão acima

Figura 2.5: M´aquina de estados simplificada que reconhece a express˜ao abc(a|b|c)*a

Apartir desta máquina de estados se fizermos passar qualquer expressão na forma ”abc(a|b|c)*a”, como abcbbbbccccaaaaaaaa, abcbbaabaa entre outras, chegamos sempre a um estado final 13 na máquina de estados da figura 2.4 ou 4 na máquina de estados da figura 2.5, o que indica que a expressão dada é reconhecida pela máquina de estados, dado que podemos chegar a um estado de aceita¸cão.

M´aquinas de estados deterministas (DFA)

Numa máquina de estados determinista, cada s´ımbolo está associada apenas a uma transi¸cão e não existem transi¸c˜oes associadas ao s´ımbolo . Para se desenhar uma máquina de estados deterministas parte-se sempre de uma máquina de estados não deterministas. A mesma expressão regular referida em 2.3.1, representada neste tipo de máquina de estados, daria origem à máquina de estados mostrada na figura 2.6.

A conversão para este tipo é também bastante pesada. A ideia base de conversão é calcular para cada estado a transi¸cão poss´ıvel associada a cada s´ımbolo e perceber quais destas dão origens a estados novos. Computacionalmente este processo é muito trabalhoso porque de cada vez que surge um estado novo é preciso re-calcular as transi¸cões para cada s´ımbolo e perceber se o estado a que dá origem já existe ou não. Se não existir é necessário continuar a calcular.

(41)

Figura 2.6: M´aquina de estados que reconhece a express˜ao abc(a|b|c)*a

Compara¸c˜ao

A grande vantagem das DFA é, dado que para cada estado existe apenas uma transi¸cão para cada s´ımbolo, um estado de aceita¸cão (final) pode ser alcan¸cado muito mais rapidamente. Por outro lado, em compara¸cão com as AFND, onde é poss´ıvel ter várias transi¸cões de um estado com o mesmo s´ımbolo, nestas pode vir a ser necess´ario fazer backtracking.

Outra desvantagem dos DFA ´e o espa¸co que ocupam. Qualquer AFND para uma linguagem Ln deve ter pelo menos 2n estados [16]. Isto pode ser um problema

se existirem alfabetos com muitos s´ımbolos e expressões regulares muito complexas, porque pode ser necessário utilizar espa¸co em disco se o espa¸co em memória não for suficiente para armazenar a tabela de transi¸cão.

Isto é uma das vantagens de utilizar as bibliotecas de expressões regulares do C# que fazem a tradu¸cão da expressão regular para AFND e permitem a pré compila¸cão de expressões regulares, conversão do AFND para DFA. Isto faz com que a máquina de estados resultante seja mantida em memória durante o tempo de execu¸cão e não seja necessário estar sempre a reconstruir a mesma [24][25].

Algumas ferramentas de análise estática de código terminam a sua análise nesta fase. Ferramentas como o RATS, FLAWFINDER, YASCAA entre outras, têm al-gumas fun¸cões identificadas como potencialmente vulneráveis a ataques e quando as identificam recorrendo simplesmente a análise lexical, lan¸cam alertas.

2.3.2 Parsing

Este processo serve para, recorrendo a tokens obtidos pela an´alise lexical (figura 2.7), transformar o c´odigo fonte numa parse tree.

A parse tree ´e constru´ıda a partir daquilo a que se chama uma gramática livre de contexto, tipicamente representada na nota¸cão Backus-Naur Form (BNF). Esta forma de especificar gramáticas é fácil de ler, de expandir e de especificar qualquer

(42)

Figura 2.7: Rela¸c˜ao entre a an´alise lexical e o parser

linguagem.

Gram´aticas livres de contexto

Este formato é o que permite especificar a sintaxe de uma linguagem através daquilo a que se chamam produ¸cões, que se constroem a partir de s´ımbolos terminais e não terminais.

S´ımbolos terminais s˜ao os tokens obtidos atrav´es do reconhecimento de expressões regulares pela análise lexical. Não terminais são os s´ımbolos que permitem especi-ficar a hierarquia de uma linguagem e são uma combina¸cão de s´ımbolos terminais e/ou não terminais. Produ¸cões especificam o método como s´ımbolos terminais e não terminais, podem ser combinados para formar strings.

A melhor forma de perceber gramáticas livres de contexto é representando a gramática de opera¸cões aritméticas. Neste caso, a análise lexical vai devolver os

tokens ou s´ımbolos terminais id, +, −, ∗, /, (, ). Um id ´e qualquer número de zero a nove. Neste caso o que a gramática deve representar é a sintaxe correcta de uma opera¸cão matemática. Esta gramática está representada na tabela 2.2. Com esta

1a _express˜_ao _→ _express˜_{ao + termo}

2a express˜ao → express˜ao - termo 3a _express˜_ao _→ _termo

4a _termo _→ _{termo * factor}

5a _termo _→ _{termo / factor}

6a termo → factor

7a _factor _→ _{( express˜}_{ao )}

8a _factor _→ _{id}

Tabela 2.2: Regras de produ¸cão para opera¸cões aritméticas

gramática é poss´ıvel especificar a estrutura que qualquer opera¸cão aritmética tem de seguir.

(43)

Se tomarmos como exemplo a seguinte expressão (1 + 4) ∗ 5 + 3, esta expressão vai come¸car por aplicar a primeira regra, que vai resultar em expressão + termo.

Sendo a express˜ao igual a (1 + 4) ∗ 5 e o termo igual a 3. De seguida vai ser aplicada

a terceira regra a (1 + 4) ∗ 5, que vai resultar em termo, que por sua vez vai aplicar a quarta regra termo ∗ f actor. O termo ainda pode ser mais simplificado, o que vai resultar em f actor, que vai resultar em (express˜ao). Sobre esta podemos aplicar

a primeira express˜ao que vai resultar em expressão + termo. Estas depois v˜ao ser simplificadas até `a oitava regra, que vai ser traduzida no token id. Estas regras s˜ao aplicadas aos tokens seguintes. Isto mostra-nos que a express˜ao (1 + 4) ∗ 5 + 3 é uma expressão válida, porque pode ser derivada recorrendo ás expressões da tabela 2.2 da seguinte forma

expressão → expressão + termo expressão + termo → termo + termo termo + termo → termo ∗ f actor + termo

termo ∗ f actor + termo → f actor ∗ f actor + termo f actor ∗ f actor + termo → (express˜ao) ∗ f actor + termo

(express˜ao) ∗ f actor + termo → (express˜ao + termo) ∗ f actor + termo

(express˜ao + termo) ∗ f actor + termo → (id + termo) ∗ f actor + termo

(id + termo) ∗ f actor + termo → (id + id) ∗ f actor + termo (id + id) ∗ f actor + termo → (id + id) ∗ id + termo

(id + id) ∗ id + termo → (id + id) ∗ id + id (id + id) ∗ id + id → (1 + 4) ∗ 5 + 3

A deriva¸cão aqui feita é à esquerda e existe ainda uma variante à direita. Com estas deriva¸cões é depois poss´ıvel fazer aquilo a que se chama ´arvores de parsing ou sintáctica, sobre as quais é poss´ıvel fazer análises. Existem também muitas vezes representa¸cões directas do código tal como o programador escreveu.

A ´area de parsing dentro de compiladores ´e uma área muito vasta existem vários tipos de gramáticas que especificam o método como ´e feito o parsing, se ´e da esquerda para a direita assim como o n´umero de lookaheads (s´ımbolos que s˜ao vistos antes de ser aplicada uma regra de produ¸cão). Estas considera¸cões contudo já não são relevantes para este projecto. No entanto, são retiradas algumas ideias como a cria¸cão de uma gramática de regras que representam padrões de código vulnerável.

2.3.3 Arvore sint´

´

actica

Uma ´arvore sint´actica ou de parsing ´e aquilo que permite representar sob a forma de ´

arvore, a estrutura de um código fonte escrita numa linguagem de programa¸cão. A vantagem desta representa¸cão é que permite perceber os vários caminhos que uma fun¸cão pode tomar, de acordo com valores ou condi¸cões diferentes. É sobre esta ´

arvore que são depois aplicadas as técnicas de análise de controlo de fluxo, dados e a variante desta, i.e, taint analysis.

Para fazer a conversão é necessário fazer a tradu¸cão das várias regras de produ¸cão que vão especificar a cria¸cão de nós e de folhas na árvore. Neste contexto, um