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