C.E.S.A.

R CENTRO DE ESTUDOS E SISTEMAS AVANADOS DO RECIFE

CINTIA LEITE CARVALHO

INFLUNCIA DA PADRONIZAO DE CDIGO NO DESENVOLVIMENTO DE SOFTWARE SEGURO UTILIZANDO A FERRAMENTA PMD

RECIFE 2011

CINTIA LEITE CARVALHO

INFLUNCIA DA PADRONIZAO DE CDIGO NO DESENVOLVIMENTO DE SOFTWARE SEGURO UTILIZANDO A FERRAMENTA PMD

Monografia apresentada ao programa de Especializao de Segurana em Engenharia de Software do Centro de Estudos e Sistemas Avanados do Recife C.E.S.A.R, como requisito para a obteno do ttulo de Especialista em Engenharia de Software com nfase em Segurana. Orientao: Prof. Felipe Ferraz

RECIFE 2011

ii

C.E.S.A.R CENTRO DE ESTUDOS E SISTEMAS AVANADOS DO RECIFE

Influncia da padronizao de cdigo no desenvolvimento de software seguro utilizando a ferramenta PMD CINTIA LEITE CARVALHO

Monoigrafia apresentada ao programa de Mestrado em Engenharia de Software do Centro de Estudos e Sistemas Avanados do Recife C.E.S.A.R, como requisito para a obteno do ttulo de Especialista em Engenharia de Software com nfase em Segurana. Data de aprovao: _____ / _____ / 2011.

Banca examinadora:

_________________________________ Prof.(a).Dr.(a) *** C.E.S.A.R Centro de Estudos e Sistemas Avanados do Recife

_________________________________ Prof.(a).Dr.(a) *** C.E.S.A.R Centro de Estudos e Sistemas Avanados do Recife

_________________________________
Prof.(a).Dr.(a)

C.E.S.A.R Centro de Estudos e Sistemas Avanados do Recife

iii

Resumo Esta pesquisa aborda a importncia da segurana como item essencial no desenvolvimento de software, falando sobre alguns dos tipos de ataques, vulnerabilidades e correes de falhas que ocorrem na maioria dos sistemas em plataforma web, que so alvos de ataques de pessoas mal intencionadas, muitas vezes com a inteno de roubo de informaes. Este trabalho tambm exibe o quadro atual dos incidentes de segurana, sendo este um fator que leva motivao e preocupao para uma maior abordagem da segurana de software. Como assunto principal, esta pesquisa prope a adoo da juno das tcnicas de padronizao de software, utilizando a ferramenta PMD de anlise esttica de cdigo, com as definies de proteo listadas pela Owasp em seu Top 10 que mostra as dez principais vulnerabilidades e prope a forma de cont-las. Conseqentemente, exige-se a melhoria da codificao de software (tornando-o seguro) fazendo com que esta ao seja item primordial no processo de desenvolvimento de software, que tende a ser aprimorado juntamente com a qualificao de seus profissionais. Esta pesquisa exibe a forma de utilizao da ferramenta PMD na criao e manuteno de regras (baseadas no Top 10 da Owasp), alm do comportamento da IDE Eclipse aps a anlise de cdigo pela ferramenta com a verificao dos seus resultados.

Palavras-chave Segurana. Software. Desenvolvimento. OWASP. PMD. Top 10.

Padronizao. Informao. Codificao. Requisitos de software. Processo de desenvolvimento. Vulnerabilidade. Ataque. Incidente de segurana. Evento de Segurana. Anlise esttica de cdigo. Validao. Regras. Eclipse.

iv

Abstract This research addresses the importance of security as an essential item in software development, talking about some of the types of attacks, vulnerabilities and bug fixes that occur in most systems in the Web platform, which are targets of attacks by malicious people often with the intention of stealing information. This work also displays the current frame of security incidents, and this is one factor that leads to motivation and concern for a greater approach to software security. Main subject, this research proposes the adoption of the joint technical standard software tool, using PMD static code analysis, with the definitions listed for protection in the OWASP Top 10 showing the top ten vulnerabilities and proposes how to contain them. Consequently, it is required to improve the software coding (making it safe) so that this action item is paramount in the process of software development, which tends to be enhanced along with the qualification of its professionals. This research shows how to use the tool PMD in creating and maintaining rules (based on the OWASP Top 10), and the behavior of the Eclipse IDE after the code analysis tool to check their results.

Key-words Security. Software. Development. OWASP. PMD. Top 10. Standardization. Information. Encoding. Software Requirements. The development process.

Vulnerability. Attack. Security incident. Security Event. Static code analysis. Validation. Rules. Eclipse.

SUMRIO
1 1.1 2 2.1 2.1.1 2.1.2 2.1.3 2.2 2.3 2.4 2.5 2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 2.6 2.6.1 INTRODUO ............................................................................................. 1 ESTRUTURA DA MONOGRAFIA ................................................................ 2 ESTADO DA ARTE ..................................................................................... 4 SEGURANA .............................................................................................. 4 Segurana da informao ............................................................................ 7 Incidente de segurana da informao ........................................................ 8 Evento de segurana da informao ............................................................ 8 VULNERABILIDADE .................................................................................... 8 ATAQUE .................................................................................................... 10 MOTIVAO PARA SEGURANA ........................................................... 10 FERRAMENTAS DE ANLISE ESTTICA DE CDIGO .......................... 14 Anlise esttica de cdigo.......................................................................... 14 PMD ........................................................................................................... 15 Checkstyle.................................................................................................. 16 Findbugs .................................................................................................... 16 Ferramenta escolhida................................................................................. 17 OWASP ...................................................................................................... 17 Top 10 ........................................................................................................ 17 2.6.1.1 Tpicos estudados nesta pesquisa ....................................... 18 2.6.1.2 Tpicos no contemplados nesta pesquisa ........................... 20 3 3.1 3.2 3.3 3.4 4 4.1 4.2 ESTUDO DE CASO ................................................................................... 21 REGRAS DO PROJETO ............................................................................ 22 VALIDAO DAS REGRAS ...................................................................... 26 RELATRIOS ............................................................................................ 30 OUTRAS REGRAS .................................................................................... 32 CONSIDERAES FINAIS ....................................................................... 36 EVOLUO DO TRABALHO ..................................................................... 38 CONCLUSO ............................................................................................ 38

REFERNCIAS ......................................................................................................... 40

Lista de ilustraes
Figura 1 - CERT.br: Incidentes Reportados e Ataques Acumulados (2011) ............... 4 Figura 2 - CERT.br (2011) ......................................................................................... 11 Figura 3 - Source Code PMD .................................................................................... 22 Figura 4 - Sintax Tree PMD ....................................................................................... 23 Figura 5 - XPath PMD ............................................................................................... 23 Figura 6 - Quadro de Resposta PMD ........................................................................ 23 Figura 7 - PMD Plugin ............................................................................................... 24 Figura 8 - Rules Configuration................................................................................... 25 Figura 9 - Properties PMD ......................................................................................... 26 Figura 10 - Menu PMD .............................................................................................. 27 Figura 11 - Sinalizao PMD ..................................................................................... 27 Figura 12 - Sinalizao Java ..................................................................................... 28 Figura 13 - Chamada para validar dados .................................................................. 29 Figura 14 - Mtodo dadosRequest ............................................................................ 29 Figura 15 - Propriedade do Projeto ........................................................................... 30 Figura 16 - Relatrio PMD ......................................................................................... 31 Figura 17 - Relatrio Adicional PMD ......................................................................... 31 Figura 18 - Concatenao em classe ResultSet ....................................................... 33 Figura 19 - Mtodo fazerConsulta ............................................................................. 34 Figura 20 - Chamada para realizar consulta de dados .............................................. 34 Figura 21 - Expresso executeQuery utilizada com parmetro ................................. 35

Lista de tabelas

Tabela 1 - Dados Consolidados ................................................................................ 14

ABREVIATURAS

Sigla ISO IDE MSDN XML HTML URL SSL

Significado International Organization for Standardization Integrated Development Environment Microsoft Developer Network Extensible Markup Language HyperText Markup Language Uniform Resource Locato Secure Sockets Layer

1 INTRODUO

A segurana da informao um assunto que vem sendo cada vez mais comentado por diversas fontes devido grande massa de dados que circulam diariamente atravs da internet. Este assunto abordado com mais nfase quando algum incidente relacionado segurana de dados e sistemas ultrapassa a fronteira dos profissionais de tecnologia da informao e atingem os usurios comuns. Porm, com exceo de algumas organizaes, a segurana da informao ainda vem sendo tratada como item em segundo plano e, de certa forma, ainda se ignoram certos riscos reais e j conhecidos. Este fato ocorre principalmente durante a fase de desenvolvimento do software. Este ser o foco desta pesquisa, que abordar as boas prticas para codificao de sistemas seguros utilizando tcnicas de padronizao de cdigo fonte atravs de ferramenta de anlise esttica de cdigo onde ser possvel, aps identificar os problemas, criar regras para que sejam evitados. Aliada a isto, os estudos e pesquisas relacionadas s boas prticas de programao sero totalmente baseadas no Top Ten da Owasp. A inteno de realizar a juno das prticas de programao promovidas pela Owasp com a criao de regras de padronizao de cdigo tratar a segurana como um dos itens base do desenvolvimento de software e no apenas como item adicional, j que muitos dos erros cometidos so por desconhecimento tcnico por parte dos profissionais e at mesmo por desinteresse por parte das empresas. Ao que contribui para um crescente aumento dos incidentes de segurana. Esta pesquisa tem como seu principal objetivo identificar pontos de vulnerabilidades ainda em tempo de codificao, aplicando regras, e utilizando ferramenta de padronizao de cdigo, que devero auxiliar no processo de desenvolvimento de software seguro. Para isso teremos os passos a seguir: Detectar falhas cometidas pelos desenvolvedores no momento da codificao de softwares, em plataforma web.

Utilizar, como referncia, o Top 10 de vulnerabilidades da OWASP. Utilizar a ferramenta PMD para definir e gerenciar a padronizao de cdigo. Definir/desenvolver regras de padronizao com os recursos da ferramenta PMD.

Verificar se as regras definidas pela ferramenta esto sendo devidamente seguidas pelos desenvolvedores atravs da prpria ferramenta PMD. Desta forma, aps a aplicao das regras, baseadas nos itens da Owasp e

utilizando a ferramenta de anlise esttica de cdigo, ser possvel visualizar a situao do cdigo fonte de uma aplicao no que se refere segurana. Atravs de indicaes da prpria ferramenta teremos nmeros informando a quantidade e a localizao das vulnerabilidades que representam perigo para a aplicao e para seus dados. Tudo isto ainda em tempo de desenvolvimento, o que contribui para a qualidade do software, para a melhoria do processo de desenvolvimento e para o aperfeioamento profissional uma vez que a codificao segura poder se tornar um hbito no ambiente em que for adotada. 1.1 ESTRUTURA DA MONOGRAFIA Esta monografia est separada pelos seguintes captulos: 1.1.1. Estado da Arte Aborda o estado atual da segurana da informao de acordo com dados reportados a rgo que instituies que fazem o mapeamento dos nmeros dos incidentes de segurana. Possui definies para: segurana, incidente, eventos de segurana, vulnerabilidade, ataque alm de explicar a motivao para segurana. mencionada algumas das ferramentas de anlise esttica de cdigo disponveis do mercado. H o detalhamento a respeito da Owasp e seu Top Ten 2010.

1.1.2. Estudo de Caso H a anlise de um pequeno prottipo que tem como objetivo verificar vulnerabilidades e, a partir dela, criar as regras para que sejam adotadas como padro de codificao. Tambm exibida a forma como criar tais regras de codificao utilizando as funcionalidades da ferramenta selecionada. So realizados testes de validao das regras onde possvel verificar o comportamento da IDE Eclipse aps a anlise da ferramenta. Tambm so criadas outras regras adicionais, porm todas baseadas nos itens da Owasp. 1.1.3. Consideraes Finais Este captulo exibe a evoluo do trabalho abordando seus resultados, vantagens e desvantagens da utilizao da padronizao de cdigo associado a itens relacionados codificao segura de software. E por fim, a concluso final da monografia.

2 ESTADO DA ARTE

Este captulo abrange o estado atual da segurana da informao quando se trata de aplicaes em plataforma web, suas vulnerabilidades, os valores de seus dados e a motivao para adoo de prticas que tornam o ambiente computacional menos propcio a investidas mal intencionadas. 2.1 SEGURANA A necessidade de ter informaes importantes e disponveis a qualquer momento fez com que os sistemas passassem a operar de forma on-line sendo acessados por grande quantidade de usurios simultaneamente para os mais diversos fins. Com essa expanso, dados e sistemas passaram a ser alvo de pessoas mal intencionadas que procuram e exploram falhas de segurana, geralmente cometidos durante o desenvolvimento do software ou em sua hospedagem. Esse crescimento pode ser visualizado no grfico abaixo:

Figura 1 - CERT.br: Incidentes Reportados e Ataques Acumulados (2011)

Legenda do grfico, ainda de acordo com a Cert.br: Dos (Denial of Service Negao de Servio): notificaes de ataques de negao de servio, onde o atacante utiliza um computador ou um conjunto de computadores para tirar de operao um servio, computador ou rede. Invaso: um ataque bem sucedido que resulte no acesso no autorizado a um computador ou rede. Web: um caso particular de ataque visando especificamente o comprometimento de servidores web ou desfiguraes de pginas na Internet. Scan: notificaes de varreduras em redes de computadores, com o intuito de identificar quais computadores esto ativos e quais servios esto sendo disponibilizados por eles. amplamente utilizado por atacantes para identificar potenciais alvos, pois permite associar possveis vulnerabilidades aos servios habilitados em um computador. Fraude: segundo Houaiss, Qualquer ato ardiloso, enganoso, de m-f, com intuito de lesar ou ludibriar outrem, ou de no cumprir determinado dever; logro. Esta categoria engloba as notificaes de tentativas de fraudes, ou seja, de incidentes em que ocorre uma tentativa de obter vantagem. Outros: notificaes de incidentes que no se enquadram nas categorias anteriores. As invases, ataques e roubo de informaes vem mudando o

comportamento das equipes de desenvolvimento que, cada vez mais, precisam adotar estratgias no momento da codificao e modelagem dos sistemas. preciso pensar no s nas funcionalidades do software, mas tambm nos demais aspectos

que garantem sua segurana a fim de conter ou minimizar tais riscos. Como dito por Bishop (2003) no texto de Fiorio (2007): A segurana de sistemas computacionais visa proteo contra a indisponibilidade, vazamento da informao e a leitura ou modificao no-autorizada das informaes. Alm de garantir dados e informaes, a segurana visa prevenir, detectar, conter e documentar eventuais ameaas aos sistemas computacionais. FIORIO (2007)

Ou seja, necessrio estabelecer aes de preveno e manuteno de ataques no somente para o software propriamente dito, mas tambm para o ambiente operacional que o hospeda. Garantir a integridade de suas informaes durante seu armazenamento e comunicao, monitorar a forma como esses dados trafegam, so armazenados e at mesmo utilizados por seus usurios. Alm de possibilitar a utilizao do sistema sempre que necessrio. O objetivo da segurana em aplicaes manter a confidencialidade, integridade e disponibilidade dos recursos de informao a fim de permitir que as operaes de negcios sejam bem sucedidas. (OWASP, 2010). Desta forma podemos definir: Confidencialidade: No texto de Fiorio, de acordo com Denning (1982), trata-se de permitir o acesso a informaes apenas a pessoas ou usurios autorizados e previamente cadastrados no sistema. A partir do momento em que tais dados so visualizados por pessoas no autorizadas, o sistema tido como no confivel. Integridade: Ainda segundo Denning (1982) no texto de Fiorio, armazenar os dados garantindo que sua forma original foi mantida. Preservar os dados permitindo que estes estejam livres de qualquer tipo de alterao indevida.

Disponibilidade: Refere-se habilidade de usar a informao ou o recurso autorizado desejado. (BRAZ, 2009).

2.1.1 Segurana da informao De acordo com a ABNT NBR (2006), se refere preservao da confidencialidade, integridade e disponibilidade da informao; adicionalmente, outras propriedades, tais como autenticidade, responsabilidade, no repdio e confiabilidade, podem tambm estar envolvidas. Autenticidade: Segundo Hoo (2003) no texto de Braz (2009), significa a validade, conformidade e legitimidade da informao. No repdio: De acordo com Landwehr (2001) no texto de Fiorio (2007), a impossibilidade de negar uma operao ou servio que modificou ou criou uma informao. Tambm podemos citar os conceitos abaixo como itens adicionais para a segurana da informao: Autenticao: Segundo Reami (1998) no texto de Bernardes (1999) referente a identidade de um usurio. Garante que o usurio quem diz ser. Autorizao: Verificao das regras e polticas de acesso para os usurios do sistema. Auditoria: Rastreabilidade dos diversos passos de um negcio ou processo, identificando os participantes, os locais e horrios de cada etapa, de acordo com Laureano (2005). A segurana no est relacionada somente aos itens citados, a poltica de utilizao dos recursos computacionais por seus usurios tambm fazem parte do contexto de segurana da informao. De acordo com Fiorio (2007), o administrador de sistemas necessita tomar decises no s no ambiente computacional, mas tambm precisa estabelecer regras que devem ser repassadas aos seus usurios. A

m preparao, orientao e utilizao dos recursos podem pr em risco todo o planejamento e esforo aplicado nas etapas do desenvolvimento de uma aplicao ou na modelagem de um ambiente apto a garantir a no intruso de indivduos no autorizados. 2.1.2 Incidente de segurana da informao Ainda de acordo com a ABNT NBR (2006), um simples ou uma srie de eventos de segurana da informao indesejados ou inesperados, que tenham uma grande probabilidade de comprometer as operaes do negcio e ameaar a segurana da informao. Ou seja, so aes realizadas por pessoas ou mquinas que podem comprometer a funcionalidade de sistemas, integridade de dados ou ambientes. Segundo a Cert.br temos: um incidente de segurana pode ser definido como qualquer evento adverso, confirmado ou sob suspeita, relacionado segurana de sistemas de computao ou de redes de computadores. 2.1.3 Evento de segurana da informao Uma ocorrncia identificada de um estado de sistema, servio ou rede, indicando uma possvel violao da poltica de segurana da informao ou falha de controles, ou uma situao previamente desconhecida, que possa ser relevante para a segurana da informao. (ABNT NBR, 2006). 2.2 VULNERABILIDADE Pontos desprotegidos que permitem que os ataques sejam realizados, e muitas vezes concretizados, tendo como resultado a invaso de um sistema com ou sem roubo de informaes. Assim como a ISO (1989) no texto de Bernardes (1999), qualquer fraqueza que pode ser explorada para se violar um sistema ou as informaes que ele contm. Tambm de acordo com a Owasp (2010), fragilidade que torna o sistema passvel a um ataque ou dano.

Ou seja, a partir do momento que um sistema ou ambiente possui pontos que podem ser quebrados, suas informaes se tornam, juntamente com o sistema, completamente desprotegidas e expostas. Na viso da Cert.br, a vulnerabilidade vai alm dos pontos fracos vistos de forma isolada, indicando tambm os momentos em que essas falhas foram cometidas, podendo assim ser exploradas. definida como uma falha no projeto, implementao ou configurao de um software ou sistema operacional que, quando explorada por um atacante, resulta na violao da segurana de um computador. (CERT.BR, 2006)

Porm a vulnerabilidade no se d apenas pelo meio lgico do software ou sistema operacional, a invaso ou acesso no autorizado a dados pode ocorrer por meios fsicos ou operacionais atravs da falta de proteo de equipamentos em locais sem restrio de acesso, polticas de segurana que limitam e informam formas de conduta atravs de regras internas, ou o despreparo dos prprios usurios que atravs de comportamento de risco podem expor seu ambiente. Uma vulnerabilidade representa um ponto potencial de falha, ou seja, um elemento relacionado que passvel de ser explorado por alguma ameaa - pode ser um servidor ou um sistema computacional, uma instalao fsica ou, ainda, um usurio ou um gestor de informaes consideradas sensveis. (MARCIANO, 2006)

A deteco e controle das vulnerabilidades de um ambiente ou sistema, quando possvel, deve ser gerenciada de forma gil a fim de evitar que mais ataques sejam realizados a partir das mesmas fragilidades encontradas em um primeiro momento. Os riscos relacionados a tais vulnerabilidades devem ser acompanhados e tratados, assim como sugerido pela ABNT:

10

Deve ser obtida informao em tempo hbil sobre vulnerabilidades tcnicas dos sistemas de informao em uso, avaliada a exposio da organizao a estas

vulnerabilidades e tomadas as medidas apropriadas para lidar com os riscos associados. (ABNT NBR, 2006)

2.3

ATAQUE Tentativa ou investida mal intencionada contra um sistema ou ambiente

computacional, para os mais diversos fins, podendo ser bem ou mal sucedida. De acordo com Bernardes (1999) ataque a realizao de uma ameaa de forma intencional. A capacidade do sistema de impedir que o ataque seja realizado como o planejado pelo atacante vai de acordo com os itens de segurana que foram implementados nele ou em seu ambiente. Contudo, segundo Schell (2001) no texto de Marciano (2006), no h como eliminar os incidentes de segurana de informao, por isso a necessidade da constante vigilncia e verificao. Por este motivo, neste projeto, iremos basear as anlises e solues de vulnerabilidades de cdigo nos critrios abordados e adotados pela Owasp, que mantm seus objetivos na busca e monitoramento de falhas de segurana tendo como resultado um checklist que orienta o desenvolvimento de software seguro. 2.4 MOTIVAO PARA SEGURANA A partir do momento em que informaes corporativas ou pessoais passam a trafegar em um ambiente computacional, sejam elas publicadas de forma intencional ou restritas a um crculo de usurios, algumas medidas devem ser tomadas para que esses dados no sejam usados por pessoas no autorizadas. De acordo com Oliveira (2011), a informao um ativo importante das organizaes e deve ser protegido adequadamente durante todo o seu ciclo de vida: criao, manipulao, armazenamento, transporte e descarte.

11

em busca dessas informaes, sejam elas com valores agregados ou no, que muitos dos ataques so planejados e realizados. O roubo de dados, tentativas de fraudes, invases, ataques, entre outros, vem aumentando consideravelmente. Tratados como incidentes, esses nmeros so reportados a entidades como a Cert.br que os mapeiam dando uma idia da dimenso da importncia da preocupao com a segurana de informao.

Figura 2 - CERT.br (2011)

Referindo-se a sistemas online, uma forma de conseguir acessar e obter dados pela explorao das vulnerabilidades da prpria aplicao hospedada na internet. Tais pontos vulnerveis, na maioria das vezes, so totalmente desconhecidos pelos prprios desenvolvedores que criaram e que mantm o sistema. Por isso a importncia no s de conhecer e corrigir essas falhas, mas tambm de incorporar o hbito de, no momento do desenvolvimento ou manuteno do software, evitar que pontos de fragilidade cheguem a ser publicados juntamente com a aplicao.

12

importante que os desenvolvedores se familiarizem com o assunto e aprendam a se proteger de ataques como SQL Injection, RFI (Remote File Inclusion) e XSS (Cross-site Scripting). Para esses tipos de ataques, o principal que se conscientizem sobre a necessidade de validar os valores recebidos. A maioria dos ataques se aproveita dessa falta de checagem para inserir comandos e at arquivos maliciosos, alerta Cristine. (IDGNOW, 2011)

Mas a preveno e proteo implementadas em um cdigo fonte no pode ser realizada de forma aleatria nem pontual. Mais que um hbito, o desenvolvimento de software seguro tende a ser padronizado, a fim de garantir que todos os pontos de vulnerabilidade estejam de acordo com as regras de padronizao delimitadas para aquele projeto. Como dito pela MSDN (2005), os padres de codificao ajudam os desenvolvedores a evitar a introduo de falhas que podem levar a vulnerabilidades de segurana. Isto tambm leva a uma mudana que comea no inicio do projeto, ainda na fase de anlise e levantamento de requisitos do sistema onde no s seriam relatadas suas funcionalidades, necessidades e exigncias, mas tambm o detalhamento dos pontos onde a segurana dever ser pensada e posteriormente aplicada durante o processo de desenvolvimento da aplicao, resultando em um sistema com menos pontos vulnerveis e menos riscos de ataques concretizados. A necessidade de considerar a segurana "de baixo para cima" um princpio fundamental do desenvolvimento de sistemas seguros. Embora vrios projetos de

desenvolvimento produzam "prximas verses" baseadas nas verses anteriores, a fase de requisitos e o

planejamento inicial de uma nova verso oferecem a melhor oportunidade para criar software seguro. (MSDN, 2005)

13

Esta pesquisa abordar apenas o momento da criao do software, ou seja, seu ponto de desenvolvimento onde muitas das vulnerabilidades passam despercebidas pelos desenvolvedores. analisando e corrigindo os pontos de fragilidade que ser possvel chegar a um checklist de anlise de cdigo, evitando que tais erros sejam explorados por pessoas mal intencionadas. A anlise e criao das regras sero baseadas no Top 10 da Owasp. Consolidao dos dados Segurana Garantir a integridade de suas informaes durante seu armazenamento e comunicao, monitorar a forma como esses dados trafegam, so armazenados e at mesmo utilizados por seus usurios. Segurana da Informao Refere-se integridade e preservao da confidencialidade, autenticidade,

disponibilidade,

responsabilidade, no repdio e confiabilidade da informao. Incidente de segurana da informao Evento de segurana da informao Vulnerabilidade So aes realizadas por pessoas ou mquinas que podem comprometer a funcionalidade de sistemas, integridade de dados ou ambientes. Ocorrncia identificada de possvel falha ou violao de um servio, rede ou sistema que no condiz com as polticas de segurana adotadas. Pontos desprotegidos que permitem que os ataques sejam realizados, e muitas vezes concretizados, tendo como resultado a invaso de um sistema com ou sem roubo de informaes. Ataque Tentativa ou investida mal intencionada contra um sistema ou ambiente computacional, para os mais diversos fins, podendo ser bem ou mal sucedida.

14

Motivao para segurana

Muitos

pontos

vulnerveis

so

totalmente

desconhecidos pelos desenvolvedores que criaram e que mantm o sistema. Por isso a importncia no s de conhecer e corrigir essas falhas, mas tambm de incorporar o hbito de evitar que pontos de fragilidade cheguem a ser publicados juntamente com o sistema.
Tabela 1 - Dados Consolidados

2.5

FERRAMENTAS DE ANLISE ESTTICA DE CDIGO As ferramentas para anlise esttica de cdigo a automatizao que auxilia

a auditoria tcnica do cdigo fonte de uma aplicao. Com a ferramenta, a verificao realizada de forma rpida e sem a necessidade de interveno manual, a final, normalmente um projeto possui inmeras classes e linhas de cdigo, muitas delas sendo alteradas constantemente. 2.5.1 Anlise esttica de cdigo Segundo a BSTQB (2007), um tipo de teste ou exame que pode ser realizado sem executar o cdigo. Ou seja, possvel realizar testes antes mesmo de disponibilizar ou instalar a aplicao em qualquer ambiente. Vale lembrar que estes testes no identificam erros de regras de negcio ou no conformidade com o projeto. A verificao por buscas de erros de cdigos ou padres previamente definidos. Segundo Teixeira (2007), consiste em uma verificao automtica do cdigo fonte, normalmente em tempo de compilao. Essa verificao feitas por ferramentas que automatizam a validao dos cdigos fontes. A importncia de utiliz-la destacada pela MSDN (2005), as ferramentas podem detectar alguns tipos de falhas de cdigo que resultam em vulnerabilidades. No momento da anlise a ferramenta pode avaliar se expresses usadas so capazes de por em risco a aplicao ou se a codificao est de acordo com as regras definidas para o projeto. De acordo com a BSTQB:

15

Os

padres

de

codificao

cobrem

tanto

aspectos

arquiteturais quanto o uso (ou proibio do uso) de algumas estruturas de programao. A conformidade com os padres de codificao permite que o software seja mais passvel de manuteno e teste. Requisitos especficos da linguagem podem tambm ser verificados usando teste esttico. (BSTQB, 2007)

Muitas das ferramentas de automatizao so compatveis com as mais diversas IDEs, facilitando o processo de desenvolvimento da aplicao atravs da instalao de plugins que incorporam suas funcionalidades Atualmente existem diversas delas disponveis no mercado, algumas so: PMD, Checkstyle e Findbugs, ESC/Java 2, Jlint, Klocwork Developer, Qj-Pro, entre outras. 2.5.2 PMD De acordo com a Source Forge, fabricante da ferramenta, ela procura por erros cometidos durante a codificao que, na maioria das vezes, s so detectados em modo de execuo e acabam no sendo notados sequer pelo compilador do Java ou pelo prprio programador. A busca realizada pela ferramenta previamente definida por ela sendo capaz de identificar duplicidades de cdigo, expresses aninhadas desnecessrias, cdigo morto (variveis, mtodos, constantes no referenciados), entre outros. Mas tambm possvel incluir novos tipos de buscas especficas de acordo com a necessidade do projeto atravs de plugins da ferramenta que disponibilizam telas para facilitar a criao e gerenciamento das novas ou j existentes regras. O PMD tambm pode ser utilizado para induzir a padronizao de cdigo em ambiente de desenvolvimento ajudando na validao do cdigo fonte ainda durante o trabalho do desenvolvedor. As regras e padronizaes podem ser especificadas como novos itens de validao. Estas regras, sejam para busca de novos bugs ou

16

para padronizao de cdigo, podem ser desenvolvidas de acordo com a necessidade do projeto atravs de classes Java ou por meio declarativo, o XPath. XPath: De acordo com a W3C(1999), XPath uma linguagem de endereamento de documentos XML que age por estrutura e no por sintaxe. A navegao por esta estrutura hierrquica dada por notao de caminhos em forma de URLs. A linguagem modela o documento no formato XML como uma rvore de ns, nas quais so divididos em diferentes tipos: ns de elementos, ns de textos e ns de atributos que permitem a manipulao de strings, nmeros e booleanos por meio de expresses que a construo sinttica primria do XPath. Relatrios: Ao final da validao, realizada de forma esttica, emitido um relatrio informando os problemas detectados e visualizados nos formatos: texto, XML, HTML e niceHtml. Integraes: Ainda segundo a Source Forge, o PMD possui integrao com JDeveloper, Eclipse, JEdit, JBuilder, BlueJ, CodeGuide, NetBeans/Sun Java Studio Enterprise/Creator, IntelliJ IDEA, TextPad, Maven, Ant, Gel, JCreator, e Emacs. 2.5.3 Checkstyle Segundo a Checkstyle (2011), uma ferramenta que ajuda o desenvolvedor a manter um padro de desenvolvimento de cdigo escrito na linguagem Java. Automatizando o processo de verificao do cdigo fonte e evitando que isto seja feito de forma manual. Assim como o PMD, esta ferramenta tambm capaz de identificar cdigos duplicados e padres de erros. 2.5.4 Findbugs Assim como o PMD e o Checkstyle, o Findbugs uma ferramenta de anlise esttica de cdigo escrita em linguagem Java. Segundo Foster (2004), o FindBugs reporta mais de 250 padres de erros. A ferramenta tambm permite que sejam definas suas prprias regras de verificao.

17

2.5.5 Ferramenta escolhida A Ferramenta PMD foi escolhida para este projeto por mostrar uma boa apresentao e fcil forma de uso, tanto para o desenvolvedor que ir utiliz-la como usurio final, quanto para a equipe responsvel por criar e manter novas regas. Pode ser utilizada como um leve plugin em conjunto com o Eclipse (entre outras IDEs), na qual ambas interagem sem problemas. 2.6 OWASP Open Web Application Security Project Organizao aberta focada em promover a segurana em aplicaes web fazendo com que se tornem softwares seguros. Segundo a prpria OWASP, o site hospeda de forma aberta projetos, fruns, blogs, apresentaes, ferramentas e artigos. O contedo do site voltado para a segurana de software seguro em plataforma web, nas diversas fases de seu desenvolvimento, indicando vulnerabilidades, correes, boas prticas de

programao, tecnologias, alm de promover eventos. Atualmente, a OWASP est distribuda em mais de 70 grupos espalhados pelo mundo na qual cada um deles ajuda a expandir e difundir o uso das boas prticas como forma de preveno e/ou correo aos ataques de softwares atravs da web. 2.6.1 Top 10 Lista das 10 vulnerabilidades mais comuns encontradas nos softwares em plataforma web. Tambm so propostos mtodos de proteo dessas aplicaes. Para a lista completa de vulnerabilidades, preciso acessar o Guia OWASP na qual possui mais de 300 itens que podem por uma aplicao em risco. A lista Top 10 utilizada neste projeto foi publicada em 2010, por ser a mais recente. possvel que, no futuro, esta lista mude a exemplo a Top 10, ano 2007. Dentre os 10 tpicos abordados pela OWASP, alguns no sero estudados neste projeto por no serem diretamente relacionados ao processo de codificao

18

de desenvolvimento de software. Veremos a seguir a definio de cada um dos tpicos definidos pela Owasp: 2.6.1.1 Tpicos estudados nesta pesquisa A1 Injection: Informaes enviadas como parte de uma query que podem executar comandos indevidos ou dar acesso no autorizado. Podem ser do tipo SQL, SO ou LDAP. Preveno: utilizar scape de cdigo, statement invs de referncia direta de parmetro, white list para evitar certos caracteres de entrada. A2 Cross site scripting (xss): Envio de dados indevidos sem qualquer tipo validao em forma de scripts que podem ser executados pelos navegadores dos usurios que acessam essas informaes. Preveno: No permitir a incluso de scripts que podem ser executados. Ex.: javascript. A3 Broken authentication and session management: A falta de gerenciamento da sesso do usurio permite que ocorra roubo de identidade, transformando invasores em usurios vlidos. Preveno: No utilizar passagem de parmetro diretamente na URL. Enviar dados encriptados inclusive na sesso do usurio. Verificar a validade da sesso do usurio para evitar que usurios no autenticados sejam considerados vlidos no sistema. A4 Insecure Direct Object References: Acesso direto a referencia de objetos tais como arquivos, diretrios ou informaes de acesso a banco de dados expem dados que podem ser manipulados por pessoas no autorizadas. Preveno: No utilizar referencia direta de parmetro em objetos, principalmente quando eles fazem qualquer tipo de execuo, query sql

19

por exemplo. Verificar se a origem da requisio tem autorizao para aquele tipo de acesso ao objeto requisitado. A5 Cross-site Request Forgery: Envio de informaes de um usurio autenticado para endereos externos. Envio de requests para a prpria aplicao, porm forjando dados de um usurio vlido. Preveno: Utilizar tokens dinmicos durante a transao. Verificar a origem da requisio. A8 Failure to restrict URL access: Verificao da url apenas nas pginas principais da aplicao implica em acesso indevido as pginas internas que no passam por validao de endereo no momento de seu acesso. Preveno: Verificar a autorizao de acesso do usurio em cada pgina do sistema (poltica de acesso), independente se ele estiver autenticado ou no. A9 Insufficient transport layer connection: Falha na proteo dos dados no momento de seu envio atravs de requisies HTML. necessrio garantir a confidencialidade das informaes. Preveno: Utilizao do recurso SSL a partir do momento da autenticao do usurio e em todas suas transaes. A10 Unvalidated redirects and forwards: Redirecionamento dos usurios de um sistema para sites fora de seu ambiente, uma vez que tais redirecionamentos so realizados sem validaes. Preveno: Validar a permisso do usurio para fazer redirects e forwards.

20

2.6.1.2 Tpicos no contemplados nesta pesquisa Os itens abaixo no esto diretamente ligados codificao/desenvolvimento de software, por isso no sero abordados nesta pesquisa. A6 Security misconfiguration: Configurao de segurana deve ser definida para o ambiente responsvel pela aplicao. Framework, servidores de dados e aplicao devem ser controlados tanto em termos de controle de acesso e atualizaes. A7 Insecure cryptographic storage: Segurana no armazenamento e acesso aos dados da aplicao. Utilizao de encriptao e hashs para dados sensveis e sigilosos.

21

3 ESTUDO DE CASO

Antes de definir as regras que devem ser seguidas, preciso identificar as possveis vulnerabilidades. Neste projeto vamos tomar como referencia o Top 10 da Owasp, assim como dito anteriormente. A princpio, se baseando no primeiro item do Top 10 (Injection) e usando um cdigo fonte de exemplo, podemos analisar o trecho abaixo que representa um risco iminente a aplicaes em plataforma web:
(...) cpf = request.getParameter("cpf");

Cliente cliente = fachada.buscarCliente(cpf); (...)

No h forma alguma de validao quanto ao tipo de informao ou caracteres que so permitidos para o campo em questo que est sendo recuperado atravs da instruo getParameter. O usurio pode enviar qualquer contedo e, no entanto, a aplicao ir aceitar com total confiana, envi-la a outras classes ou diretamente ao banco de dados. Para evitar que dados sejam recuperados sem que passem pelas devidas validaes definidas para cada tipo de campo, possvel simplesmente impedir que instrues dessa natureza sejam utilizadas

aleatoriamente e de forma insegura em todo o projeto. Partindo do princpio que a utilizao do getParameter deve ser evitada para impedir a possvel insero de determinados caracteres, podemos definir uma regra para que sempre que a instruo for usada ela ser sinalizada, seja como erro ou warning. A severidade da sinalizao da regra pela ferramenta deve ser definida de acordo com os riscos que a instruo em questo oferece a aplicao. Neste caso vamos apresent-la como um erro, uma vez que o recebimento indevido de dados pode trazer conseqncias danosas aplicao.

22

3.1

REGRAS DO PROJETO Com as definies j estabelecidas e utilizando a ferramenta PMD, podemos

criar a regra para o seguinte modelo de cdigo fonte, que representa a situao que queremos prever e evitar:
public class LoginServlet extends HttpServlet{ protected void doPost(HttpServletRequest request, HttpServletResponse response){ String nome = request.getParameter("login"); }}

O objetivo identificar a expresso request.getParameter sendo o item que a ferramenta dever identificar e sinalizar, independente de passagem de parmetro na qual a instruo ir receber. A ferramenta PMD disponibiliza em seu plugin um facilitador que ajuda na criao de novas regras. Trata-se de uma tela simples e intuitiva, o PMD Rule Designer. Nesta tela temos quatro reas: Source Code: Local onde o cdigo fonte com o problema em questo para a criao da regra deve ser inserido.

Figura 3 - Source Code PMD

23

Abstract Syntax Tree/Symbol Table: rvore gerada automaticamente pelo Rule Designer baseado no cdigo inserido no quadro Source Code. a partir dela que a regra ser criada.

Figura 4 - Sintax Tree PMD

Xpath Query: Regra escrita pelo usurio, baseada na anlise do quadro Abstract Syntax (Figura 4).

Figura 5 - XPath PMD

Quadro de Resposta: rea localizada na parte direita inferior da tela (imagem abaixo), usada pelo usurio durante a gerao da regra. Nele possvel testar se a regra criada est funcionando e identificando os itens no cdigo fonte do quadro Source Code. No caso da imagem abaixo, podemos perceber que o Rule Designer conseguiu traduzir a regra e identificar na linha 5, coluna 23 a instruo referida na rea com o cdigo fonte.

Figura 6 - Quadro de Resposta PMD

24

Com a anlise da rvore XPath (Figura 4) gerada pela prpria ferramenta, e a partir do cdigo fonte com a origem do problema que queremos atacar, foi possvel escrever a regra a seguir: //PrimaryExpression[PrimaryPrefix/Name[contains(@Image,'.getParameter')]]

Com a regra escrita e testada ainda no PMD Rule Designer, o prximo passo registr-la no plugin do PMD. neste passo que iremos definir seu nome, as mensagens que sero visualizadas pelo desenvolvedor, a severidade da regra que ser exibida para o desenvolvedor (erro, warning, etc) e o exemplo que ele dever seguir. Como mostra a imagem abaixo:

Figura 7 - PMD Plugin

25

Aps seu cadastro no PMD, podemos visualizar na tela Rule Configuration a nova regra criada e nomeada como NaoUtilizarGetParameter, alm das j existentes (originais) da prpria ferramenta, sendo possvel alter-las ou exclu-las a qualquer momento. Tambm nesta mesma tela que o usurio tem acesso ao Rule Plugin e ao Rule Designer. Ver imagem abaixo:

Figura 8 - Rules Configuration

A tela d a possibilidade de utilizar outras configuraes disponibilizadas pela ferramenta, acessando as propriedades do projeto, na opo PMD. Neste local possvel visualizar todas as regras (novas e j existentes) alm de escolher quais delas estaro disponveis e/ou ativas para a anlise esttica da ferramenta. No momento em que o PMD estiver varrendo o cdigo fonte do projeto em busca de no conformidade, as regras que no estiverem selecionadas sero totalmente ignoradas. Nesta monografia, para que outras regras no interfiram no resultado final do trabalho, apenas as regras criadas para esta pesquisa ficaro ativas. Como podemos perceber na imagem abaixo, todas as outras regras foram desmarcadas, e apenas a NoUtilizarGetParameter est ativa.

26

Figura 9 - Properties PMD

O PMD d ainda a opo da gerao de arquivos onde so agrupadas todas as regras, tanto novas quanto j existentes. Esses arquivos so de extenso XML e so denominadas como ruleset. Nele, cada regra deve ser declarada manualmente, assim como as mensagens que sero apresentadas para os desenvolvedores, a severidade da regra, os exemplos e tambm a referencia para os arquivos HTML que sero utilizados pelos relatrios. Como podemos ver na imagem acima, h o item Use the ruleset configured in a Project file, onde deve ser indicado o local onde a ruleset, ou seja, o arquivo XML, com todas as regras est localizado. Caso esta opo de gerao das regras seja escolhida, a tela equivalente a imagem PMD Plugin no ser utilizada para o cadastramento da regra. Assim como as regras no sero visualizadas nas telas que equivalem s imagens Rule Confiiguration e Properties PMD. A vantagem de utilizar a ruleset a facilidade no momento da distribuio e manuteno das regras, precisando apenas disponibilizar o arquivo para que os desenvolvedores atualizem em seus ambientes. Nesta monografia a opo ruleset no foi utilizada pela no necessidade de distribuio das regras, foi utilizada apenas a forma de cadastro das regras pelas telas disponibilizadas pela prpria ferramenta atravs de seu plugin interagindo com o Eclipse. 3.2 VALIDAO DAS REGRAS Com todos os passos de anlise do problema, definio e criao das regras e configurao da ferramenta j concluda, podemos fazer o teste de validao no projeto, seja ele novo ou em andamento. Com o projeto aberto, o plugin disponibiliza

27

no menu do Eclipse uma opo para o PMD realizar sua anlise atravs da opo Check Code With PMD. Imagem abaixo:

Figura 10 - Menu PMD

A opo de menu responsvel pela checagem do projeto exibida na imagem acima identificar a regra ativa na ferramenta e varrer a instruo em questo no cdigo fonte do projeto. Quando encontrada, causa a seguinte indicao no Eclipse:

Figura 11 - Sinalizao PMD

Podemos perceber que a linha onde h o getParameter tratada como um erro, impedindo a completa compilao do projeto. Na aba Violations Outline, sob a perspectiva PMD, exibida a mensagem No utilizar getParameter diretamente nas classes do projeto que tambm foi definida no momento da criao desta regra no PMD. Ou seja, no momento em que esta expresso for utilizada pelo desenvolvedor,

28

a reao da ferramenta ser sempre a indicao de um erro em qualquer parte do projeto. Sob a perspectiva Java, o indicativo de erro apresentado da seguinte forma na aba Problems do Eclipse:

Figura 12 - Sinalizao Java

Alm de criar regras para evitar a utilizao de certas instrues, tambm necessrio criar mecanismos que possibilitem a utilizao alternativa dos itens proibidos, porm, de forma segura e controlada. Neste caso, foi gerada uma classe centralizadora responsvel por recuperar, validar dados vindos do request e devolver apenas informaes limpas que podem ser processadas pela aplicao ou utilizadas pelo banco de dados. A referncia, a partir da servlet no mtodo doPost, para a nova instruo responsvel por recuperar dados de formulrios ou parmetros trazidos por um request ficaria da seguinte forma:

29

Figura 13 - Chamada para validar dados

Assim

programador

ser

induzido

utilizar

somente

funo

verificaRequestCliente para recebimento de dados provenientes de formulrios web na qual foi previamente escrita e disponibilizada e onde j estariam todas as validaes necessrias, diminuindo os riscos com codificao insegura e padronizando os projetos para que todos sejam atendidos pelos mesmos critrios de segurana. O mtodo verificaRequestCliente, que est sendo chamado pela fachada do projeto na imagem anterior, equivalente ao mtodo dadosRequest pertencente a classe responsvel por centralizar todas as validaes e tratamentos provenientes de formulrios. Na imagem abaixo que exibe parte da classe em questo, podemos ver que no campo CPF, que est sendo recuperado do request, existe a validao que retira qualquer caractere que no seja numrico. Evitado que possveis tentativas de injeo de script sejam finalizadas. Depois de tratada e validada, a informao retorna para sua chamada de origem para ser utilizada pelo sistema.

Figura 14 - Mtodo dadosRequest

30

Tambm possvel perceber que a expresso getParameter do mtodo dadosRequest no est sendo sinalizada pela ferramenta PMD como um erro, ao at ento comum em outras reas do projeto. Isto ocorre porque essa expresso est sendo utilizada atravs de uma biblioteca jar configurada no build path do projeto java. O gerenciamento das validaes por meio de um projeto independente e integrado a todos os outros por bibliotecas jar torna a manuteno e atualizao facilitada, uma vez que bastaria comunicar a todas as equipes a necessidade de sua atualizao sempre que houvesse mudana nessas classes, seja para adio de novas funes, campos, ou at mesmo para incremento de rotinas de validao. Como podemos ver na imagem abaixo, temos a biblioteca validaDados_1.0.jar que foi gerada a partir da classe centralizadora e que deve conter todas as validaes necessrias e pertinentes a anlise de dados.

Figura 15 - Propriedade do Projeto

Esta biblioteca dever ser adotada como obrigatria em todos os projetos em desenvolvimento para que a padronizao seja devidamente seguida. 3.3 RELATRIOS A visualizao, atravs de relatrios em HTML, de todas as ocorrncias de no conformidade encontradas pelo PMD mais uma das funcionalidades da ferramenta. Nesta pgina padro temos informaes referentes ao nmero de todas

31

as no-conformidades detectadas; a classe Java em que a no conformidade foi usada, e a linha onde a instruo foi encontrada com o problema atribudo a ele. Este relatrio uma das formas de informar ao programador onde esto os problemas do projeto e como resolv-los por utilizao de codificao segura e padronizada.

Figura 16 - Relatrio PMD

A ferramenta tambm d a opo de criar pginas HTML adicionais onde podemos mostrar exemplos de codificao segura de forma mais detalhada aos desenvolvedores. No momento da criao da regra NoUtilizarGetParameter, utilizando a tela PMD Plugin (ver Figura 7 - PMD Plugin), foi possvel indicar no campo External Info URL a pgina HTML que dar apoio ao desenvolvedor e que seu link exibido no relatrio padro da ferramenta, podendo ser facilmente acessada. Podemos visualizar este item na imagem acima (Figura 16) sendo equivalente a coluna Problem. Ao clicar neste link, teremos:

Figura 17 - Relatrio Adicional PMD

32

Esta nova pgina HTML no um item obrigatrio durante o processo de criao da regra pelo plugin do PMD, mas poder auxiliar o desenvolvedor na visualizao dos problemas detectados no projeto por meio de viso geral. Esta pgina pode receber qualquer layout definido pela equipe responsvel pela sua gerao. Neste caso especfico, foi indicado apenas o motivo da noconformidade encontrada alm da nova maneira de utilizao, sendo esta sua forma segura. 3.4 OUTRAS REGRAS Seguindo os mesmo procedimentos para criao de novas regras e ainda utilizando o primeiro item (Injection) do Top 10 da Owasp, podemos desenvolver mais uma regra para a seguinte situao de risco: String sql = ; sql = "select nome from cliente where cpf =" + request.getParameter("cpf"); ResultSet resultado = statement.executeQuery(sql); return resultado;

No cdigo acima vemos dois problemas em potencial, o primeiro a concatenao do parmetro proveniente do request diretamente na varivel que compe a query que ser executada pelo banco de dados atravs da expresso executeQuery(string). O segundo problema a falta de validao do valor recuperado do request, na qual j temos o tratamento para essa situao na regra NaoUtilizarGetparameter. Vale mencionar que o cdigo acima pode conter a seguinte variao: sql = "select nome from cliente where cpf =".concat(request.getParameter("cpf"));

33

Essa nova anlise seguir os passos j descritos na sesso: Criar Regras para o Projeto que mostra algumas das funcionalidades do PMD. Referente nova regra, ns podemos definir que: no permitiremos a utilizao de concatenaes de valores e variveis em queries SQL. Assim temos: //Expression/AdditiveExpression[(@Image='+' and count(//ClassOrInterfaceType[contains(@Image,'ResultSet')]) > 0)] | //PrimaryExpression/PrimarySuffix[(@Image='concat' and count(//ClassOrInterfaceType[contains(@Image,'ResultSet')]) > 0)]

A regra acima no permitir a concatenao de valores seja pelo uso do caractere + ou pela instruo concat atravs das informaes: @Image='+' e @Image='concat desde que no estejam em uma classe do tipo ResultSet indicado por: count(//ClassOrInterfaceType[contains(@Image,'ResultSet')]) > 0)]. Como dito, o PMD passar a identificar a concatenao apenas nas classes do tipo Resultset como um erro, impedindo a compilao do projeto, como mostra a imagem abaixo:

Figura 18 - Concatenao em classe ResultSet

A delimitao da regra procura de concatenaes somente em classes do tipo ResultSet d a possibilidade do desenvolvedor utilizar a concatenao de valores e variveis em qualquer outra parte do projeto, sem prejuzo quanto ao seu

34

manuseio. Aps essa definio, indicaremos a seguinte forma alternativa para utilizao pelos desenvolvedores:

Figura 19 - Mtodo fazerConsulta

A classe fazerConsulta referenciada pelo trecho abaixo, que, inclusive, j detm a resoluo quanto validao dos dados recuperados do formulrio e que j foi demonstrado na Figura 13.

Figura 20 - Chamada para realizar consulta de dados

Observando os cdigos acima, vemos a possibilidade de ligao com o quarto item do Top 10 da Owasp: Insecure Direct Obeject Reference. Essa proposta de soluo evitar a referncia direta ao objeto, que no nosso caso se traduz pela expresso request.getParameter("cpf"). Indiretamente tambm estamos evitando a expresso executeQuery(string), que deixar de ser utilizada j que ela necessita de uma string equivalente a varivel query, a ser executada no banco de dados. Porm, para garantirmos que essa expresso no seja escrita em nenhuma outra parte do projeto, podemos criar mais uma regra:

35

//PrimaryExpression [ (PrimaryPrefix/Name[contains(@Image,'executeQuery')]) ] //PrimarySuffix/Arguments[@ArgumentCount=1]

A regra acima ser responsvel por sinalizar na IDE, atravs do plugin do PMD, a presena da instruo executeQuery(string), desde que haja passagem de parmetro, em qualquer classe da aplicao. Ainda na regra acima, a linha responsvel por identificar se a expresso utilizada possui passagem de parmetro : //PrimarySuffix/Arguments[@ArgumentCount=1]. Ou seja, o desenvolvedor ainda poder fazer uso desta expresso (sem parmetro) assim como indicada na Figura 19. A sinalizao da regra na IDE ficar da seguinte forma:

Figura 21 - Expresso executeQuery utilizada com parmetro

At o momento foram criadas trs regras que abrangeram dois itens (Injection e Insecure Direct Obeject Reference) do Top 10 da Owasp. Os outros itens do Top 10, por falta de tempo hbil, no foram abordados e suas regras no foram criadas nessa pesquisa. Porm foi realizado estudo em cada um deles e h viabilidade tcnica das regras serem feitas e incorporadas normalmente a um projeto, como demonstrado neste captulo.

36

4 CONSIDERAES FINAIS

No prottipo utilizado para exemplificar vulnerabilidades, analisar solues e construir as regras citadas no captulo anterior, possvel fazer um quantitativo apenas isolando as classes relacionadas entidade Cliente, para que possamos compreender os resultados da adoo da prtica de padronizao de cdigo de forma proporcional. Para isso temos os seguintes nmeros (quantidade): Pacotes: 3 Classes: 11 Linhas: 490 (estimativa) Bibliotecas prprias: 2 Dessas 11 classes relacionadas entidade Cliente, trs so do tipo Servlet, que recebem os dados vindos de pginas normalmente preenchidas por usurios. Estas classes foram o alvo de nosso estudo por serem a entrada de dados na aplicao e por serem diretamente afetadas pela falta de tratamento quanto as suas vulnerabilidades. Seja por no tratar os dados, no verificar os redirecionamentos ou por permitir certas instrues, elas afetam indiretamente outras partes da aplicao como, por exemplo, a camada responsvel por interagir com a base de dados ou, dependendo do objetivo da aplicao, executar certas instrues diretamente em seu ambiente de hospedagem. Ao adotar a padronizao de cdigo baseada nas vulnerabilidades de segurana neste projeto, impedimos certos vcios de codificao e controlamos o uso de instrues consideradas de risco, assim diminumos as possibilidades de ataques serem concretizados e, conseqentemente, trouxemos para aplicao mais valor e confiabilidade uma vez que suas informaes esto protegidas. Podemos identificar essas caractersticas na regra NaoUtilizarGetParameter que, nesta pesquisa, est destinada apenas verificao dos dados de login do cliente. Expandindo a rea de atuao desta regra para uma aplicao de grande porte e complexidade, esta regra, ainda assim, ser adotada por toda e qualquer

37

classe do projeto que utilize a expresso getParameter, uma vez que o PMD impedir automaticamente a compilao da classe. Observando o impacto da padronizao aps o trmino da anlise da ferramenta sobre todas as regras criadas at o momento, ela indicar a quantidade de no conformidade encontrada na aplicao (visualizar Figura 12 e Figura 16). Considerando que no captulo anterior estudamos uma simples tela de login com os campos CPF e senha, temos como impacto apenas duas classes e - pelo menos quatro linhas sofrendo indicao de erro pelo PMD. Uma das classes afetadas a servlet que recebe diretamente da tela os dados dos dois campos e a outra responsvel por realizar a consulta no banco de dados. Mais uma vez expandindo o contexto para uma aplicao de grande porte e complexidade, e utilizando a mesma proporo, veremos a multiplicao significativa da quantidade de violaes informadas pelo PMD. Se para cada tela do projeto da pesquisa tivermos duas classes e quatro linhas afetadas, em uma aplicao com 10 telas podemos estimar uma variao de 20 classes e 40 linhas com indicativos de vulnerabilidades reais. Lembrando que, at o momento, temos apenas trs regras criadas abrangendo o item nmero um e o item nmero quatro do Top 10 da Owasp. Ou seja, esses nmeros podem ser ainda maiores. A descoberta de vulnerabilidades em uma aplicao demanda no somente tempo, mas tambm experincia da equipe responsvel por tratar dessas questes. Se por um lado teremos uma menor probabilidade de ataques bem sucedidos e um melhor aproveitamento de boas prticas de programao, por outro lado ser necessrio demandar tempo extra para o estudo dos pontos fracos e suas solues, o que pode ser iniciado ainda no levantamento de requisitos do projeto. Todo esse tempo extra, que foi seguido e realizado nesta pesquisa a partir do captulo trs, foi preenchido com as atividades listadas abaixo e que podem fazer parte do novo processo de modelagem e desenvolvimento de software que inclui a premissa segurana: Anlise das vulnerabilidades; Definio das regras;

38

Criao das regras na ferramenta PMD; Codificao de funes seguras como item de padronizao (citado no captulo anterior como cdigo alternativo);

Gerao de documentao de apoio para o desenvolvedor (relatrios do PMD, por exemplo);

Montagem e disponibilizao de bibliotecas prprias; Atualizaes, sempre que necessrio, dos itens desenvolvidos em todos esses passos. A garantia da utilizao das regras da ferramenta de anlise esttica de

cdigo precisa ir alm do ambiente de desenvolvimento. necessrio que haja um controle no deploy da aplicao, permitindo que apenas os que esto dentro dos padres estabelecidos sejam instalados e liberados para outros ambientes. 4.1 EVOLUO DO TRABALHO Como evoluo deste trabalho, proponho: Construir regras para os outros itens do Top 10 da Owasp. Construir casos de testes voltados para segurana de software, para serem aplicados nas regras criadas no PMD. Utilizao das tcnicas de Pontos de Funo para verificar o nvel de segurana (ou insegurana) da aplicao, baseado no resultado relatado pela anlise das regras no PMD. 4.2 CONCLUSO Com todos os critrios abordados nesta pesquisa, podemos observar que a preocupao com a segurana da informao rene diversas etapas e atores, sendo para mais ou para menos, de acordo com o que se quer proteger. Durante o desenvolvimento de um software tido como seguro, no diferente. Os inmeros fatores que impulsionam a preocupao com a segurana de software servem como

39

motivao para o aperfeioamento no s dos softwares e dos processos de desenvolvimento, mas tambm profissional, uma vez que a busca por solues requer investimento e aprendizado. O reconhecimento dos pontos fracos da aplicao, as solues encontradas, a tomada de deciso (de tudo que deve ser banido ou mantido na estrutura do software) e a novas posturas nos hbitos profissionais quanto segurana de software so temas abordados por grupos e organizaes que discutem, estudam e divulgam seus resultados de forma completamente aberto para sejam adotados por profissionais e empresas interessadas em ter a segurana como item permanente em seus processos. Essas organizaes, como a Owasp, por exemplo, mostram em seus os resultados que a melhoria na proteo, no s dos dados que trafegam, mas da aplicao em si, alm de essencial tambm o retorno de todo esforo realizado durante seu processo de anlise e desenvolvimento. A adoo de tcnicas de padronizao e anlise esttica de cdigo uma forma j bem difundida, inclusive por grandes organizaes, para o aperfeioamento da escrita de cdigo fonte uma vez que a anlise esttica vista como uma maneira eficiente e rpida de auditoria quando se trata de expresses e caractersticas de lgica e linguagem de programao. A juno da padronizao (e ferramentas de anlise esttica de cdigo) com a abordagem especifica para segurana de software pode ser usada para garantir uma maior eficincia no controle daquilo que est sendo liberado para os usurios e exigindo que todos os critrios de segurana adotados sejam seguidos, independente se a aplicao lida com dados crticos ou no, pelo visto que cada vez mais informaes tendem a permanecer online. Com este critrio, pode-se afirmar que a adoo de medidas de segurana e a integrao com aspectos de padronizao garantem mais credibilidade e valor ao sistema por que h a preocupao real com o sigilo e segurana dos dados dos usurios, mesmo admitindo que o esforo adicional para aplicar essa juno significa ter equipe especializada, tempo extra para anlise e desenvolvimentos das regras e, conseqentemente, um maior (e permanente) investimento monetrio.

40

REFERNCIAS

ABNT NBR. Norma Brasileira. ABNT NBR ISSO/IEC 27001, 2006. Disponvel em: http://cercopdf.com/visualizza/aHR0cDovL3d3dy5yZW5hdG9kYWNvc3RhLm5ldC8y NzAwMS5wZGY= Acesso em: 28/08/2011. BERNARDES, Mauro Cesar. Avaliao do uso de agentes mveis em segurana computacional. Instituto de cincias matemticas e computacionais. 1999. BRAZ, Fabrcio Ataides. Instrumentalizao da anlise e projeto de software seguro baseada em ameaas e padres. Departamento de Engenharia Eltrica, Universidade de Braslia, Braslia, 2009. BSTQB. Gesto de Segurana da Informao. 2007. Disponvel Acessado em: em

http://pt.scribd.com/doc/55801742/66/Analise-Estatica-do-Codigo 06/11/2011. CERT.br. Incidentes Reportados ao CERT.br. 2011.

Disponvel

em:

http://www.cert.br/stats/incidentes/2011-jul-sep/tipos-ataque-acumulado.html Acesso em 06/11/2011. CERT.br. Estatsticas dos Incidentes Reportados ao CERT.br. 2011. Disponvel em: http://www.cert.br/stats/incidentes/ Acesso em 06/11/2011. CERT.br. Crimes pela Internet: Aspectos Tcnicos. 2009. Disponvel em: http://www.cert.br/docs/palestras/certbr-abranet-icann2009.pdf 06/11/2011. CERT.br. Cartilha de Segurana para Internet. Parte I: Conceitos de Segurana. 2006. Disponvel em: http://cartilha.cert.br/download/cartilha-01-conceitos.pdf Acesso em: 06/11/2011. CERT.br. Cartilha de Segurana para Internet. Parte II: Riscos Envolvidos no Uso da Internet e Mtodos de Preveno. 2006. Disponvel em: Acesso em

http://cartilha.cert.br/download/cartilha-02-prevencao.pdf Acesso em: 06/11/2011.

41

CERT.br. Cartilha de Segurana para Internet. Parte IV: Fraudes na Internet. 2006. Disponvel em: http://cartilha.cert.br/download/cartilha-02-prevencao.pdf

Acesso em: 06/11/2011. DENNING, D. (1982). Criptography and data security, Addison-Wesley. FIORIO, Milene. EMMANOEL, Carlo. PIRES, Paulo. DELICATO, Flvia. Solues para o desenvolvimento de sistemas seguros. In: VII Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais. 2007. IDGNOW. Ataques crescem quase 300% na internet brasileira. 2011. Disponvel em: http://idgnow.uol.com.br/seguranca/2011/07/14/ataques-crescem-quase-300-nainternet-brasileira/ Acesso em: 28/08/2011. LAUREANO, Marcos Aurlio. MORAES, Paulo Eduardo Sobreira. Segurana como estratgia de gesto da informao. In: Revista Economia & Tecnologia, Volume &, Fascculo 3, pgina 38-44, 2005. MARCIANO, Joo Luiz Pereira. Segurana da Informao Uma abordagem social. 2006. Braslia. Disponvel em:

http://repositorio.bce.unb.br/bitstream/10482/1943/1/Jo%C3%A3o%20Luiz%20Pereir a%20Marciano.pdf Acesso em: 06/11/2011. MSDN. LIPNER, Steve. HOWARD, Michael. O ciclo de vida do desenvolvimento da segurana de computao confivel. 2005. Disponvel em

http://msdn.microsoft.com/pt-br/library/ms995349.aspx. Acesso em: dia/ms/ano.

OLIVEIRA, Salomo. Normas e Polticas de Segurana da Informao. Centro Universitrio Radial Estcio. So Paulo. 2011. OWASP. Melhores Prticas de Codificao Segura OWASP - Guia de Referncia Rpida. 2010. Disponvel em:

https://www.owasp.org/images/e/e2/OWASP_SCP_Quick_Reference_PTBR_v1.0.pdf Acesso em: 28/08/2011. W3C. W3C Recommendation. XML Path Language (XPath) Version 1.0. 1999. Disponvel em: http://www.w3.org/TR/xpath/ Acesso em: 08/10/2011.