     |
Segurança na Americanas.com:No começo da minha experiência na Americanas.com, não me envolvi em nenhum projeto muito grande. Boa parte do meu tempo estava alocada a pesquisas sobre segurança. Como eu não tinha muita experiência em trabalhar com redes eu ainda conhecia pouco e eu ainda não havia feito nenhuma matéria no IME relacionada a isso. Graças à enormidade de informações que se encontra na Internet, não foi difícil achar o que eu queria. Comecei a aprender muito sobre como as vulnerabilidades são exploradas em um sistema, sobre os erros mais comuns cometidos por administradores de rede em relação à segurança e sobre ferramentas que, embora sejam feitas para verificar se uma rede está segura, são freqüentemente usadas para fins maléficos. Alguns exemplos disso são crackers de senha que são usados pelos administradores para ter a certeza de que os usuários de uma rede estão utilizando senhas suficientemente fortes e pelos hackers para descobrir as senhas de usuários com senhas fracas, scanners de rede que são usados por administradores para procurar vulnerabilidades em seus sistemas e então eliminá-las e pelos hackers para procurar essas vulnerabilidades e utilizá-las para invadir sistemas ou causar danos às redes alheias. Um scanner de rede que chamou muito a minha atenção foi o Nessus. O Nessus é um scanner de rede gratuito que procura falhas de segurança em toda a sua rede e então fornece um relatório completo sobre os problemas que encontrou. Ele não diz apenas onde está o problema, mas também quais as suas conseqüências e o que fazer para eliminá-lo. Mais informações sobre o Nessus podem ser encontradas no site official: http://www.nessus.org/. Outra coisa sobre a qual pesquisei bastante foram ataques DoS (Denial of Service) e DDoS (Distributed Denial of Service). Esses são ataques muito comuns hoje na Internet, pois são muito mais fáceis de se executar do que uma invasão a um sistema, são de difícil detecção (a não ser quando já é tarde demais) e, em alguns casos, são impossíveis de se impedir. Um ataque DoS implica simplesmente que um certo host ou um serviço prestado por um certo host pára de funcionar, por exemplo, quando um ataque é lançado para derrubar um servidor WEB. Qualquer ataque do tipo DoS pode ser impedido através de atualizações do software presente em cada máquina. Quando vulnerabilidades que permitem DoS são detectadas, os fabricantes do software problemático costumam publicar uma correção para tal problema. Ataques DDoS são bem mais sofisticados. Eles partem do princípio de que, havendo um grande número de máquinas se comunicando com o servidor alvo, não só o servidor ficará ocupado demais para receber comunicação de clientes legítimos que precisam do serviço, como os links que levam a esse servidor estarão congestionados demais para transmitir dados que estabelecem uma conexão com o cliente. Esse tipo de ataque, quando bem executado, não pode ser impedido e, para minimizar o prejuízo causado, deve ser detectado o quanto antes. O que impressiona mais nesse tipo de ataque são as ferramentas usadas pelos hackers. Essas ferramentas possuem interfaces que permitem que o hacker controle centenas de máquinas ao mesmo tempo sem muito esforço. Um dos projetos em que trabalhei envolvia escrever um pequeno programa que detectasse certos tipos de ataques DDoS. Para isso tive que compreender com certo detalhe o funcionamento do protocolo TCP. Uma matéria que teria me beneficiado muito nesse ponto seria MAC 448 (Redes: Uma perspectiva de software). Infelizmente eu ainda não havia feito essa matéria e tive que fazer toda a pesquisa necessária do zero. Por outro lado, quando finalmente cursei MAC 448, o conhecimento adquirido no estágio permitiu que eu desse uma aula sobre segurança de rede. Informações sobre DDoS e segurança de rede em geral podem ser facilmente encontradas na Internet. Uma boa fonte de informação é o site da Security Focus (http://www.securityfocus.com/). Para assuntos mais específicos de segurança, o ideal é utilizar um bom search engine já que a melhor literatura de segurança está mesmo em sites produzidos por hackers. Como muitos desses sites não tendem a permanecer por muito tempo no ar não incluirei links aqui. Fraudes:Toda empresa de comércio eletrônico e televendas corre um certo risco em relação a fraudes. Qualquer compra feita com cartão de crédito implica em um certo risco que a empresa está tomando, pois não dá para saber se o cliente está usando um cartão de crédito que acabara de ser roubado. Quando isso ocorre, o dono do cartão irá fatalmente estornar a cobrança na sua fatura de cartão de crédito e a empresa, tendo já entregue o produto, nada mais poderá fazer além de aceitar o prejuízo tomado. Esse tipo de problema nunca chegou a alcançar grandes proporções na Americanas.com. Durante algum tempo trabalhei em um projeto para que esse problema não apenas não aumentasse, mas para que pudéssemos impedir algumas fraudes que já estavam ocorrendo. Foram necessárias algumas reuniões para com as pessoas envolvidas na prevenção de fraudes para definirmos o que seria feito. Seria implantado um sistema de prevenção de fraudes na Americanas.com pelo qual passariam todos os pedidos. O sistema tentaria separar os pedidos de compradores legítimos dos pedidos de pessoas agindo de má fé. Coube a mim escrever o código que implementasse esse sistema de prevenção. Por ser basicamente relacionado à análise dos dados do pedido e do comprador, o sistema foi implementado diretamente no banco de dados em PL/SQL, uma extensão de SQL que permite alguns recursos adicionais de programação. Mais uma vez me vi diante da situação de ter de lidar com algo com a qual eu ainda não havia tido muito contato. Eu cursaria a disciplina de bancos de dados (MAC 426) apenas um semestre depois. O pouco contato que eu já havia tido com SQL e com o uso geral de bancos de dados havia sido na própria Americanas.com. Mas um pouco de esforço e análise de alguns exemplos de código me deixaram “fluente” em PL/SQL em pouquíssimo tempo e a construção do sistema anti-fraudes ocorreu sem maiores problemas. Ainda que eu gostaria de poder contar sobre o que aprendi em relação à prevenção de fraudes, não poderei entrar em detalhes sobre esse assunto já que, ao tornar isso público eu estaria deixando vulnerável o sistema antifraudes da Americanas.com, o que invalidaria toda essa parte do meu trabalho por lá. Um pouco sobre WebObjects:Na Americanas.com a maior parte do desenvolvimento das aplicações usadas para o funcionamento do site e dos processos internos da empresa são feitas usando um ambiente de desenvolvimento da Apple, conhecido como WebObjects. Como tive que usá-lo muito, antes de descrever os projetos em WebObjects, vou falar um pouco sobre o seu funcionamento. O WebObjects é uma ferramenta interessante. Ela permite que você crie com facilidade páginas da WEB e desenvolva toda a lógica de programação por trás dela mais ou menos como se você estivesse programando uma interface nativa de um sistema operacional. As páginas são criadas visualmente e os campos no design visual podem ser associados a variáveis ou métodos em classes pertencentes ao seu projeto, por exemplo, se você tem em uma determinada classe um método que retorna uma string com o nome de um produto, e ao mesmo tempo uma página com um campo que mostra o nome desse produto, você pode associar esse campo ao método correspondente. Assim quando essa página tiver de ser mostrada ele chamará o método e preencherá o campo com o resultado dessa chamada, no caso desse exemplo, com o nome do produto. O código fonte que reside por trás da interface WEB do WebObjects pode ser uma de três linguagens: Objective-C, WebScript ou Java. Objective-C, apesar do nome, é uma linguagem que não tem muito a ver com C. É uma linguagem orientada a objetos, mas sua sintaxe é bem diferente de C++. Até mesmo lá na Americanas.com, os desenvolvedores conhecem pouco de Objective-C. WebScript, como o próprio nome já diz, é uma linguagem de script que também não é usada por lá. O que realmente faz sucesso por lá é o Java. Praticamente todo o desenvolvimento WebObjects é feito com Java como a linguagem por trás da interface. A programação em Java no WebObjects permite que seja usado qualquer recurso presente no pacote Java da Sun além de fornecer novas classes que facilitam certas tarefas como o acesso ao banco de dados. Para acesso ao banco de dados o WebObjects possui uma interface visual que permite que sejam definidas as propriedades das tabelas assim como as relações entre elas. Após ter suas relações definidas, joins entre as tabelas são feitos automaticamente na medida do necessário. Acessar os dados do banco também fica bem mais fácil, pois o WebObjects mapeia as tabelas em classes Java e as colunas em métodos das classes. Assim, em uma tabela com informações sobre clientes chamada “Clientes” que possui uma coluna chamada “Nome”, por exemplo, essa coluna pode ser acessada através de uma chamada ao método “nome()” da classe “Clientes”. Cada linha na tabela equivale a uma instância de um objeto da classe correspondente. Apesar de facilitar certas tarefas, o WebObjects também tem seus defeitos. O que dá para notar de cara ao começar a usar o WebObjects é que a interface do ambiente de desenvolvimento foi claramente feita para ser portátil, não possuindo a “fluidez” normal de um programa Windows. As regras para seleção de texto e o comportamento do mouse ao clicar em um objeto diferem levemente do padrão a que os usuários Windows estão acostumados; por exemplo, esperamos que ao clicar com o botão direito em um objeto teremos um menu com todas as opções relacionadas àquele objeto. O ambiente para a criação visual de páginas é o mais confuso de todos e ainda não estou totalmente adaptado a ele. Outra peculiaridade do WebObjects é que, mesmo permitindo programação em Java, a linguagem nativa no WebObjects ainda é Objective-C. Por causa disso algumas aplicações exigem que seja feita uma certa “ginástica” em Objective-C (já que todas as aplicações WebObjects devem ter um ponto de entrada escrito em Objective-C) para que esta chame uma classe Java que executará o resto do programa. O WebObjects também reclama, ocasionalmente, de alguns recursos do Java. Em uma aplicação que comecei a escrever, precisei fazer uso do sistema de threads do Java. Ao acessar o banco de dados em um thread separado, o WebObjects começou a cuspir uma enorme quantidade de mensagens de erro. Uma pesquisa no site da Apple mostrou-me uma breve explicação de porque isso acontecia e o que eu teria de fazer para solucionar o problema. Este foi um caso excepcional, pois a maior crítica que tenho a fazer em relação ao WebObjects é a falta de documentação. A maior parte do que sei sobre WebObjects foi aprendido através da observação de código escrito pelos meus colegas de trabalho ou por indagações diretas a eles. Por não ter uma interface mais intuitiva, a Apple deveria ter compensado o WebObjects com documentação mais abundante. Os manuais do pacote WebObjects não fazem mais do que explicar casos específicos e relativamente simples em relação ao uso de certos recursos. Alguns recursos não possuem sequer menção no manual. O sistema de ajuda on-line do WebObjects não é muito diferente sendo que a documentação mais completa presente nele é a documentação oficial do Java, escrita pela Sun. Recentemente estive fazendo algumas pesquisas para que pudéssemos executar as consultas no banco de dados causando menos stress nos servidores através do uso de procedimentos e funções presentes no próprio banco de dados. Embora esteja claro, através das opções apresentadas na interface visual, que existe no WebObjects recursos para tornar isso possível, posso dizer com uma boa dose de certeza de que não há documentação sobre isso publicada em nenhum lugar acessível a um usuário de WebObjects. Após extensivas buscas na documentação on-line do WebObjects, no site da Apple (que não tem muito mais coisa do que na documentação on-line) e na própria Internet, não consegui encontrar nenhuma referência a isso. Projetos em WebObjects:Quando comecei a trabalhar com WebObjects, não cheguei a pegar nenhum projeto desde o começo. Inicialmente apenas tive que fazer alterações em aplicações que já estavam prontas e precisavam de novos recursos acrescentados. Uma dessas aplicações usada pela central de atendimento da Americanas.com. Para atender bem a um cliente, é necessário que o atendente tenha o maior número de informações possíveis sobre o pedido em questão. Fiz alterações nessa aplicação para responder certas dúvidas de clientes que os atendentes não estavam conseguindo responder. Outra aplicação na qual mexi é a responsável pela cobrança de cartão de crédito dos clientes. Ela pega todos os pedidos feitos com cartão de crédito que estejam aguardando aprovação da administradora de cartões de crédito. Os pedidos são lidos um de cada vez e o número do cartão de crédito associado ao pedido é enviado ao servidor TEF (Transferência eletrônica de fundos). No servidor TEF, o cartão é enviado à administradora de cartão correspondente através de uma conexão criptografada. O servidor então envia de volta o resultado da transação e a aplicação age de acordo enviando e-mail de confirmação de compra ou de recusa do cartão ao cliente que fez a compra. Após o uso, o número do cartão de crédito é apagado, por segurança. As alterações que fiz nesse programa foram relacionadas à quantidade de informações passadas ao cliente no e-mail de confirmação e à decisão de quais pedidos devem ser processados por esta aplicação. A Americanas.com não faz vendas apenas pelo site, mas também tem uma central de televendas. Devido a alguns problemas que tivemos com a estabilidade da aplicação usada no processo de televendas, para a segurança dos clientes, foi decidido que seria melhor se essa aplicação não fizesse o processamento de cartões de crédito, mas deixasse que isso fosse feito pela mesma aplicação que faz o processamento de cartões de compras feitas pelo site por essa ser comprovadamente estável. Cartões de crédito:O maior projeto no qual trabalhei até agora deverá entrar no ar em breve. Como foi explicado na seção anterior, temos uma aplicação que processa os pagamentos de cartões de crédito enviando o número de cada cartão ao servidor de transferências eletrônicas juntamente com o valor a ser cobrado. No momento essa comunicação funciona da seguinte forma. A aplicação grava as informações de cobrança em um arquivo criptografado em uma pasta montada remotamente no servidor TEF. O servidor TEF lê esse arquivo e processa a transação com a operadora de cartão de crédito. Em seguida o servidor TEF grava o arquivo com o resultado e a aplicação lê o resultado e grava um outro arquivo contendo a confirmação de que recebeu a resposta, o qual o servidor TEF lê e confirma a transação. Acontece que, durante esse processo, o servidor pode não conseguir receber a confirmação da transação. O motivo é provavelmente a corrupção do arquivo durante a transferência de um lugar ao outro. Ainda que a não confirmação de uma transação não implique problema nenhum para o cliente, já que o resto do pedido continuará a passar por todo o resto do processo normalmente e o número do cartão apagado como deveria, isso faz com que seja necessário alguém ir até o servidor TEF e confirmar as transações pendentes manualmente. O pior que pode acontecer quando uma transação não é confirmada é o atraso da cobrança na fatura de cartão de crédito do cliente, mas o simples fato de que alguém tem que ir até lá periodicamente para confirmar as transações é algo contraditório à filosofia da empresa de automatizar todo o processo de compra para obter a maior agilidade possível. Foi pensando nisso que será alterada a maneira como esta cobrança é feita. Do ponto de vista do servidor TEF, a alteração é simples. Ao invés de fazer a comunicação através de arquivos, a comunicação será feita através de comunicação criptografada via sockets. O servidor TEF que estaremos utilizando já possui suporte a esse tipo de comunicação. Mas a aplicação que faz hoje o processamento de cartões de crédito do site o faz gravando os arquivos descritos acima no servidor TEF. Para que ela continuasse a trabalhar no novo sistema ela teria de ser alterada para suportar o uso de sockets. Acabamos optando por não alterar a aplicação, mas sim por construir uma nova aplicação que fizesse isso com um pouco mais de eficiência. Foi essa nova aplicação na qual eu andei trabalhando ultimamente. A nova aplicação lê todos os pedidos que estejam aguardando cobrança de cartão de crédito e inicia um novo thread para cada pedido. Cada thread abre, independentemente, uma conexão com o servidor TEF e faz toda a comunicação necessária através dessa conexão. Cuidados foram tomados em alguns pontos devido à aplicação ser multithread. Como cada nova conexão ao banco de dados consome uma quantidade não desprezível de recursos do servidor de dados, é importante que, mesmo com vários threads rodando, todos eles utilizem a mesma conexão ao banco de dados. Por causa disso é importante que dois threads não acessem o banco de dados ao mesmo tempo. À primeira vista isso pode parecer meio sem sentido, afinal se estamos usando threads para permitir múltiplas conexões ao servidor TEF e, de repente colocamos uma limitação dessas na comunicação com outro servidor, onde está o ganho de eficiência? Acontece que o tempo que um thread gasta acessando o banco de dados é bem menor do que o tempo que ele gasta comunicando-se com o servidor TEF, assim é plausível que vários threads compartilhem a mesma conexão com o banco de dados, mas não a mesma conexão com o servidor TEF. Por ser esta uma aplicação multithread e pelos cuidados que tive de tomar para torná-la “thread-safe”, tive de recorrer a muito do que aprendi durante a matéria de programação concorrente (MAC 438). Foi nessa matéria que fiz pela primeira vez programas multithread em Java e entendi os aspectos mais importantes de concorrência. No momento a aplicação está pronta, mas está passando por uma série de testes para eliminar eventuais bugs. |
|
Copyright © 2000 - Denis Celestino de Souza
|