Skip to content

Instantly share code, notes, and snippets.

@lfzawacki
Created March 26, 2018 03:16
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save lfzawacki/a08ccdee6704463b01830b8f994e0f8f to your computer and use it in GitHub Desktop.
Notas Hack Fest 24/03/18

software seguro - protege o quê? qual é o dano que se quer evitar? qual é o acesso que se quer registringir?

vulnerabilidades criadas por omissões técnicas dos próprios programadores

  • minimizar superfície de ataque - se precisar deixar superfícies abertas, o admin tem que assumir o risco...

  • negar por padrão, permitir só /site (robot e firewall, por exemplo, arquivo de indexação)

  • uso de componentes mais confiáveis - não precisa escrever tudo na mão, mas buscar aplicações com uma comunidade grande e ativa (quanto mais gente monitorando o código, mais chances de ele ser mais seguro...)

  • segurança em vários níveis de profundidade

  • evitar segurança por obscuridade, porque UMA vez quebrada...

  • privilégios mínimos - pensar segurança conforme REAL necessidade de pessoas terem acesso aos privilégios de admin

  • presumir que os sistemas SEMPRe são inseguros

  • 443 porta padrão do https

  • burpsuite: proxy

  • quando não mostra https, é porque é http

  • foxproxy - addon

  • setar foxproxy para enviar para determinado local as requisições que saem da máquina, para serem lidas pelo burp

  • política da mesma origem - navegador não recebe linguagem client side de origens diferentes (???)

  • cookie pelo domínio, origem pelo host

  • firebug para facilitar visualização e gerenciamento de cookies

  • serviço nenhum deve enviar senha por e-mail, porque ele não pode guardar sua senha... ele pode te enviar um link para que tu escreva diretamente no banco de dados a nova senha

  • o correto é guardar o hash gerado por aquela senha, mas um hash dinâmico, não um estático (estático pode ser quebrado por força bruta, e quebrando o primeiro...)

  • outra camada de dificuldade é adicionar um salt (sempre dinâmico, um pra cada senha) na senha antes de gerar o hash

  • procurar o /robots.txt

  • http only setado evita que uma linguagem clientside envie o cookie, por exemplo, para um link que rouba a sessão por um javascript

  • abas anônimas apagam o cookie logo que a aba é fechada/sessão encerrada. clicar em um link malicioso durante a navegação pode entregar o cookie por javascript (tópico anterior)

  • não aceitar que o login seja lido como sql (o ideal é ser como string) porque ele pode gerar um valor verdadeiro (true) e assim aceitar o login, entregando o primeiro usuário do banco (APENAS o masteradmin do sistema...)

  • xkcd.com

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment