tiagocassio / capsize Goto Github PK

ID: CVS_00201.003

Categoria: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Reportado por: Tiago Cassio da Conceição

Projeto: tiagocassio/capsize

Criticidade:

Impacto: Alto

Probabilidade: Alto

Criticidade: Crítico

Padrões: [2010] A2 – Cross-Site Scripting (XSS), CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Descrição: A vulnerabilidade de Cross-Site Scripting (XSS) possibilita a um atacante obter informações sensíveis de uma determinada aplicação, além de permitir o acesso não autorizado e a execução de fraudes. A exploração do XSS dá-se através da injeção de código malicioso no escopo da aplicação, fazendo com que a vítima execute tal código e envie para o atacante informações sigilosas e que possibilitam a tomada de controle da aplicação.

Descrição do Impacto: Aguardando preenchimento

Solução: O primeiro passo no intuito de mitigar os problemas de XSS consiste em identificar todos os pontos da aplicação onde dados fornecidos pelo usuário são utilizados na construção de páginas de resposta. Esse procedimento de identificação deve incluir não apenas os pontos onde os dados provenientes de uma determinada requisição são copiados diretamente para as páginas de resposta, mas deve considerar também, qualquer ponto onde os dado fornecidos pelo usuário.
Recomenda-se que a validação que obedece o fluxo de entrada de dados seja feita com base no contexto das informações que estão sendo recebidas, por exemplo, campos numéricos devem receber aceitar estritamente caracteres numéricos, rejeitando a princípio qualquer outro conjunto de caracteres diferente do qual a aplicação espera. Esse mesmo procedimento deve ser seguido para outros campos de formulário de acordo com o tipo de informação que a aplicação deseja aceitar: nomes, endereços de e-mail, telefones, entre outros. Esse objetivo pode ser alcançado empregando expressões regulares a fim de filtrar conjuntos de caracteres considerados indesejados com base no contexto das informações recebidas. Com relação à validação que segue o fluxo de saída dos dados da aplicação, quando as informações são efetivamente utilizadas para construir as respostas, deve-se garantir que caracteres potencialmente maliciosos sejam substituídos conforme proposto pelas sequências de escape definidas no HTML. Um conjunto bem definido de HTML entities deve ser utilizado para substituir caracteres literais conforme indicado a seguir:
caractere “ por &quot;caractere ‘ por &apos;caractere & por &amp;caractere < por &lt;caractere > por &gt;
Como forma de atingir excelência no que concerne a criação de filtros, recomenda-se fortemente adotar a codificação em HTML para qualquer caractere que não pertença ao conjunto dos alfanuméricos, incluindo caracteres de espaço em branco (whitespace).
Para correção de DOM-based XSS, é preciso seguir algumas regras conforme descritas neste guia. Essas regras dizem respeito ao cuidado em fazer uso de dados do usuário, que podem conter elementos HTML ou código JavaScript, em elementos do ambiente DOM como atributos, "event handler", funções entre outros.

Referência: https://www.owasp.org/index.php/DOM_Based_XSS
https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
http://cwe.mitre.org/data/definitions/79.html
https://www.owasp.org/index.php/Cross_Site_Scripting_Flaw
 

Tipo de falha:

**Protocolo:**http

**Método:**GET

**URL:**http://localhost

Parametros:

TESTE

Passo a Passo:

TESTE

**Requisição:**TESTE

**Resposta:**TESTE

Defect Tracker: https://app.conviso.com.br/scopes/11/projects/3924

ID: CVS_00201.002

Categoria: CWE-592: Authentication Bypass Issues

Reportado por: Tiago Cassio da Conceição

Projeto: tiagocassio/capsize

Criticidade:

Impacto: Alto

Probabilidade: Médio

Criticidade: Alto

Padrões: N/A, CWE-306 Missing Authentication for Critical Function

Descrição: Problema de segurança que ocorre quando um atacante tem acesso à uma área restrita. Esse acesso pode ter sido obtido pela exploração de uma ou mais falhas no sistema, como também por falhas na configuração de restrição de acesso (Firewall). Ataques direcionados para usuários da aplicação também podem ocasionar a obtenção deste acesso.

Descrição do Impacto: Aguardando preenchimento

Solução: Mitigar as vulnerabilidades/configurações que permitiram o acesso indevido.

Referência: https://www.owasp.org/index.php/Category:Sensitive_Data_Protection_Vulnerability
https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure
 

Tipo de falha:

Código:[7]

Entrada de dados:

Saída de dados:

Defect Tracker: https://app.conviso.com.br/scopes/11/projects/3924

ID: CVS_00201.004

Categoria: Uncategorized

Reportado por: Tiago Cassio da Conceição

Projeto: tiagocassio/capsize

Criticidade:

Impacto: Alto

Probabilidade: Alto

Criticidade: Crítico

Padrões: N/A

Descrição: O controle de acesso físico não é efetivo ou pode ter partes críticas desse processo parcial ou completamente subvertidas. Uma vez que uma das partes apresentem fragilidades ou sejam constituídas de funcionalidades que são suscetíveis a abuso, o controle de acesso físico pode ser considerado deficiente.
 

Descrição do Impacto: Aguardando preenchimento

Solução: Dada a criticidade do controle analisado, recomenda-se que algumas ações sejam consideradas para a fim de tornar o controle de acesso efetivo, como esperado:

Validação do RG do visitante: embora possa não ser um procedimento trivial em alguns casos, seria uma verificação importante, uma vez que de alguma maneira está relacionado ao perfil do visitante e às suas ações nas dependências da empresa em questão.

Validação da devolução do crachá: Se o crachá deve ser depositado nos controles de acesso ao se deixar as dependências da empresa, isso é devido a uma camada de segurança que funciona de acordo com a seguinte lógica: se o crachá não é devolvido na catraca/dispositivo de controle de acesso (no local específico no dispositivo) para liberar a saída, uma vez que o mesmo não pode ser lido pelo dispositivo, o usuário pode ter perdido o crachá ou ter entrado sem ele e ambos os casos merecem a atenção dos recepcionistas e seguranças locais. Logo é de suma importância que não somente a entrada, mas também a saída sejam controladas com rigor, o que requer que o sistema possa detectar que o crachá foi de fato depositado e devolvido no dispositivo e não somente realizada uma leitura para verificar a presença do crachá. 

Sistemas integrados: o ideal é que o sistema de registro trabalhe de maneira integrada, possibilitando que os recepectionistas de diversas entradas distintas do prédio, caso se aplique, possam consultar se o visitante devolveu o último crachá recebido, e também que o número do crachá seja associado ao nome/RG daquele visitante. Importante enfatizar que mesmo que o crachá permaneça válido somente no dia da solicitação, temos ainda um cenário onde um ataque coordenado visa impactar no fluxo e atendimento, o que pode auxiliar em outras ações.

Treinamento: Recepcionistas e seguranças devem ser treinados quanto aos riscos desse tipo de abordagem. Embora os critérios normalmente utilizados para se identificar e um mitigar um perigo físico "tradicional" tenham sua efetividade, o fato é que nesse caso estamos lidando com um híbrido, onde através do abuso de deficiencias e fragilidades em dispositivos e (talvez na cultura da empresa) se consegue burlar certos controles. 

Referência: http://resources.infosecinstitute.com/physical-access-control/
https://silentbreaksecurity.com/services/physical-penetration-testing/
 
 

Tipo de falha:

**Protocolo:**http

**Método:**GET

**URL:**http://testete

Parametros:

teste

Passo a Passo:

teste

**Requisição:**teste

**Resposta:**teste

Defect Tracker: https://app.conviso.com.br/scopes/11/projects/3924