Vulnerabilidades mais comuns em apps (e como corrigir 🎉)

o maior problema de segurança do seu app ou SAS não tá na rede nem grandes exploits tá entre a cadeira e o monitor o problema não é que seu código pode ser hackeado é que você já deixou ele praticamente aberto mas calma hoje eu vou te mostrar as vulnerabilidades mais comuns que eu encontro por aí E como corrigir se depois desse vídeo você cometer esses erros não é descuido é sabotagem eu não vou focar em falar sobre grandes cvs redes nem nada disso ainda mais porque você tá hospedando na versel Fly ou outra grande empresa

que tem um certo tipo de proteção e provavelmente você tá usando ORM que dificulta scale injection tá fazendo tudo em jsx que dificulta xss não significa que é impossível você não sofrer esses ataques só que não é o escopo desse vídeo e tem infinitos conteúdos sobre essas vulnerabilidades e eu recomendo muito você pesquisar Bora lá web Hook todo mundo gosta mas principalmente a grande maioria usam sempre a mesma rota ap web Hook ou ap Hook isso não tá errado e Tecnicamente não é uma coisa ruim mas qualquer um pode ficar chutando rotas possíveis de web

Hook e acabar encontrando e se tiver mal configurado um usuário mal intencionado pode mandar uma mensagem para sua rota fingindo o se méo de pagamento confirmando uma compra sempre que você for configurar um web Hook você tem que usar uma sinatura secreta no stripe você recebe o cabeçalho stripe signature e no mercado pago tem o ex signature seu backend deve validar esse código para garantir que a requisição veio da funte certa e aí Quando um usuário mandar uma requisição pro web Hook a sua P vai reclamar que falta assinatura idor que é basicamente não verificar

permissão ao acessar S objetos via api imagina que você tem um Ed Point purchas barid e o código é mais ou menos assim o usuário vai mandar uma requisição get purchas com o ID 1 23 e você vai devolver os detalhes da compra Mas e se essa compra 1 23 não foi dele Parabéns Tu acabou de vazar os dados de outro usuário outro erro clássico é o Patch profile onde o servidor recebe o user ID no corpo da requisição Não façam isso o ID do usuário deve vir sempre da sessão do jwt do que for

mas nunca do body da requisição sempre valida quem tá pedindo acesso Antes de mostrar editar ou excluir qualquer coisa data exposure que é a exposição de dados sensíveis imagina que você criou o Marketplace e você pode acessar um produto mandando uma requisição G com ide do produto beleza a retorna aos detalhes do produto e do vendedor só que junto com o nome e a foto do vendedor você também acaba recebendo o e-mail o CPF o telefone endereço senha criptografada isso aconteceu porque quando você buscou o produto acabou pegando os dados do vendedor também só só

que você acabou não filtrando o que que devia ter sido enviado por front ou não Você deve enviar somente o que realmente for necessário pro frontend se você precisa do nome da foto do vendedor só manda isso não vai pensando que ah o frontend só usa o que precisa não proteja seus usuários não colocar um rate limit ou um capt em certos lugares pode não ser uma vulnerabilidade direta mas sem dúvida é uma das coisas que mais prejudica o produto imagina que sua aplicação tem uma p pública para fazer um post se não houver nenhuma

limitação no uso um atacante pode automatizar essa requisição e criar milhares de posts falsos isso acaba poluindo o banco de dados e degradando a experiência dos usuários e Vale lembrar que armazenamento em banco é relativamente caro então sem uma proteção você acaba perdendo dinheiro um outro exemplo Suponha que você tem uma API para enviar um e-mail um atacante pode enviar milhares de requisições explodi o seu limite de envio de e-mail e você tem que acabar pagando para poder enviar mais e-mails de novo também não colocar essas proteções acabam diminuindo a segurança do seu aplicativo em

geral em uma página de login por exemplo dá para fazer um ataque de brute Force para descobrir a senha de alguém então você tem que considerar implementar um capt limites ou outro mecanismos em lugares sensíveis ou caros mass assignment conhecido como atribuição massiva essa vulnerabilidade Inclusive eu explorei lá no último vídeo quando eu me tornei administrador quando você tem uma rota Patch você altera algumas informações de Algum objeto como o username para usuário descrição para algum produto essa vulnerabilidade deixa você alterar qualquer propriedade do objeto além de você alterar o seu nome de usuário você

também consegue alterar seu cargo para administrador ou qualquer outra propriedade você tem que definir explicitamente os campos que podem ser alterados ou não esse aqui é meu favorito que vulnerabilidade mais linda time of check to time of use é um tipo de vulnerabilidade que é causado quando tem um intervalo entre verificar uma condição que é o cheque e usar o resultado o use o exemplo clássico é do banco você tem R 100 na sua conta e você pede para fazer o saque dos R 100 primeiro o programa vai verificar se você tem o dinheiro se

tiver faz o saque Mas e se você mandar duas requisições ao mesmo tempo Tecnicamente é bem difícil conseguir mandar só duas requisições ao mesmo tempo então geralmente a gente manda várias porque tem um delay de rede de tanto quem envia quanto quem recebe a função vai ser executada várias vezes ao mesmo tempo e ao mesmo tempo vão passar pelo cheque que verifica o saldo e depois vai acontecer o saque várias vezes isso funciona para muitas coisas tanto para like em alguma publicação compra de tickets e tudo mais e a resolução é bem fácil você só

precisa travar os recursos críticos enquanto estão sendo usados você pode usar semáforo sistema de filas mas o que é mais usado Ger são as transactions no banco de dados onde o check e o use aconteçam de forma atômica ou seja uma operação ou acontece totalmente ou não acontece nada sem interrupção confiar no frontend Na verdade essa parte é uma junção de vulnerabilidades mas que eu agrupe tudo e gosto de chamar de confiar no frontend muita gente acha que validar só no front já é suficiente afinal se o botão tá desabilitado a requisição nunca vai ser

enviada se o frontend fala que eu tenho R 10 eu posso sacar os R 10 afinal foi o meu servidor que falou pro front Ele tem 10 certo não é bem assim qualquer regra que tá no front end pode ser ignorada ou manipulada pelo usuário e isso é verdade principalmente quando você US CSR quer ver a gente tá aqui na Aler pi eu mudar meu dinheiro para e pod liberar o botão do saque a primeira que a gente tem que fazer é proc o texto de saque indisponível que provavelmente uma renderização condicional a gente procura

aqui encontr a gente pode achar aqui agora a condição de renderização que é ou saque indisponível ou é o botão de resgatar Então essa aqui é a nossa condição Vamos colocar um Break Point aqui em cima e recarregar a página agora eu tenho o código pronto aqui que vai mudar as variáveis do front end então ele vai mudar o meu amount Gross amount vai botar essa variável c como como true vai mudar as informações da minha conta para ela poder liberar o saque e o código é esse aqui Eu recarreguei a página parou no break

Point e agora vou mudar as variáveis então mudei o código execução mudei executa mudei executa pronto meu saldo Total tá aqui e o botão liberou agora se eu clicar sacar com pix vai mandar requisição pro backend mas eu sei que Alert pix ele Verifica o que o front Change envia Então essa requisição vai falhar mas era só para mostrar para vocês que toda a renderização condicional que acontece do lado do cliente pode ser falsificado Agora imagina o e-commerce que ele vai calcular os preços no front Change e enviar o valor pro backend e se interceptar

a requisição e mudar o preço para 50 o backend tem que ter algum controle Então você recebeu o preço Confere se o preço no back end é igual do front end se não for retorna um erro sempre recalcule os preços no servidor você nunca nunca nunca deve confiar no frontend e sempre validar no backend se o seu sistema depende só do frontend Para ter segurança alguém vai burlar Pronto agora seu app tá impossível de ser hackeado brincadeira segurança 100% não existe e nunca vai existir Pensa bem todo programa que você usa para criar ou hospedar

seu app foi feito por ser humano e humanos erram pode ser um bug no seu código no Framework que você usa banco de dados sistema operacional Tudo foi feito por alguém que em algum momento pode ter cometido um único erro e mesmo que seu código seja perfeito nada impede que alguém invada fisicamente seu servidor ou algum funcionário do seu provedor de hospedagem roube suas credenciais você cai em algum Fishing enfim segurança é um jogo infinito o objetivo não é ficar 100% Seguro mas é dificultar ao máximo o ataque e reduzir os danos se alguma coisa

der errado agora falei já viu essas falhas em algum lugar deixa nos comentários e claro se curtiu já sabe se inscreve deixa o like e manda o vídeo para aquele Dev que confia muito no fronte valeus