Protegendo sua aplicação – Mini Livro

No que se baseia segurança?

Infelizmente falar de “segurança de projetos” não é simples, esse termo é um termo muito amplo e é possível encontrar diversas definições.

Umas definições interessantes são da Microsoft (links no final) sobre o que abranger quando falamos de “segurança de projetos”. Abaixo podemos listar as bases da segurança de projetos citadas pela Microsoft (haverá comentários e linhas a mais que eu escrevi abaixo):

  • Autenticação: Quem é você? Essa ação determina se a chamada ao nosso projeto vem de uma fonte conhecida. Uma fonte conhecida poderia ser uma pessoa, um celular, um browser, um hacker, etc. Existem diversos projetos que não necessitam de um login, por exemplo: Google, uaiHebert.com, etc. Não é só por que uma requisição está sem dados de login (usuário autenticado, login, senha, etc), que ela não pode ter um perfil conhecido. Para requisições de usuários não logados um perfil como NAO_LOGADO seria ideal. As vantagens de ter um perfil para quem não está logado seria:
    • Podemos ter uma linguagem em comum na hora de debates sobre o projeto, a seguinte frase poderia aparecer: “essa nova funcionalidade poderia ser acessada por um NAO_LOGADO?”.
    • O perfil NAO_LOGADO poderia ser filtrado em determinadas áreas do projeto: “Perfil NAO_LOGADO não poderá ter acesso a tela X”.
    • Em caso de auditoria poderíamos ter diversos registros de navegações salvos para alguém do perfil NAO_LOGADO. 
  • Autorização: Você pode fazer isso? Uma chamada que vem de um perfil conhecido (ou não no caso de usuários de perfil NAO_LOGADO) e que foi validada por um processo de autenticação, pode ou não realizar determinada ação. Um usuário poderia apenas ter acesso de leitura, enquanto um gerente poderia ter acesso as ações de CRUD do projeto. Falhas de autorizações poderiam levar a gravíssimos problemas, perda de dinheiro para a empresa, quebra de confiança para com o usuário, etc.
  •  Auditoria: Haverá quem fiscalize o projeto? O que será fiscalizado? Existem projetos que colocam todas as informações do projeto (dados do request, dados do usuário, etc) em um banco de dados/arquivos de texto e, ao acontecer algum problema, colocam algum funcionário para analisar aquela quantidade enorme de registros. Muitas vezes a enorme massa de dados causa preguiça/indisposição na hora de buscar algum problema, o que pode ocasionar erros na procura de falhas de segurança. Sempre deixar disponível para o auditor (seja um profissional em auditoria ou um desenvolvedor) as informações de um modo bastante direto e objetivo. Salvar as informações importantes em lugares separados é importante para conseguir analisar uma possível fraude, por exemplo, um cliente que alega que não solicitou a troca de plano e processa a empresa. Note que o trabalho de auditoria pode vir a ajudar na questão da segurança e na questão da evolução do projeto.
  • Confidencialidade: também conhecida como privacidade, confidencialidade é o conceito de somente ter acesso a determinada informação somente quem pode ter. Uma pessoa só poderá ver as fotos de outra se for permitido. Outra preocupação também é: os dados estão protegidos na hora do envio e do recebimento da informação? Estamos protegendo a informação de modo que ninguém no meio do caminho consiga roubar a informação? Veja a imagem abaixo:
    manInTheMiddle
    Qual a garantia que temos de que a informação enviada é a mesma recebida? O que precisamos fazer para que o “User Request Data” não seja interceptado? É preciso ter o cuidado de proteger as informações enviadas pelo usuário, não deixar que nenhum dado confidencial seja exposto.
  • Integridade: A informação recebida está exatamente ao que o foi enviado? Imagine que uma pessoa, cheia de maldade no coração, interceptou um request enviado por um usuário e alterou o email enviado (usu@rio.feliz.com) para o email dele (pur@maldade.com). A partir daí todos os comunicados que seriam recebidos pelo nosso usuário feliz iriam para o hacker do mal; uma vez que o hacker tenha em mãos os comunicados enviado e ele poderia simplesmente encaminhar o email para nosso usuário feliz e continuar com a farsa. É preciso sempre ter certeza de que a informação enviada chegue completa e sem alterações.
  • Disponibilidade: a aplicação sempre deve estar disponível para requisições de chamadas confiáveis. Durante um ataque de DoS (veremos mais a frente) é preciso manter o serviço disponível para os usuários confiáveis e de algum modo impedir que o projeto falhe.

Note que os conceitos vistos tratam os aspectos de como a aplicação deve se comportar, mas e com relação aos funcionários que trabalham com a aplicação? Como devemos tratar ataques internos? Que tipo de código pode prejudicar a segurança do nosso projeto?

Todos os pontos vistos acima e as perguntas levantadas nesta página serão detalhadas mais a frente nesse post.

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