Regras

O ficheiro de regras ´e onde est´a definido o comportamento do motor quando encon- tra uma sequˆencia de tokens especificados no ficheiro. A estrutura deste ´e muito semelhante `a do l´exico.

Existe um conjunto de regras associadas a cada linguagem. Estas regras ditam o comportamento do motor quando uma sequˆencia ´e encontrada.

Cada conjunto de regras tem associado um atributo que define o nome do con- junto de regras, assim como dois atributos que definem que tokens devem ser usados para ignorar vulnerabilidades em certas zonas do c´odigo. Mostra-se como exemplo o bloco c´odigo XML em 3.9, no qual foi definido o contexto com o nome ASP. Neste foi definido como tokenLigarVulnerabilidade o token T INICIAR IGNORAR e como tokenDesligarVulnerabilidade o token T FIM IGNORAR. Estes tokens tˆem que estar definidos no l´exico.

Listing 3.9: C´odigo de exemplo do cabe¸calho de regras 1 <regras nome="asp" tokenLigarVulnerabilidade="T__INICIAR_IGNORAR"

tokenDesligarVulnerabilidade="T__FIM_IGNORAR">

2 .

3 .

4 .

5 </regras>

O ficheiro de regras tem uma sec¸c˜ao onde est˜ao definidas express˜oes. Cada uma tem dois atributos: um nome ´unico e uma regra que lhe est´a associada. Esta regra ´e escrita utilizando os tokens do ficheiro de l´exico.

1 <expressoes>

2 <expressao nome="RESPONSE_WRITE" regra="@TIDENTIFICADOR(Response,CI)

@TPONTO @TIDENTIFICADOR(WRITE,ci)"/>

3 <expressao nome="PROCEDIMENTO_INICIO_QUERY" regra="@TPONTO

@TIDENTIFICADOR(query,ci) @TPARENTESISESQ" />

4 <expressao nome="PROCEDIMENTO_FIM_QUERY" regra="@TVIRGULA @TFALSE

@TVIRGULA @TNUMEROINTEIRO @TPARENTESISDIR" />

5 </expressoes>

No bloco de c´odigo XML de exemplo 3.10 est˜ao definidas v´arias express˜oes. A defini¸c˜ao de regras obedece a uma condi¸c˜ao: os tokens devem ser todos iniciados com o caracter @, isto para que o motor consiga perceber o in´ıcio de um token. No exemplo ilustrado observa-se que a descri¸c˜ao de tokens ´e sempre a mesma excepto quando se trata de tokens que possam ter textos associados.

´

E necess´ario, ao descrever alguns padr˜oes, especificar alguns textos. Por exem- plo, se for necess´ario especificar o padr˜ao que corresponde `a linha 1 do bloco de c´odigo em 3.11 ´e essencial poder especificar, n˜ao s´o qual o token, mas a sequˆencia de caracteres que devem estar associados a esse token. Ou seja, a sequˆencia a ser identificada tem um identificador response (o texto seria o response e o token se- ria um TIDENTIFICADOR). Segue-se um token que corresponde ao ponto (token TPONTO sem nenhum texto associado). Por fim, segue-se mais um identificador

write. Contudo, este ´e um caso onde o texto a ser identificado ´e o texto associado na sua totalidade. Existem situa¸c˜oes onde isso n˜ao acontece. Para especificar um padr˜ao para a situa¸c˜ao das linhas 3, 4 e 5, sem que sejam descritas todos as va- riantes que existem e que corresponde a um script da base de dados, foi criada a capacidade de indicar que apenas parte do texto deve ser reconhecida (neste caso o

select). Existe ainda a possibilidade destes textos poderem estar em mai´usculas ou min´usculas e a linguagem a ser analisada ser case insensitive. Isto ´e resolvido im- plementando a capacidade de especificar se o texto deve ser identificado ignorando se os caracteres s˜ao mai´usculas ou min´usculas.

Listing 3.11: C´odigo de exemplo 1 response.write

2 RESPONSE.WriTE

3 "select * from Escola"

4 "select * from Utilizadores" 5 "select * from Alunos"

Existem trˆes situa¸c˜oes diferentes. Na primeira, o texto deve ser exactamente igual ao texto associado. Na segunda ´e apenas necess´ario que parte do texto as- sociado esteja contido no texto identificado. Finalmente, o texto identificado deve ser indiferente a mai´usculas ou min´usculas. Ao descrever o padr˜ao que se pretende identificar ´e permitido associar um texto ao token que quer ser identificado, assim como flags que descrevem o comportamento do motor quando identifica o texto.

Cap´ıtulo 3. Aplica¸c˜ao Athena 47

Foram criadas duas flags: a flag CI, que permite que o texto seja emparelhado in- dependentemente de este estar em mai´usculas ou min´usculas e a flag P que permite indicar ao motor que o texto a identificar deve apenas conter uma parte do texto associado ao token. As express˜oes para identificar as linhas de bloco de c´odigo em 3.11 poderiam ser descritas como est´a representado no bloco de c´odigo de exemplo 3.12.

Listing 3.12: Express˜oes para o c´odigo de exemplo

1 <expressao nome="RESPONSE_WRITE" regra="@TIDENTIFICADOR(Response,CI)

@TPONTO @TIDENTIFICADOR(WRITE,ci)"/>

2 <expressao nome="SELECT" regra="@TLITERAL(select,p)"/>

Existe tamb´em uma sec¸c˜ao de contextos que, `a semelhan¸ca do l´exico, oferece a capacidade de em diferentes contextos, serem especificados diferentes padr˜oes para serem reconhecidos. A estrutura desta ´e exactamente igual `a do l´exico ou seja, cada contexto tem um nome e uma a¸c˜ao de erro no caso de nenhum padr˜ao ser reconhecido. Cada um destes contextos tem uma lista de padr˜oes que ao serem emparelhados v˜ao activar as ac¸c˜oes que lhes est˜ao associadas.

Dentro das regras existe uma sec¸c˜ao de vulnerabilidades que ´e apenas uma lista de nomes que s˜ao utilizados pelas ac¸c˜oes. Esta sec¸c˜ao pode ser estendida no futuro para associar um atributo que detalhe alguma informa¸c˜ao sobre a vulnerabilidade em si e de que maneira pode ser corrigida.

Ac¸c˜oes

Algumas das ac¸c˜oes definidas nas regras s˜ao iguais `as anteriormente definidas no l´exico. Estas ac¸c˜oes, tal como explicado, s˜ao activadas quando um padr˜ao ´e empa- relhado.

Estas ac¸c˜oes tˆem que indicar ao motor os padr˜oes a serem identificados, a vul- nerabilidade que est´a associada e indicar mudan¸cas de contexto. Estas mudan¸cas de contexto s˜ao mais complexas que no l´exico. No processo de identifica¸c˜ao de um padr˜ao pode ser necess´ario saltar de um contexto para outro, mantendo no¸c˜ao do contexto em que o motor estava anteriormente, para poder continuar a aplicar os padr˜oes desse contexto. Para isso foi criado o conceito de pilha de contextos (FIFO-First In Firs Out) onde ´e poss´ıvel guardar uma s´erie de contextos para que a informa¸c˜ao esteja guardada caso seja necess´ario voltar para contextos anteriores. Para contemplar as situa¸c˜oes anteriores foram criadas as ac¸c˜oes espec´ıficas ao XML das regras abaixo descritas:

• Alerta: ´e a ac¸c˜ao mais relevante nas regras e ´e respons´avel por devolver uma sequˆencia que tem informa¸c˜ao sobre a sequˆencia do ficheiro que foi capturada pelo padr˜ao, assim como a vulnerabilidade que lhe est´a associada e outras informa¸c˜oes como a linha e a coluna do in´ıcio da sequˆencia. Esta ac¸c˜ao recebe nas regras um parˆametro que ´e a vulnerabilidade, a qual tem que estar descrita nas regras;

• Entrar: ´e a ac¸c˜ao que permite colocar um contexto na pilha;

• Sair: ´e a ac¸c˜ao que retira o contexto actual da pilha e coloca o motor no contexto anterior;

• Saltar: ´e a ac¸c˜ao igual `a a¸c˜ao do l´exico e permite saltar do contexto actual para outro. A diferen¸ca desta a¸c˜ao para a a¸c˜ao Entrar ´e que n˜ao ´e guardado o contexto anterior;

• Ignorar: ´e igual `a ac¸c˜ao do l´exico e serve apenas para o motor n˜ao fazer nada e continuar. Esta a¸c˜ao ´e usada muitas vezes com padr˜oes de fun¸c˜oes que s˜ao seguros e onde n˜ao queremos que o padr˜ao gere um alerta.

• GuardarLocalizac¸˜ao: ´e aquela que permite guardar a localiza¸c˜ao actual do padr˜ao. ´E muitas vezes utilizada em conjunto com a ac¸c˜ao Entrar, para guar- dar a posi¸c˜ao em que foi detectado o in´ıcio da sequˆencia. Deste modo quando o alerta ´e lan¸cado noutro contexto que n˜ao o original, a posi¸c˜ao associada ao alerta ´e a do in´ıcio da fun¸c˜ao.