FACNET Faculdade de Negcios e Tecnologias da Informao SESLA Sociedade de Ensino Superior do Lago Curso de Bacharelado em Sistemas da Informao Disciplina: Desenvolvimento de Software Seguro Turma: BSI 5AD Professora Mestre: Leandro Vaguetti

ATPS Etapas 1, 2, 3, 4 e 5

Daniel Rodrigues Araujo Priscila Nunes da Silva Rafael Santos Caduda Thiago Farias Da Silva

Braslia, 06 de Dezembro de 2011.

ATPS Etapas 1, 2, 3, 4 e 5

Daniel Rodrigues Araujo Priscila Nunes da Silva Rafael Santos Caduda Thiago Farias Da Silva

Professor Mestrado: Leandro Vaguetti Desenvolvimento de Software Seguro

FACNET Faculdade de Negcios e Tecnologias da Informao Dezembro de 2011.

ETAPA 01 Passo: 01 A melhor maneira de desenvolver software seguro incorporar a segurana desde o incio do desenvolvimento de software. O desenvolvedor deve conhecer as vulnerabilidades em diferentes artefatos do ciclo de vida do desenvolvimento do software para que estes possam ser removidos assim que possvel. Caso contrrio, a remoo as vulnerabilidades, numa fase posterior ir aumentar o custo significativamente. Vulnerabilidades em software nos afetam quase diariamente, nos foraram a mudar a forma como usamos computadores, alm de ser o centro de algumas das mais espetaculares e caras falhas em computadores. Por exemplo, o custo total do vrus Code Red foi estimado em 2.6 bilhes de dlares, e o vrus Nachi afetou operaes da companhia area do Canad e da CSX ferrovias. Os dois exploraram buffer overflows, uma classe de vulnerabilidades que conhecida desde 1988. Esforos esto comeando a reduzir as vulnerabilidades em software, mas a indstria certamente ainda tem um longo caminho a percorre. O BSI busca alterar o caminho com o qual o software desenvolvido, tendo assim menores vulnerabilidades de ataques atravs da construo de segurana desde inicio do desenvolvimento do projeto. O SSDP est dividido em quatro fases: Engenharia de Requisitos; Design; Implementao; Garantia. Cada uma dessas fases est dividida em uma seqncia de atividades que devem ser seguidas, alm do relacionamento entre as fases. Passo: 02 Requisitos 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. Durante a fase de requisitos, a equipe de produto entra em contato com a equipe de segurana central para solicitar a designao de um supervisor de segurana (chamado de o "cara da segurana" na implementao) que serve como um ponto de contato, pesquisa e orientao durante o planejamento. O supervisor de segurana ajuda a equipe de produto revisando os planos, fazendo recomendaes e garantindo que a equipe de segurana planeje recursos apropriados para dar suporte ao cronograma da equipe de produto. O supervisor de segurana aconselha a equipe de produto sobre os marcos de segurana e os critrios de sada que sero exigidos com base no tamanho, na complexidade e no risco do projeto. O supervisor de segurana continua sendo o ponto de contato da equipe de produto com a equipe de segurana, desde o incio do projeto at a concluso da Reviso final de segurana e o lanamento do software. O supervisor de segurana tambm serve como ponto de contato entre a equipe de segurana e a gerncia da equipe de produto, e aconselha a gerncia da equipe quanto ao controle do elemento de segurana de seus projetos, de forma a evitar surpresas relacionadas segurana posteriormente durante o processo. A fase de requisitos a oportunidade para a equipe de produto considerar como a segurana ser integrada no processo de desenvolvimento, identificar os objetivos-chave de segurana e maximizar a segurana de software, minimizando a quebra de planos e cronogramas. Como parte desse processo, a equipe precisa considerar como os recursos de segurana e as medidas de controle de seu software sero integrados com outros softwares que provavelmente sero usados com ele. (A interface com outros softwares uma considerao essencial para atender s necessidades dos usurios de integrao de produtos individuais em sistemas seguros.) A perspectiva geral da equipe de produto sobre os objetivos, os desafios e

os planos de segurana deve se refletir nos documentos de planejamento produzidos durante a fase de requisitos. Embora os planos estejam sujeitos a alteraes conforme o andamento do projeto, a articulao precoce desses planos ajuda a garantir que nenhum requisito seja desconsiderado ou estabelecido na ltima hora. Cada equipe de produto deve considerar os requisitos de recursos de segurana como parte dessa fase. Embora alguns requisitos de recursos de segurana sejam identificados em resposta modelagem de ameaas, provvel que os requisitos do usurio determinem a incluso de recursos de segurana em resposta s exigncias do cliente. Os requisitos dos recursos de segurana tambm sero definidos de acordo com a necessidade de obedecer aos padres da indstria e dos processos de certificao, como os Critrios comuns. A equipe de produto deve reconhecer e refletir esses requisitos como parte de seu processo de planejamento normal. Anlise/ Projetos o estudo dos objetivos do sistema como um todo, dos procedimentos que o envolvem, da sua estrutura, dos fluxos de informao que estabelece o seu desempenho e as suas deficincias. Atividades da Analise do Sistema: Uma vez compreendido como um sistema interage com os outros, o analista deve preocupar-se com o sistema em si. Identificar cada um dos seus componentes, examinandoos com cuidado de forma a levantar todos os detalhes respeitantes sua natureza, funcionamento e relao com outros componentes. Etapas necessrias para identificao: 1. Determinao dos Objetivos: Antes de qualquer anlise necessrio estabelecer uma base para decidir o que se pretende que o sistema faa tendo em conta os objetivos de cada um dos setores da organizao. Com estes objetivos e as relaes entre departamentos, pode-se estabelecer os objetivos do sistema como um todo. 2. Levantamento de informaes sobre os mtodos utilizados: Antes de se tirar concluses sobre os problemas ou deficincias do sistema pr-existente, deve-se compreender e documentar todos os fatos relacionados execuo dos procedimentos, manuteno das informaes e ao processo de tomada de deciso. 3. Anlise das inter-relaes: Os dados encontrados devem agora ser organizados, analisados e comparados com os de sistemas similares, de forma a serem facilmente entendidos. Os fatores crticos para o desempenho da organizao vo ser identificados e passar a merecer toda a ateno. 4. Determinao dos dados necessrios: Determinar a melhor disposio do fluxo de informao. Quem precisa de qual informao? Quem fornece os dados? Quem processa os dados e obtm os resultados? Fazer por qu? 5. Definio dos procedimentos necessrios: So propostas vrias alternativas pelas quais os processos poderiam ser realizados; um ou mais cursos de ao devem ser apresentados. 6. Ferramentas para a Anlise de Sistemas: Para se fazer uma anlise necessria se recorrer utilizao de ferramentas e tcnicas prprias, de forma a garantir a obteno de dados completos e acertados de modo a que se possa chegar a concluses corretas. Implementao A fase de implementao, a equipe de produto gera o cdigo, testa e integra o software. As etapas seguidas para remover falhas de segurana ou evitar sua insero inicial durante essa fase tm um aproveitamento alto; elas reduzem significativamente a probabilidade de que vulnerabilidades de segurana estejam presentes na verso final do software que lanada para os clientes. Os resultados da modelagem de ameaas fornecem uma orientao particularmente importante durante a fase de implementao. Os desenvolvedores dedicam ateno especial em corrigir o cdigo de

modo a atenuarem as ameaas de alta prioridade e os testadores concentram seus testes na garantia de que essas ameaas estejam de fato bloqueadas ou atenuadas. Os elementos do SDL que so aplicados na fase de implementao so:

Aplicar padres de codificao e teste. Os padres de codificao ajudam os desenvolvedores a evitar a introduo de falhas que podem levar a vulnerabilidades de segurana. Por exemplo, a utilizao de construes de manipulao de seqncias e de buffer mais consistentes e seguras pode ajudar a evitar a introduo de vulnerabilidades de saturao do buffer. As prticas recomendadas e os padres de testes ajudam a garantir que os testes se concentrem na deteco de possveis vulnerabilidades de segurana e no apenas na operao correta de funes e recursos do software. Aplicar ferramentas de testes de segurana, incluindo ferramentas de difuso. A "difuso" oferece entradas estruturadas, mas invlidas para APIs (interfaces de programao de aplicativo) de software e interfaces de rede, de forma a maximizar a probabilidade de detectar erros que podem levar a vulnerabilidades de software. Aplicar ferramentas de verificao de cdigo de anlise esttica. As ferramentas podem detectar alguns tipos de falhas de cdigo que resultam em vulnerabilidades, incluindo saturaes do buffer, de nmeros inteiros e variveis no inicializadas. Realizar revises de cdigo. As revises de cdigo complementam os testes e as ferramentas automatizadas; para isso, elas aplicam os esforos de desenvolvedores treinados no examine do cdigo-fonte e na deteco e remoo de possveis vulnerabilidades de segurana. Elas so uma etapa essencial no processo de remoo de vulnerabilidades de segurana do software durante o processo de desenvolvimento.

Teste O teste tambm conhecido como fase de verificao o ponto em que o software est funcionalmente concludo e entra em testes beta por usurios. Durante essa fase, enquanto o software passa por testes beta, a equipe de produto realiza um "esforo de segurana" que inclui revises do cdigo de segurana alm das concludas na fase de implementao, bem como testes de segurana direcionados. Houve dois motivos para a introduo do esforo de segurana no processo:

O ciclo de vida do software para as verses em questo alcanou a fase de verificao, e essa fase estava em um ponto apropriado para realizar as revises de cdigo e os testes orientados necessrios. Realizar o esforo de segurana durante a fase de verificao garante que a reviso de cdigo e os testes tenham como objetivo a verso final do software, e oferece uma oportunidade para revisar o cdigo desenvolvido ou atualizado durante a fase de implementao e o "cdigo herdado" que no foi modificado.

O primeiro desses motivos reflete um acidente histrico: a deciso de iniciar um esforo de segurana ocorreu inicialmente durante a fase de verificao. Onde foi possvel concluir que realizar um esforo de segurana durante a fase de verificao realmente uma prtica recomendada para garantir que o software final preencha os requisitos e permitir uma reviso mais profunda do cdigo herdado que tenha sido transferido de verses anteriores do software. importante notar que as revises de cdigo e os testes do cdigo de alta prioridade (aquele que parte da "superfcie de ataque" do software) so crticos para vrias partes do SDL. Por exemplo, essas revises e esses testes devem ser exigidos na fase de implementao para permitir a correo precoce de quaisquer problemas, alm da identificao e da correo da origem desses problemas. Eles tambm so crticos na fase de verificao, quando o produto est perto de ser concludo. Manuteno

Apesar da aplicao do SDL durante o desenvolvimento, as prticas de desenvolvimento mais avanadas ainda no do suporte ao fornecimento de software completamente livre de vulnerabilidades, e h bons motivos para acreditarmos que isso nunca acontecer. Mesmo que o processo de desenvolvimento pudesse eliminar todas as vulnerabilidades do software fornecido, novos ataques seriam descobertos e o software que era "seguro" estaria vulnervel. Assim, as equipes de produto devem se preparar para responder a vulnerabilidades recm-descobertas no software fornecido aos clientes. Parte do processo de resposta envolve a preparao para avaliar relatrios de vulnerabilidades e lanar orientaes e atualizaes de segurana quando apropriado. O outro componente do processo de resposta a conduo de um post-mortem das vulnerabilidades relatadas e a adoo de medidas, conforme necessrio. As medidas em resposta a uma vulnerabilidade variam de emitir uma atualizao para um erro isolado at atualizar as ferramentas de verificao de cdigo e iniciar revises do cdigo dos principais subsistemas. O objetivo durante a fase de resposta aprender a partir dos erros e utilizar as informaes fornecidas em relatrios de vulnerabilidade para ajudar a detectar e eliminar mais vulnerabilidades antes que sejam descobertas no campo e utilizadas para colocar os clientes em risco. O processo de resposta tambm ajuda a equipe de produto e a equipe de segurana a adaptar processos de forma que erros semelhantes no sejam introduzidos no futuro. Passo: 03 O investimento em segurana no desenvolvimento uma viagem obrigatria, com apenas estao de partida, que toda organizao, cujo negcio software, se ainda no entrou, ter que entrar. Essa obrigatoriedade est ligada curva crescente de perdas causadas por explorao de falhas de segurana. Essa viagem est obviamente muito mais avanada nos EUA e pases, cujo rigor com questes de segurana maior. No Brasil, por exemplo, a onde de busca solues de segurana para atender o padro PCI (Payment Card Industry), mais especificamente parece ainda nem ter comeado. Algumas alternativas para segurana de ciclo de desenvolvimento, como anlise esttica de cdigo, firewall de aplicao sairo do status de recomendao PCI para obrigatrio em julho/08. O mercad americano mostra boas perspectivas acerca dessas mudanas de mentalidade, basta observar os movimentos das empresas, como por exemplo, a integrao entre Sentinel (Scan) da WhiteHar com o Ounce5 (Source Code Analyzer) da Ounce Labs e outros. Obviamente, eles esto prevendo alta demanda caminho. Voltando questo do negcio em si, hoje as organizaes (pelo menos as grandes) j reconhecem a importncia de desenvolver software com segurana desde o princpio, e que o custo dessa alternativa , sem dvida, menor que os custos associdos incerteza sobre o nvel de segurana do produto final. Essa percepo sobre o nvel de segurana diretamente influenciada pelas evidncias de aes de segurana recolhidas ao longo do desenvolvimento. Cita-se, como exemplo, os touch points da Cigital. No h outro elemento mais importante na segurana do que o recurso humano quer seja no desenvolvimento ou na operao. Acontece, que as instituies de ensino em geral, continuam a no dar tanta importncia ao assunto de software seguro. Quem paga a conta est comeando a agir para mitigar esse problema. Como? Solicitando oficialmente s universidades para que ensinem seus alunos como desenvolver com segurana. Para finalizar, fica destacado que a segurana no desenvolvimento no deve ser o objetivo de negcio de nenhuma organizao (exceto quelas onde esse o negcio em si), mas que seu resultado pode suportar ou no os objetivos de negcio dela. Com essa mentalidade, a resistncia a embarcar dessa viagem passa a ser dirigida pela anlise de risco e custo da oportunidade. Passo: 04 Estouro de Buffer

Estouro de buffer a forma de ataque baseado na explorao do mal uso de funes que manipulam arrays. Esta vulnerabilidade pode estar presente em linguagens que no verificam automaticamente se os limites de memria alocada para uma varivel foram respeitados durante a execuo do programa. Stack-Smashing Protector (SSP) uma das ferramentas mais utilizadas atualmente para impedir ou dificultar a explorao de estouros de buffer para a linguagem C. Sistemas operacionais modernos o utilizam como ferramenta padro para evitar brechas de segurana em programas copilados em seu domnio. Normalmente, o ataque consiste na descoberta de algum parmetro de entrada vulnervel de um sistema que possa ser manipulado de tal forma que permita a injeo de comandos de mquinas maliciosos. Tais comandos, se bem formulados, podem ser usados para comprometer a mquina hospedeira de tal forma que o atacante receba privilgios no antes alcanveis. Em qualquer situao a vulnerabilidade pode ser evitada com boa praticas de programao. O mal uso de funes que trabalham com arrays a principal causadora de brechas na segurana de um sistema. Funes tais que permitam a escrita de um dado em memria alem dos limites estabelecidos pelo o compilador devem ser usadas com um cuidado especial, pois podem estar inserindo vulnerabilidade passiveis de explorao. Aps ter sido tornada pblica a tcnica de buffer overflow por alephone (1998), diversos mtodos surgiram para automaticamente evitar que a explorao fosse executada com sucesso. Solues foram apresentadas tanto para os compiladores como para os sistemas operacionais, visando dificultar ao mximo o uso dessas falhas para maus fins. Porm, no existe atualmente uma tcnica definitiva que evite a explorao dos estouros de buffer sem adicionar overhead significativo ao programa definido. Dentre as tcnicas em compiladores existentes para proteo de cdigo escrito em C, destaca-se o Stack-Smashing Protector (ou SSP, ou ainda Pro Police). Desenvolvido por Hiroaki Etoh, ele uma evoluo do conceito apresentado no Stack Guard por Crispin Cowan. Atualmente, o mtodo padro em diversos sistemas operacionais conhecidos, como Ubuntu e OpensBSD, ele se demonstra muito eficiente em impedir a explorao de buffer overflows. Etapa 02 Passo 01 PHP uma linguagem interpretada livre e utilizada para gerar contedo dinmico na World Wide Web. A linguagem surgiu por volta de 1994, como um pacote de programas CGI criados por Rasmus Lerdorf. Com o nome Personal Home Page Tools, para substituir um conjunto de scripts Perl que ele usava no desenvolvimento de sua pgina pessoal. Em 1997 foi lanado o novo pacote da linguagem com o nome de PHP/FI, trazendo a ferramenta Forms Interpreter, um interpretador SQL. Mais tarde, Zeev Suraski desenvolveu o analisador do PHP 3 que contava com o primeiro recurso de orientao a objetos, que dava poder de alcanar alguns pacotes, tinha herana e dava aos desenvolvedores somente a possibilidade de implementar propriedades e mtodos. Pouco depois, Zeev e Andi Gutmans, escreveram o PHP 4, abandonando por completo o PHP 3, dando mais poder mquina da linguagem e maior nmero de recursos de orientao a objetos. O problema srio que apresentou o PHP 4 foi a criao de cpias de objetos, pois a linguagem ainda no trabalhava com apontadores ou handlers, como so as linguagens Java, Ruby e outras.

O problema fora resolvido na verso atual do PHP, a verso 5, que j trabalha com handlers. Caso se copie um objeto, na verdade copiaremos um apontador, pois, caso haja alguma mudana na verso original do objeto, todas as outras tambm sofrem a alterao, o que no acontecia na PHP 4.[4] Trata-se de uma linguagem extremamente modularizada, o que a torna ideal para instalao e uso em servidores web. Diversos mdulos so criados no repositrio de extenses PECL (PHP Extension Community Library) e alguns destes mdulos so introduzidos como padro em novas verses da linguagem. muito parecida, em tipos de dados, sintaxe e mesmo funes, com a linguagem C e com a C+ +. Pode ser dependendo da configurao do servidor, embarcada no cdigo HTML. Existem verses do PHP disponveis para os seguintes sistemas operacionais: Windows, Linux, FreeBSD, Mac OS, OS/2, AS/400, Novell Netware, RISC OS, AIX, IRIX e Solaris. Construir uma pgina dinmica baseada em bases de dados simples com PHP, (em parte, vale lembrar), este prov suporte a um grande nmero de bases de dados: Oracle, Sybase, PostgreSQL, InterBase,MySQL, SQLite, MSSQL, Firebird, etc., podendo abstrair o banco com a biblioteca ADOdb, entre outras. A Wikipdia funciona sobre um software inteiramente escrito em PHP, usando bases de dados MySQL: oMediaWiki. PHP tem suporte aos protocolos: IMAP, SNMP, NNTP, POP3, HTTP, LDAP, XML-RPC, SOAP. possvel abrir sockets e interagir com outros protocolos. E as bibliotecas de terceiros expandem ainda mais estas funcionalidades. Existem iniciativas para utilizar o PHP como linguagem de programao de sistemas fixos. A mais notvel a PHP-GTK. Trata-se de um conjunto do PHP com a biblioteca GTK, portada do C+ +, fazendo assim softwares inter-operacionais entre Windows e Linux. Na prtica, essa extenso tem sido muito pouco utilizada para projetos reais.

Passo 02 e 03 Exemplo:01

MD5A criptografia Md5 mais comum, que um algoritmo de um hash de 128 bits. Voc pode usar o md5 na sua aplicao. O md5 gera uma string alfa-numrica de 32 caracteres, no importa se voc t gerando o md5 de duas letras ou de um texto de 20 pargrafos. O md5 gerado sempre vai gerar 32 caracteres. Voc pode usar o md5 na hora de salvar um dado sigiloso (senhas) o banco. Com isso, ningum tem acesso senha original do cliente. Depois s comparar o md5 do que foi digitado no campo senha (na hora do login) com o que est armazenado no banco, se bater, t tudo certo. Infelizmente o md5 tem um problema. Voc pode, com muita dificuldade (preste ateno: muita dificuldade), gerar dois md5 iguais. Duas strings diferentes que acabem como um mesmo md5. Isso rarssimo, mas pode acontecer. Pra usar o md5 no PHP s usar da seguinte forma: view source print? 1 $string = 'O rato reu a ropa do rei de Roma';

2 $codificada = md5($string); 3 echo "Resultado da codificao usando md5: " . $codificada; 4 // 54cf74d1acdb4037ab956c269b63c8ac Criptografia crypt() Sua sintaxe string crypt(valor); Retorna uma string e em geral implementa o algoritmo de encriptao Unix Standard DES-based. E tambm no tem decodificao. Exemplo: $texto = "edson"; echo crypt($texto); // RESUTADO: $1$fs2.68/.$VM9iirUeSlJvl4WPWZZmx0 // para voltar: // sem volta ?>

Criptografia BASE64Base64 um mtodo para codificao dos dados para transferncia na Internet. Ela uma codificao de mo dupla, e usando uma segunda funo voc pode descobrir a string original de uma string codificada. Para usar ela no PHP voc tem as duas formas so elas:01 $string = 'O rato reu a ropa do rei de Roma'; 02 03 $codificada = base64_encode($string); 04 05 echo "Resultado da codificao usando base64: " . $codificada; 06 // TyByYXRvIHJldSBhIHJvcGEgZG8gcmVpIGRlIFJvbWE= 07 08 echo "

"; 09 10 $original = base64_decode($codificada); 11 12 echo "Resultado da decodificao usando base64: " . $original; 13 // O rato reu a ropa do rei de Roma 14

15 // Note que $original vai ser idntica a $string

Com esses recursos possvel deixar a aplicao bem mais segura e, por fim, organizada.

Relatrio de Criptografia Relatrio 3: Utilizando Criptografia base64_encode Codifica com base64, para decodificar basta usar a funo: base64_decode(). md5 Retorna um hash em um nmero hexadecimal de 32 caracteres, no h funo de decodificao. crypt Retornar uma string criptografada usando o algoritmo de encriptao Unix Standard DES-based ou algoritmos alternativos disponveis no sistema. No h funo de decodificao, desde que crypt utiliza uma algorimo de um s caminho. Vejamos agora exemplo de uso de cada um: Usando base64_encode:

Usando md5;

Usando crypt:

A grande Vantagem dos dois segundos modos se d a partir da afirmativa que os valores codificados por elas no retornam ao estagio anterior da codificao, "Os modos md5 e crypt no pode voltar o valor da varivel normal depois de criptografado." crypt - nico caminho de codificao de string (hashing). Descrio: string crypt ( string str [, string salt] ) crypt() retornar uma string criptografada usando o algoritmo de encriptao Unix Standard DESbased ou ou algoritmos alternativos disponveis no sistema. Os argumentos so uma string para ser criptografada e uma string opcional para basear em qual encriptao est. Etapa 03 Passo 02 Mtodos de ataque O ataque de SQL Injection consiste em injetar cdigo de SQL (Structure Query Language) em informaes que podem ser manipuladas pelo usurio. Estas informaes podem ser campos de formulrios, variveis de URL ou at mesmo valores descontrole de sesso dos navegadores. O objetivo alterar a lgica do comando SQL para executar comandos arbitrrios. Tem-se visto diversas empresas e rgo do governo sendo vtimas dessa vulnerabilidade. Primeiro exemplo de cdigo vulnervel a SQL Injection est em uma no filtragem dos parmetros passados no formulrio HTML para um cdigo da linguagem de programao PHP.