Vulnerabilidades de injeção afetam cerca de 19% das aplicações analisadas pelo OWASP, mas o alto impacto de roubo de dados ou execução de comandos por injeção significam que essa é a 3a vulnerabilidade mais relevante em aplicações web.

Lembre que qualquer requisição feita para um servidor malicioso a partir do seu site pode roubar os cookies do seu site se eles não forem configurados especificamente para serem de site único, ou outros dados privilegiados.

Outro exemplo de injeção bem conhecido é o XSS, que é justamente o caso que citei acima de quando HTML é construído a partir de input.

Em SQL, por exemplo, é recomendável sempre usar um query builder (ou um ORM que construa suas queries, embora não seja minha preferência) que irá cuidar sempre de que os dados sejam tratados de fato como dados.

Então, por exemplo, se você for gerar SQL, todos os elementos que podem fazer execução acontecer têm que ser claramente distinguidos por meio de escaping.

Mas é melhor ainda se você puder só evitar gerar comandos a partir de dados que não sejam extensivamente validados.

Se você usa "eval" em JS com dados gerados a partir de input do usuário, você pode permitir que ele rode código arbitrário.

Em resumo: Injeção ocorre sempre que você tem uma confusão entre "código" e "dados".

Pra impedir injeção de acontecer, você tem que ter certeza que a distinção é clara.

Mas SQL Injection não é o único tipo de injeção relevante. Por exemplo, se você gera uma página HTML a partir de input do usuário, você permite ao seu usuário injetar componentes que fazem requisições HTTP numa página.

Injeção, resumidamente, é quando o input de um sistema externo pode entrar, sem controle, num comando que vai ser passado pra outro sistema. Por exemplo, se você usa um banco SQL, se você permite que o comando SQL seja definido por quem está enviando input.

Design inseguro afeta 24.2% das aplicações afetadas pelo OWASP, normalmente com consequências graves e grande dificuldade de mitigação - pois a vulnerabilidade no nível do design torna difícil de alterar de forma segura.

Qual a solução então? Você precisa ter um modelo claro do uso pretendido do seu sistema e já projetar ele pra que seja possível coibir comportamentos que não sejam os ideais. Incluir atividades de modelagem de ameaças no processo de design é importante.

Nesse caso, se não tiver outros controles, o próprio design do seu sistema abre pra um atacante que simule vários usuários simultâneos e reserve todos os ingressos disponíveis, te impedindo de vender.

Por exemplo, suponha que você está fazendo um sistema de compra de ingressos. Suponha que você deixa as pessoas reservarem os ingressos sem pagamento imediato.

Essa é uma categoria bem ampla, mas o resumo é: Cada parte do seu sistema precisa ter um design claro de controles. O que são controles nesse contexto? São as regras de como é definido se uma determinada entidade (pessoa, sistema) deve ter acesso àquela parte.

"Se fosse bom mesmo não estaria cobrando barato"

"Se fosse bom mesmo não estaria falando de boa comigo"

Então sei lá, tem jogos que eu não gosto mas eu entendo pq as pessoas jogam.

Você ser acessível demais, não ter nariz empinado, até colocar preços acessíveis em produtos ou serviços que você venda parece que tem o efeito na maioria das vezes de fazer as pessoas desvalorizarem o que você tá criando ou vendendo.