Exemplo da (in)segurança de um site sem HTTPS


Destaques PPLWARE

35 Respostas

  1. br says:

    muito muito bom post!
    desconhecia essa opcao Follow TCP Stream

  2. NokTham says:

    Pedro Pinto, desculpa lá o reparo: “…em resumo: Caso o seu servidor tens(tenha?) SSL”

  3. NokTham says:

    Isto é sem dúvida um excelente abre olhos! Um óptimo post, agora vamos lá a ver quantos é que vão andar a usar isto para brincar um bocado hehe

  4. DD says:

    Ainda bem que a Google, Facebook e afins andaram anos e anos sem SSL… E não foi à muito tempo que passaram a ter SSL.

    • Nelson says:

      Não, a Google sempre teve ssl, o mesmo para o facebook.

      A diferença, é que antigamente, estes serviços só utilizavam ssl para a autenticação.

      Agora, já usam sempre ssl, mesmo para uma simples pesquisa, ou para ver uma página.

      Tal adveio da massificação das redes wifi, se for tráfego não ssl, é possível ver as páginas que as outras pessoas estão a ver (mas não as credenciais, claro), e executar comandos (exemplo posts) em nome de outrem…

      Isso era possível em qualquer rede cabalada ou não, mas o wifi veio agravar o problema.

      Além disso, o tráfego ssl usa muito mais CPU, com os avanços nos processadores, isso tornou-se mais secundário…

      • HTTPS says:

        Nas redes cabladas não é bem assim….
        A era dos HUBs já passou há muito tempo. Com os switches só recebes o que é pra ti, ao contrário do wifi.

        Obviamente que se podia fazer arp poising, mas dá muito nas vistas.

        • Nelson says:

          Exacto. Nas redes cabladas, era possível, mas mais dificil.

          Nas redes sem fios, é fácil…

        • Ricardo Almeida says:

          ARP Spoofing/Poisoning funciona em qualquer tipo de rede (switched) seja esta cablada ou Wifi, salvo estejam implementados alguns mecanismos de protecção (ex: dhcp snopping) no switch ou no AP/Controladora Wifi e também os hosts (aka windows e/ou *nix) tenha entradas estáticas na tabela de ARP.

          Fica a dica para todos se estiverem na Univ. ou numa rede qualquer se souberem o MAC Address do gateway da rede, insiram na vossa tabela de ARP uma entrada estática do MAC do Gateway para evitarem ataques ARP Spoofing/MITM.

          Para quem quiser aprender mais um pouco sobre o assunto fica o link: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11_603839.html

  5. Lino Lisboa says:

    Excelente artigo, mais uma vez Pllware.

    Obrigado

  6. Cláudio Freitas says:

    Isso não é assim tão linear.
    Há a possibilidade de se fazer a cifra no computador antes de se enviar para o site. Isso faz com que a password não circule em “clear text”. E é isso que uma pessoa que saiba o que está a fazer vai fazer.
    Isto é um exemplo de uma aplicação mal construída e serve, quando muito, para mostrar o que acontece quando se atribuem projectos sensíveis a pessoas menos “atentas” ao que estão a fazer e eventualmente menos conhecedoras das bases.
    Não me parece, no entanto, boa politica fazer parecer que em tudo que é site (que não seja HTTPS) se está sempre a uns cliques de se descobrir passwords transferidas na rede porque isso não é verdade em todos os casos!

    P.S.:Quando muito estejam atentos a avisos do tipo “Esta a sair de uma ligação segura e a partir de agora os seus dados circularam em clear text” ou uma coisa do genero que o velhinho IE produzia.

  7. Nf says:

    Boas
    Que livros sobre segurança em web apps recomendam?
    em inglês

  8. Nelson says:

    William Stallings, CRYPTOGRAPHY AND NETWORK SECURITY PRINCIPLES AND PRACTICE

  9. Ricardo Santiago says:

    🙂

  10. Bruno says:

    Permitam-me apenas uma pequena correção ao explicado inicialmente.
    A chave pública fornecida ao cliente pelo servidor não é usada para enviar informação propriamente dita, mas mais corretamente para cifrar uma chave simétrica acordada entre ambos, que será usada daí em diante nessa sessão, aí sim para cifrar a informação.
    Usam uma chave simétrica, porque esta forma de encriptação necessita de muito menos poder de processamento para encriptar/desencriptar.

    • Filipe says:

      Bem observado, Bruno! A cifra é acordada com recurso à chave pública, e tem de ser uma cifra conhecida por cliente e servidor. Tipicamente cada um dispõe de uma lista delas e é acordada qual deve ser usada para a comunicação segura cliente/servidor. Esta fase é conhecida como fase de handshake.

  11. Alex says:

    Boas, só uma dúvida, caso o nosso servidor suporte HTTPS mas não tenha o certificado, a cifra é feita na mesma certo?
    Apenas dá o alerta no browser por não ter o certificado SSL.

  12. José Adelino says:

    Faltava era mostrarem o mesmo exemplo mas recorrendo agora ao envia de dados através de um formulário web que corra sobre https. Era interessante mostrar o que ficaria registado no wireshark 😉

  13. Jorge Félix says:

    Exemplo1

  14. Ricardo Moura says:

    Fiquei com a conta bancária a zeros só de ler este sh*tpost.

Deixar uma resposta

O seu endereço de email não será publicado.

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

Aviso: Todo e qualquer texto publicado na internet através deste sistema não reflete, necessariamente, a opinião deste site ou do(s) seu(s) autor(es). Os comentários publicados através deste sistema são de exclusiva e integral responsabilidade e autoria dos leitores que dele fizerem uso. A administração deste site reserva-se, desde já, no direito de excluir comentários e textos que julgar ofensivos, difamatórios, caluniosos, preconceituosos ou de alguma forma prejudiciais a terceiros. Textos de caráter promocional ou inseridos no sistema sem a devida identificação do seu autor (nome completo e endereço válido de email) também poderão ser excluídos.