Você pensa ativamente em segurança ao codificar?

Quando você está codificando, você pensa ativamente que seu código pode ser explorado de maneiras que ele não deveria originalmente e, assim, obter acesso a informações protegidas, executar comandos ou algo que você não gostaria que seus usuários fizessem?

Mais ou menos. Disclaimer: Eu sou um cara de segurança;)

Portanto, a maneira como trabalho é ter meu modelo de ameaças, que descreve que tipo de ataques e que tipo de invasores são mais prováveis. Isso ajuda a elaborar os requisitos de segurança. Quando na verdade estou codificando, pratico as práticas usuais de "codificação segura", como sendo cuidadoso para que as variáveis ​​do cursor estejam sempre dentro dos limites, a entrada contaminada seja higienizada e as condições de erro sejam tratadas. Depois, volto ao meu modelo de ameaças para ver quais módulos têm mais probabilidade de serem alvo de ataques; aqueles recebem uma revisão extra.

Eu uso práticas padrão da indústria, como o uso de parâmetros SQL. Uso plataformas "seguras", como o .NET Framework, e aproveito os recursos de segurança, como tokens anti-falsificação no ASP.NET MVC. Não escrevo meus próprios algoritmos de criptografia, mas entendo o que essas criptografias oferecem em termos de benefícios de segurança e quando preciso usá-los para obter esses benefícios.

Em resumo, uso as melhores práticas, mas não desenvolvo minhas próprias ferramentas de segurança. Eu não sou um especialista em segurança a esse respeito; Confio em outros especialistas em segurança, que provavelmente já pensaram profundamente sobre esses problemas e têm uma compreensão clara dos riscos e benefícios.

Minha abordagem fundamental à segurança, além de simplesmente usar ferramentas de segurança, é eliminar todas as entradas possíveis no sistema, exceto a que eu estou esperando. Se eu tiver um campo de número de segurança social, os únicos caracteres que realmente devem aparecer são dígitos e traços numéricos, em um padrão específico.

Valido a entrada do usuário no cliente e no servidor.

Absolutamente.

Segurança é tudo. E com software numérico, isso vale duas vezes.
Outro dia, um usuário conseguiu encontrar e explorar o bug em um dos meus programas antigos. O dano foi irreparável. Ver abaixo:

Costumava ser redondo.

Não, porque não trabalho em um domínio problemático em que a segurança é relevante (SW de visualização massiva de dados). Eu faço tem um monte de afirma no meu código (verificação de índice, a verificação de consistência, etc.), não por causa de preocupações com a segurança, mas porque eu como o código errado para travar mais cedo e bater visivelmente.

Absolutamente. Penso nas vulnerabilidades de injeção, e também como minha lógica de negócios funcionará em um ambiente de desktop versus um ambiente da web, e como a segurança é implementada nos dois tipos de ambientes.

Não sou especialista em segurança, mas quando estou codificando aplicativos da Web, sempre assumo que a entrada do usuário pode conter todo tipo de estranheza e sempre deve ser totalmente escapada e afins. Além disso, sou cuidadoso ao fazer chamadas do Ajax de volta ao servidor para verificar se o usuário está logado (se for para esse evento específico) e se eles têm permissões para fazer o que eles estão tentando fazer.

A base de código possui um conjunto de filtros para entradas. Eu nunca checo PHP $_GETou $_POSTmatrizes diretamente. Em vez disso, eu consultá-los através de uma função Request::get('parameter', 'filter')com filtros, como int, texte alguns outros. (E Request::post()para entradas do POST, é claro.)

Sim. Quando trabalhei em um jogo multiplayer, todos eram paranóicos de façanhas e maneiras de trapacear. Trapacear pode destruir um jogo totalmente, sem mencionar qualquer modelo de negócio conectado à venda de itens no jogo. Portanto, as preocupações com a segurança e as medidas anti-adulteração estavam muito na agenda. Eu gostei muito disso. Já trabalhei em outros projetos antes em que você se sentia culpado por trabalhar mais no código apenas para garantir que ele era seguro.

Sim. A segurança é importante e não deve ser uma reflexão tardia; adicionar segurança após o fato é geralmente mais difícil do que projetá-la no aplicativo, e se você a adicionar posteriormente, provavelmente perderá algumas coisas (ou simplesmente não se importará em adicioná-la).

Entenda os princípios gerais de segurança (integridade, autenticação, autoridade) e leia alguns livros sobre como as pessoas têm subvertido esses pilares de segurança há milênios e você estará na metade do caminho.

Depois, leia alguns bons livros sobre estratégias de design e teste e você aprenderá como projetar testabilidade em sua arquitetura.

Agora chegamos ao ponto em que penso em segurança. Estou pensando em como posso validar a fonte de dados, importa se os dados são adulterados, quem é a fonte de dados, qual a certeza disso? como poderia ter sido alterado etc ...

Isso afeta o design. Os arquivos de configuração podem ter seções principais criptografadas ou campos específicos podem estar em texto não criptografado com um campo de assinatura associado. As coisas ficam mais complexas com os serviços voltados para a Internet, pois você deve esperar um nível maior de hostilidade por lá.

Então, no teste, como você testa tudo isso. Quais são as entradas máximas de dados, o que acontece se você empurrar o software além desses limites, como ele lida com isso? Em que confia? como você pode fingir essa confiança?

Sim.

Eu lidei com hackers suficientes no passado para saber que eles estão constantemente tentando comprometer qualquer site grande, e existem bots suficientes por aí que até sites pequenos não são seguros.

Eu tento pensar como um hacker o tempo todo, até o ponto em que às vezes preocupo meus colegas de trabalho com comentários casuais sobre como os sistemas que tomamos como garantidos todos os dias podem ser utilizados.

Deve ser algo que qualquer desenvolvedor constrói no processo desde o início até um grau maior ou menor, dependendo da aplicação etc. Infelizmente, como os desenvolvedores não tendem a citar por segurança, os compradores não costumam pensar nisso ( Eu sei, isso é um pouco complicado, porque se os compradores quiserem a cotação mais barata, talvez ela não inclua segurança)

Como desenvolvedor, você pode obter uma vantagem definitiva se tiver experiência nessa área - estou pensando especificamente em bancos e serviços financeiros, mas outros setores também são aplicáveis. Atualmente, eles podem orçar 70 - 100k em treinamento para que um novo graduado seja atualizado com rapidez nos processos, segurança e outros detalhes específicos dessa organização. Se você pode salvá-los 30k disso, é um bom CV plus!

No Reino Unido, o Instituto de Profissionais de Segurança da Informação e, na Escócia, o Centro de Excelência em Segurança e Crime Cibernético estão trabalhando em estreita colaboração com as Universidades para ajudar a revisar os materiais do curso, fornecer palestras para convidados sobre as implicações do mundo real da má codificação e facilitar as colocações de verão (por exemplo, desenvolvedores de software inseridos em divisões de fraude na aplicação da lei.) A maioria das organizações de suporte está fazendo isso de graça, pois tem o potencial de economizar uma grande quantia de dinheiro - isso me parece valioso.

(aviso de isenção de responsabilidade - fui responsável pela segurança de várias organizações globais)