Quais são as atenuações para todas as vulnerabilidades do top 10 da owasp?

Aqui, é a descrição detalhada dada abaixo que pode ser considerada a fim de assumir todas as vulnerabilidades que estão listadas no OWASP Top 10 e também para satisfazer o entrevistador.

1. Prevenir Ataques de Injeção:
   1. A maneira mais simples de proteger contra a injeção é evitar o acesso a intérpretes externos sempre que possível. Para muitos comandos shell e algumas chamadas de sistema, existem bibliotecas específicas de linguagem que executam as mesmas funções. Usar tais bibliotecas não envolve o interpretador shell do sistema operacional e, portanto, evita um grande número de problemas com comandos shell.
   2. li> Outra forte proteção contra a injeção de comandos é garantir que a aplicação web execute apenas com os privilégios que ela absolutamente precisa para executar sua função. Portanto, você não deve executar o webserver como root ou acessar um banco de dados como DBADMIN, caso contrário um atacante pode abusar desses privilégios administrativos concedidos à aplicação web. Alguns dos ambientes J2EE permitem o uso do Java sandbox, que pode impedir a execução dos comandos do sistema.
2. Building a proper authentication and session management:
   1. Cuidado e adequado uso de mecanismos de autenticação personalizados ou fora da prateleira e gerenciamento de sessão deve reduzir significativamente a probabilidade de um problema nesta área. Definir e documentar a política do seu site com respeito ao gerenciamento seguro das credenciais dos usuários é um bom primeiro passo. Garantir que a sua implementação aplique de forma consistente esta política é fundamental para ter uma autenticação segura e robusta e um mecanismo de gerenciamento de sessão. Algumas áreas críticas incluem::>ol>>li>Controles de mudança de senha>li>Li>O uso da senhaLi>Força da senhaLi>Armazenamento de senhaLi>Proteger credenciais em trânsitoLi>Proteção de ID de sessãoLi>Lista de contasLi>Caching do navegador/ol>>Li>Prevenir o uso de scripts cross-site:melhor maneira de proteger uma aplicação web contra ataques XSS é garantir que sua aplicação execute a validação de todos os cabeçalhos, cookies, strings de consulta, campos de formulário e campos ocultos (i.e., todos os parâmetros) contra uma especificação rigorosa do que deve ser permitido. A validação não deve tentar identificar o conteúdo ativo e removê-lo, filtrá-lo ou higienizá-lo. Existem muitos tipos de conteúdo ativo e muitas maneiras de codificá-lo para contornar filtros para tal conteúdo. Nós recomendamos fortemente uma política de segurança 'positiva' que especifique o que é permitido. Políticas 'negativas' ou baseadas em assinaturas de ataque são difíceis de manter e provavelmente estão incompletas. A codificação de saída fornecida pelo usuário também pode derrotar as vulnerabilidades do XSS, impedindo que scripts inseridos sejam transmitidos aos usuários em uma forma executável. Aplicações podem ganhar proteção significativa contra ataques baseados em javascript ao converter os seguintes caracteres em toda a saída gerada para a codificação apropriada da entidade HTML, como < < > > (( )) #&\ / ' "
3. Prevenir referências inseguras a objectos directos:
   1. >li> A melhor protecção é evitar a exposição de referências a objectos directos aos utilizadores, utilizando um índice, um mapa de referência indirecto ou outro método indirecto que seja fácil de validar. Se uma referência a objetos diretos deve ser usada, certifique-se de que o usuário está autorizado antes de usá-la.
   2. Estabelecer uma forma padrão de referência a objetos de aplicação é importante:
      1. Evite expor suas referências a objetos privados aos usuários sempre que possível, tais como chaves primárias ou nomes de arquivos>li>Validar qualquer referência a objetos privados extensivamente com uma abordagem de "aceitar bem conhecido">li>Verificar autorização para todos os objetos referenciados
   >li>Guia de configuração de segurança básica:primeiro passo é criar um guia de endurecimento para a configuração particular do seu servidor web e servidor de aplicações. Esta configuração deve ser usada em todos os hosts rodando a aplicação e também no ambiente de desenvolvimento. Recomendamos começar com qualquer orientação existente que possa encontrar no seu fornecedor ou aquelas disponíveis nas várias organizações de segurança existentes, como OWASP, CERT e SANS e depois adaptá-las às suas necessidades particulares. O guia de endurecimento deve incluir os seguintes tópicos:
   1. Configurar todos os mecanismos de segurança>li>Li>Desligar todos os serviços não utilizadosLi>Configurar funções, permissões, contas, senhasLi>Li>Logging and alerts
   >Li>Proteger dados sensíveis:>Li>Li> A maneira mais fácil de proteger contra falhas criptográficas é minimizar o uso de criptografia e manter apenas as informações que são absolutamente necessárias. Por exemplo, em vez de criptografar números de cartão de crédito e armazená-los, basta requerer que os usuários reinsiram os números. Além disso, em vez de armazenar senhas criptografadas, use uma função unidirecional, como SHA-1, para hash das senhas.
4. Se a criptografia precisar ser usada, escolha uma biblioteca que tenha sido exposta ao escrutínio público e certifique-se de que não haja vulnerabilidades abertas. Encapsule as funções criptográficas que são utilizadas e reveja o código cuidadosamente. Certifique-se de que segredos, tais como chaves, certificados e senhas, sejam armazenados com segurança. Para dificultar a tarefa de um atacante, o segredo principal deve ser dividido em pelo menos dois locais e montado em tempo de execução. Tais locais podem incluir um arquivo de configuração, um servidor externo ou dentro do próprio código.

Controle de acesso de nível de função segura:

1. >li>Capturar as regras>li>Label todos os recursos e funções>li>Label todos os usuários

>li>Prevenir o CSRF:

1. >li>Prevenir o CSRF requer a inclusão de um token imprevisível no corpo ou URL de cada solicitação HTTP. Tais tokens devem no mínimo ser únicos por sessão do usuário, mas também podem ser únicos por pedido.
2. li> A opção preferida é incluir o token único em um campo oculto. Isso faz com que o valor seja enviado no corpo do pedido HTTP, evitando sua inclusão na URL, que está sujeita à exposição.
3. O token único também pode ser incluído na própria URL, ou em um parâmetro URL. Entretanto, tal colocação corre o risco de que a URL seja exposta a um atacante, comprometendo assim o token secreto.

Onde procurar vulnerabilidades em componentes de terceiros conhecidos:

1. >li>Keep atualize todas as aplicações e componentes de terceiros
2. Localize vulnerabilidades em qualquer das versões apropriadas de componentes em Exploit-db, vulndb, CVE, etc.
3. Update to other required versions as per the vulnerability mitigations and recommendations.
4. Where appropriate, consider adding security wrappers around components to disable unused functionality and/ or secure weak or vulnerable aspects of the component.

Redirect validation:

1. Simply avoid using redirects and forwards.
2. If used, don’t involve user parameters in calculating the destination. This can usually be done.
3. If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.

Hiren Patel (Pune, MH)