Protegendo sua aplicação – Mini Livro

Publico Alvo

Toda vez que um desenvolvedor for criar um projeto ou até mesmo aumentar a segurança de um projeto existente, é necessário levantar qual será o público alvo do projeto.

Um projeto que é aberto para o mundo precisa ter mais cuidados do que um projeto que rodará em uma intranet sem acesso externo. Essa informação é necessária para um levantamento de requisitos mais aproximado da realidade. Um projeto que rodará apenas em uma Intranet inicialmente não teria a necessidade de uma proteção contra Brute Force ou XSS, por exemplo, no começo do projeto. Caso o projeto fique acessível para toda internet, seria necessário pensar em todas as possibilidades de ataques e o que fazer quando eles acontecerem.

Ataques Internos

É preciso sempre pensar que ataque interno pode acontecer. Podemos pensar em ataque interno em duas categorias: acidental e proposital.

Um ataque interno acidental seria quando um usuário inexperiente poderia clicar em um arquivo zipado chamado “alterarSenhaDoBanco.exe”. O melhor jeito de tratar esse problema seria pensando: “que tipo de dano esse ataque me causaria”. Alguns pontos a se pensar são:

  • A máquina do banco de dados e/ou servidor do projeto está exposta a um usuário inexperiente? Um usuário consegue fazer um ping  ou acessar a máquina via FTP, SSH ou por pastas? A máquina tem todas as portas de comunicação abertas? Uma solução seria deixar habilitada, para todos os usuários do projeto, apenas a porta 80 ou 8080 ou a porta que realmente é utilizada.
  • O projeto tem um local de backup em comum com usuários inexperientes? O ideal é ter ambientes separados para evitar que um hacker não copie dados do usuário e da aplicação. Imagine o dano que um virus “DELETE ALL” poderia fazer em seus backups.
  • Da rede local é possível que qualquer um abra um túnel para outra rede? Uma solução para esse tipo de problema é: utilizar firewall para evitar que esses tipos de conexões não sejam facilmente iniciadas; usuário que não precisam de túnel não precisam desse recurso liberado.
  • Se possível deixe o projeto em uma rede separada. O projeto em uma rede e ambientes separados dos demais usuários da empresa evitará ataques internos acidentais.

Ataque interno proposital

Pode haver também o chamado ataque interno proposital. Esse tipo de ataque pode partir de um funcionário que está com raiva com a empresa, algum funcionário que quer tirar proveito de alguma situação ou até mesmo prejudicar outro funcionário.

Um funcionário que não é do setor de TI, mas que pode entender de programação, poderia por exemplo, aumentar seu banco de horas apenas com um update; tudo que ele precisaria seria a URL do banco de dados e disparar um Brute Force Attack até encontrar uma senha válida. E você acha difícil alguém conseguir roubar a URL do banco? Bastaria ele puxar papo com alguém de TI, falar que está interessado em projetos + banco de dados e se mostrar simpático. Em pouco tempo o usuário maldoso estaria sentado ao lado de alguém de TI, observando tudo apenas para ‘aprender’ como é o dia a dia de alguém de TI. E facilmente ele conseguiria ver a URL de conexão e até mesmo ter acesso a senha.

Proteja a TI de funcionários de outros setores. Só por que a pessoa é a dona da empresa, e não entende nada de TI, que ela precisa ter usuário e senha a todos os ambientes da empresa; caso você seja obrigado a dar acesso, usuário, senha a pessoas fora do setor deixe isso claro por emails, memorando ou papeis que deixem alguém ciente da responsabilidade. Assim você estará protegido contra problemas futuros de roubo de senhas ou uso indevido.

Conclusão

A vantagem de se determinar quem é o público alvo é que você terá idéia do que deve entrar no planejamento do projeto, e em qual etapa. Quando o projeto é acessado apenas de uma rede fechada, algumas features de segurança podem ser postergadas ou até mesmo ignoradas; uma proteção contra o ataque XSS (veremos ainda nesse post) poderia ser entregue nas etapas finais do projeto, por exemplo.

Quando temos um projeto aberto ao mundo é preciso ter cuidado em sempre ter presentes proteções contra os ataques. Proteção contra XSS, por exemplo, seria primordial no começo do nosso projeto.

Um projeto recém lançado que já apresenta problemas de invasões terá dificuldades em obter credibilidade e confiança do usuário.

31 thoughts on “Protegendo sua aplicação – Mini Livro

  1. Achei muito positiva a iniciativa… acompanho o blog sempre que posso como maneira de estudo e sempre achei que isto é algo que falta na visão dos desenvolvedores e/ou analistas, porque impactam em outras áreas e medidas pequenas ajudam no que circunda uma aplicação.

    • Henrique, boa tarde.

      Realmente é difícil ver o assunto segurança em blogs ou foruns.

      Ultimamente li muito material sobre segurança e resolvi compartilhar. [=

      Obrigado pelo apoio! =D

  2. Parabéns pela iniciativa, Hebert!! Sempre tenho visto os posts e são sempre sobre um tema atual, interessante e este, um tema que pouco se ver falar. Vou terminar de ler, mas me parece bem interessante. Mais uma vez, parabéns!

  3. Parabéns por mais este excelente post!!!
    Mas eu gostaria de saber,e tenho certeza que outras pessoas que acompanham seu site também é quando teremos um livro da casa do codigo – EJB 3.2 Eficaz? rsss, já tenho a JSF Eficaz, JPA Eficaz.

    • Jivago, boa tarde.

      Muito obrigado pelo apoio, fico feliz por saber que estou ajudando.

      Quanto ao livro infelizmente não depende só de mim, mas do pessoal da casa do código também. [=

      Até mais.

  4. Parabéns Hebert :D os seus conteúdos são muito top :D

    E eu feliz aqui com meus 11k acessos do meu blog hauahuahua
    mas não crio nada, apenas posto soluções de exceptions/erros
    e tradução de alguns artigos que acho útil :D

    é isso ai… continue com o ótimo trabalho :D

    Abraços!

    • Gustavo, boa tarde.

      Obrigado pelo apoio.

      Eu vejo qualquer ajuda importante.

      Eu também fiquei feliz da vida quando fiz 10k de visitas algum tempo atrás.

      O importante é não desanimar. [=

      Até mais.

    • Jeferson, boa tarde.

      Obrigado pela visita, e desculpe a demora em responder. Estive muito ocupado nesse último mes.

  5. Parabéns pelo excelente post hebert, esse trabalho que você faz aqui no blog de compartilhar conhecimento é fantástico!

  6. Fiz um teste utilizando XSS, salvei como Teste
    E não funcionou =/

    Aqui não teve como por o link direito, mas eu fiz um link e não funcionou =I

    • Marcos, boa tarde.

      Nesse caso você não colocou a URL, por isso não apareceu direito. Acredite ou não, aqui para mim o Teste está parecendo diferente. [=

      Obrigado pela visita.

      • Boa Noite Hebert ,
        Aqui no blog ficou como link, mais na minha aplicação não ocorreu isso , ficou normal e até um script não rodou.
        Mas eu confio no que você diz e me atentarei com isso nas próximas vezes.

        Sensacional esse mini-livro, já li todos os livros e mini-livros seus[ tenho eles impressos para auto-ajuda].

        Impossível destacar qual o melhor, são todos sensacionais!

        Sou teu fã de carteirinha assinada tenho todas as coleções dos mini-livros e dos EFICAZES ( Jpa e JSF ), estou muito ansioso para o próximo lançamento do EFICAZ!.
        Deus continue te dando sabedoria, peço isso diariamente.
        Quero ser igual a você, com todo esse conhecimento algum dia, meu ídolo!

        Abraços, meus parabéns e até a próxima !

  7. Execelente mini livro, através dele estou podendo adquirir uma bela noção de segurança em aplicações que,particularmente, é uma área que me fascina e que é de suma importância, pois ataques especializados estão se tornando cada vez mais frequentes.

    Baixando o PDF para consulta posterior, mas voltarei a visitar esse site mais vezes!

  8. Não costumo comentar em blogs, mas nesse caso é preciso.
    Parabéns pelo trabalho cara, obrigado por compartilhar o seu conhecimento com a comunidade!

  9. Inacreditável pois quando aprendemos e lemos sobre o assunto de brechas de segurança e erros de programação, a primeira imagem que vem em mente é um estagiário criando seus primeiros códigos ou um estudante aprendendo sobre alguma linguagem e que saiu vendendo seus sites/projetos sem ter o conhecimento mínimo necessário, mas então vemos exemplos de erros e brechas da Microsoft, NASA, Yahoo, Nasdaq, governos entre tantos outros, é no mínimo cômico :D . Gostei muito deste seu mini livro, tem uma visão macro de muitos detalhes imprescindíveis para a sólida construção de um software. Parábens!

  10. Olá. Parabéns pelo blog. São ótimos os tópicos: atuais e revelantes. Já adicionei ao meu leitor de feeds.

    Fiquei com uma dúvida ao ler seu mini-livro e gostaria de ouvir sua opinião. E quanto ao uso de senhas e usernames em arquivos XML, como o persistente.xml do JPA? O que você recomenda? Criptografar o arquivo? E quanto à colocar senhas no próprio código fonte?

    Obrigado. Paulo.

    • Paulo, boa noite.

      Primeiro, me perde a demora em responder. Estou muito pegado no trabalho, para você ter idéia, estou te respondendo dele enquanto um deploy não termina.

      Honestamente não recomendo colocar senha nem no persistence.xml e nem no código. Para mim o melhor local para se colocar a senha é na configuração de pool de conexão que pode ficar dentro do servidor. Ao configurar o pool de conexão (ex.: tomcat, jboss, etc) você pode colocar a senha criptografada. A vantagem dessa abordagem é que você não precisará fazer um novo deploy da aplicação apenas por uma senha trocada.

      Espero ter ajudado, obrigado pela visita e pelo apoio.

  11. Outra dúvida: e quanto ao uso do atributo “rendered” do JSF para esconder informações importantes? Por exemplo, quando alguém esconde de um usuário comum, alguns itens de menu que só devem ser vistos por um usuário cadastrado no sistema.

    • Paulo, boa noite.

      Eu recomendo sempre esconder, mas ainda assim bloquear o acesso no código. Eu penso que se o usuário não deve ter acesso a informação, ela não deve nem ser enviada a tela.

      Espero ter ajudado. Obrigado pela visita.

      • Aí reside a minha dúvida: quando uso o “rendered”, os dados que não devem ser vistos são enviados na resposta da requisição e os mesmos são escondidos no browser do usuário (via JS, por exemplo)? Ou o JSF detecta, no lado do servidor, que os dados não devem ser enviados, altera a árvore de componentes e envia a resposta já omitindo esses dados? Obrigado.

        • Paulo, boa noite.

          Vou te dar uma resposta que você não esperava ouvir: “Por que você não faz o teste e coloca a resposta aqui? Esse teste é fácil de reproduzir. Após a página ser exibida, olhe o código fonte. Coloque em seu código códigos como System.out.println(“passou aqui”) para você saber por onde sua chamada passou”.

          Obrigado pela visita.

Leave a Comment