2.1 CVE-2012-1629
A vulnerabilidade de script entre sites (XSS) no módulo Taxotouch para Drupal permite que usuários remotos autenticados com certas permissões injetem script da web arbitrário ou HTML por meio de vetores não especificados.
https://nvd.nist.gov/vuln/detail/CVE-2012-1629
Categorias
CWE-79 : Neutralização imprópria de entrada durante a geração da página da Web ('Cross-site Scripting')
O produto não neutraliza ou neutraliza incorrectamente a entrada controlável pelo utilizador antes de ser colocado na saída que é utilizada como uma página web que é servida a outros utilizadores. Uma abreviatura comum para "Cross-Site Scripting". Usado como sinónimo de armazenado (Tipo 2) XSS. Nos primeiros anos após a descoberta inicial do XSS, "CSS" era uma abreviatura comummente utilizada. No entanto, isto causaria confusão com "Cascading Style Sheets", pelo que a utilização deste acrónimo tem diminuído significativamente. Usar ferramentas de análise estática automatizada que visam este tipo de fraqueza. Muitas técnicas modernas utilizam a análise do fluxo de dados para minimizar o número de falsos positivos. Esta não é uma solução perfeita, uma vez que 100% de precisão e cobertura não são viáveis, especialmente quando estão envolvidos múltiplos componentes. Use a Folha de Dados XSS [REF-714] ou ferramentas automatizadas de geração de testes para ajudar a lançar uma grande variedade de ataques contra a sua aplicação web. A Folha de Consulta contém muitas variações XSS subtis que são especificamente direccionadas contra defesas XSS fracas. Compreenda todas as áreas potenciais onde entradas não confiáveis podem introduzir o seu software: parâmetros ou argumentos, cookies, qualquer coisa lida a partir da rede, variáveis de ambiente, pesquisa de DNS invertido, resultados de consultas, cabeçalhos de pedidos, componentes URL, e-mail, ficheiros, nomes de ficheiros, bases de dados, e quaisquer sistemas externos que forneçam dados à aplicação. Lembre-se de que tais entradas podem ser obtidas indirectamente através de chamadas API. Para quaisquer verificações de segurança que sejam realizadas do lado do cliente, assegurar que estas verificações sejam duplicadas do lado do servidor, a fim de evitar a CWE-602. Os atacantes podem contornar as verificações do lado do cliente, modificando os valores após as verificações terem sido executadas, ou alterando o cliente para remover completamente as verificações do lado do cliente. Então, estes valores modificados seriam submetidos ao servidor. Se estiverem disponíveis, utilizar mecanismos estruturados que automaticamente imponham a separação entre os dados e o código. Estes mecanismos podem ser capazes de fornecer automaticamente a citação, codificação e validação relevantes, em vez de dependerem do programador para fornecer esta capacidade em todos os pontos onde a saída é gerada. Com Struts, escrever todos os dados dos feijões de formulário com o atributo de filtro do feijão definido como verdadeiro. Para ajudar a mitigar os ataques XSS contra o cookie de sessão do utilizador, definir o cookie de sessão para ser HttpOnly. Em navegadores que suportam a funcionalidade HttpOnly (como as versões mais recentes do Internet Explorer e Firefox), este atributo pode impedir que o cookie de sessão do utilizador seja acessível a scripts maliciosos do lado do cliente que utilizam document.cookie. Esta não é uma solução completa, uma vez que o HttpOnly não é suportado por todos os navegadores. Mais importante ainda, XMLHTTPRequest e outras tecnologias de browser poderosas fornecem acesso de leitura aos cabeçalhos HTTP, incluindo o cabeçalho Set-Cookie no qual a bandeira HttpOnly está definida. Quando o conjunto de objectos aceitáveis, tais como nomes de ficheiros ou URLs, é limitado ou conhecido, criar um mapeamento a partir de um conjunto de valores de entrada fixos (tais como IDs numéricos) para os nomes de ficheiros ou URLs reais, e rejeitar todas as outras entradas. Utilizar uma firewall de aplicação que possa detectar ataques contra esta fraqueza. Pode ser benéfico nos casos em que o código não pode ser fixado (porque é controlado por um terceiro), como medida de prevenção de emergência enquanto são aplicadas medidas de garantia de software mais abrangentes, ou para fornecer defesa em profundidade. Ao utilizar PHP, configurar a aplicação de modo a que não utilize register_globals. Durante a implementação, desenvolver a aplicação de modo a que não confie nesta característica, mas tenha cuidado ao implementar uma emulação register_globals que esteja sujeita a pontos fracos como CWE-95, CWE-621, e questões semelhantes. O Gestor da Biblioteca Python não neutralizou suficientemente um termo de pesquisa fornecido pelo utilizador, permitindo o XSS reflectido. A plataforma de comércio electrónico baseada em Python não escapou ao conteúdo devolvido nas páginas de erro, permitindo ataques de "Cross-Site Scripting" reflectidos. XSS universal no sistema operativo móvel, tal como explorado na natureza por CISA KEV. Cadeia: validação de entrada imprópria (CWE-20) no produto de firewall leva ao XSS (CWE-79), tal como explorado na natureza por CISA KEV. Admin GUI permite XSS através de cookie. O programa de estatísticas da Web permite XSS através de cabeçalhos HTTP criados. O produto de análise de registo Web permite XSS através de cabeçalho HTTP Referer criado. Chain: falha do mecanismo de protecção permite XSS Chain: denylist incompleto (CWE-184) apenas verifica a tag "javascript:", permitindo XSS (CWE-79) usando outras tags Chain: denylist incompleto (CWE-184) apenas remove tags SCRIPT, permitindo XSS (CWE-79) XSS reflectido usando a tag PATH_INFO num URL Reflected XSS não tratado correctamente ao gerar uma mensagem de erro XSS reflectido enviado através de mensagem de correio electrónico. XSS armazenado num produto de segurança. Armazenou XSS usando uma página wiki. Armazenou XSS numa aplicação do livro de visitas. Armazenou XSS numa aplicação do livro de visitas utilizando um javascript: URI numa etiqueta bbcode img. Chain: ficheiro de biblioteca não está protegido contra um pedido directo (CWE-425), levando ao reflectido XSS (CWE-79).
Referências
CPE
| cpe |
começar |
fim |
| Configuration 1 |
| cpe:2.3:a:dmitry_loac:taxotouch:-:*:*:*:*:*:*:* |
|
|
| Running on/with |
| cpe:2.3:a:drupal:drupal:-:*:*:*:*:*:*:* |
|
|
REMEDIAÇÃO
EXPLOITS
Exploit-db.com
| id |
descrição |
datado |
|
| Nenhum exploit conhecido |
Outros (github, ...)
| Url |
| Nenhum exploit conhecido |
CAPEC
Common Attack Pattern Enumerations and Classifications
| id |
descrição |
gravidade |
| 209 |
XSS usando incompatibilidade de tipo MIME
Um adversário cria um arquivo com conteúdo de script, mas onde o tipo MIME especificado do arquivo é tal que o script não é esperado. O adversário engana a vítima para acessar um URL que responde com o arquivo de script. Alguns navegadores detectarão que o tipo MIME especificado do ficheiro não corresponde ao tipo real do seu conteúdo e mudarão automaticamente para o tipo de conteúdo real utilizando um intérprete. Se o navegador não invocar filtros de script antes de fazer isso, o script do adversário pode ser executado no alvo não digitalizado, possivelmente revelando os cookies da vítima ou executando script arbitrário em seu navegador. Usando um navegador ou uma ferramenta automatizada, um adversário segue todos os links e ações públicas em um site da Web. Eles registram todas as áreas que permitem que um usuário carregue conteúdo através de uma solicitação HTTP POST. Isto é normalmente encontrado em blogs ou fóruns. O adversário usa os pontos de entrada reunidos na fase "Explore" como uma lista de alvos e faz upload de arquivos com conteúdo de script, mas cujo tipo MIME é especificado como um tipo de arquivo que não pode executar conteúdo de script. Se o aplicativo verificar apenas o tipo MIME do arquivo, ele pode deixar o arquivo passar, fazendo com que o script seja executado por qualquer usuário que acesse o arquivo. Uma vez que o adversário tenha determinado quais locais de carregamento de arquivo são vulneráveis ao descasamento do tipo MIME, ele carregará um script malicioso disfarçado como um arquivo não scripting. O adversário pode ter muitos objetivos, desde roubar IDs de sessão, cookies, credenciais e conteúdo de página de uma vítima. Para que o ataque seja bem-sucedido, a vítima precisa visualizar o conteúdo malicioso armazenado na página da web. |
Média |
| 588 |
XSS baseado em DOM
Este tipo de ataque é uma forma de Cross-Site Scripting (XSS) onde um script malicioso é inserido no HTML do lado do cliente sendo analisado por um web browser. O conteúdo servido por uma aplicação web vulnerável inclui código de script usado para manipular o Document Object Model (DOM). Este código de script ou não valida corretamente a entrada, ou não executa a codificação de saída apropriada, criando assim uma oportunidade para um adversário injetar um script malicioso para lançar um ataque XSS. Uma distinção chave entre outros ataques XSS e ataques baseados em DOM é que em outros ataques XSS, o script malicioso é executado quando a página da Web vulnerável é carregada inicialmente, enquanto um ataque baseado em DOM é executado algum tempo depois que a página é carregada. Outra distinção entre ataques baseados em DOM é que em alguns casos, o script malicioso nunca é enviado para o servidor vulnerável da web. Um ataque como este é garantido para contornar qualquer tentativa de filtragem do lado do servidor para proteger os usuários. Usando um navegador ou uma ferramenta automatizada, um adversário segue todos os links e ações públicas em um site da Web. Eles registram todos os links, os formulários, os recursos acessados e todos os outros pontos de entrada potenciais para a aplicação web. O adversário usa os pontos de entrada reunidos na fase "Explore" como uma lista de alvos e injeta várias cargas úteis e caracteres especiais de script comuns para determinar se um ponto de entrada realmente representa uma vulnerabilidade e para caracterizar a extensão em que a vulnerabilidade pode ser explorada. Especificamente para o XSS baseado em DOM, o adversário está à procura de áreas onde o input está a ser usado para alterar directamente o DOM. Uma vez que o adversário tenha determinado quais parâmetros são vulneráveis ao XSS, ele irá criar um URL malicioso contendo a exploração do XSS. O adversário pode ter muitos objetivos, desde roubar IDs de sessão, cookies, credenciais e conteúdo de página da vítima. No XSS baseado em DOM, o script malicioso pode nem sequer ser enviado para o servidor, uma vez que o navegador da vítima irá manipular o próprio DOM. Isso pode ajudar a evitar mecanismos de detecção do lado do servidor. Para que o ataque seja bem-sucedido, a vítima precisa acessar o URL malicioso. |
Muito alto |
| 591 |
XSS refletido
Este tipo de ataque é uma forma de Cross-Site Scripting (XSS) onde um script malicioso é "refletido" de uma aplicação web vulnerável e depois executado por um navegador da vítima. O processo começa com um adversário entregando um script malicioso a uma vítima e convencendo a vítima a enviar o script para a aplicação web vulnerável. Usando um navegador ou uma ferramenta automatizada, um adversário segue todos os links e ações públicas em um site da web. Eles registram todos os links, os formulários, os recursos acessados e todos os outros pontos de entrada potenciais para a aplicação web. O adversário usa os pontos de entrada reunidos na fase "Explore" como uma lista de alvos e injeta várias cargas úteis e caracteres especiais para determinar se um ponto de entrada realmente representa uma vulnerabilidade e para caracterizar até que ponto a vulnerabilidade pode ser explorada. Uma vez que o adversário tenha determinado quais parâmetros são vulneráveis ao XSS, ele irá criar um URL malicioso contendo a exploração XSS. O adversário pode ter muitos objetivos, desde roubar IDs de sessão, cookies, credenciais e conteúdo de página da vítima. Para que o ataque seja bem-sucedido, a vítima precisa acessar o URL malicioso. |
Muito alto |
| 592 |
XSS armazenado
Um adversário utiliza uma forma de Cross-site Scripting (XSS) onde um script malicioso é persistentemente "armazenado" dentro do armazenamento de dados de uma aplicação web vulnerável como entrada válida. [Usando um navegador ou uma ferramenta automatizada, um adversário segue todas as ligações e acções públicas de um sítio web. Eles registam todas as ligações, os formulários, os recursos acedidos e todos os outros potenciais pontos de entrada para a aplicação web. O adversário procura áreas onde são armazenadas entradas do utilizador, tais como perfis de utilizador, carrinhos de compras, gestores de ficheiros, fóruns, blogs, e registos. [O adversário utiliza os pontos de entrada reunidos na fase "Explorar" como uma lista de alvos e injecta várias cargas úteis e caracteres especiais comuns para determinar se um ponto de entrada representa realmente uma vulnerabilidade e para caracterizar até que ponto a vulnerabilidade pode ser explorada. [Armazenar conteúdo XSS malicioso] Uma vez que o adversário tenha determinado quais os locais armazenados que são vulneráveis ao XSS, eles irão interagir com a aplicação web para armazenar o conteúdo malicioso. O adversário pode ter muitos objectivos, desde roubar IDs de sessão, cookies, credenciais, e conteúdo de página de uma vítima. [Para que o ataque seja bem sucedido, a vítima precisa de ver o conteúdo malicioso armazenado na página web. |
Muito alto |
| 63 |
Cross-Site Scripting (XSS)
Um adversário incorpora scripts maliciosos em conteúdos que serão servidos aos navegadores de internet. O objetivo do ataque é que o software alvo, o browser do lado do cliente, execute o script com o nível de privilégio do usuário. Um ataque deste tipo explora as vulnerabilidades de um programa que são trazidas ao permitir que hosts remotos executem código e scripts. Navegadores web, por exemplo, têm alguns controles de segurança simples, mas se um atacante remoto tem permissão para executar scripts (injetando-os em conteúdo gerado pelo usuário, como quadros de avisos), então esses controles podem ser contornados. Além disso, estes ataques são muito difíceis de detectar para um usuário final. Usando um navegador ou uma ferramenta automatizada, um atacante segue todos os links e ações públicas em um site da web. Eles registram todos os links, os formulários, os recursos acessados e todos os outros pontos de entrada potenciais para a aplicação web. O atacante usa os pontos de entrada reunidos na fase "Explore" como uma lista de alvos e injecta várias cargas úteis de script comuns para determinar se um ponto de entrada realmente representa uma vulnerabilidade e para caracterizar até que ponto a vulnerabilidade pode ser explorada. Como o atacante consegue explorar a vulnerabilidade, ele pode optar por roubar as credenciais do usuário para reutilizá-las ou analisá-las posteriormente. [Navegação forçada] Quando o atacante ataca o aplicativo atual ou outro (através de vulnerabilidades do CSRF), o usuário será então aquele que executa os ataques sem estar ciente disso. Estes ataques são na maioria das vezes direcionados a falhas de lógica da aplicação, mas também podem ser usados para criar um ataque generalizado contra um determinado site na rede atual do usuário (Internet ou não). Ao manipular o conteúdo, o atacante visa as informações que o usuário gostaria de obter do site. |
Muito alto |
| 85 |
AJAX Footprinting
Este ataque utiliza as frequentes viagens de ida e volta cliente-servidor na conversa Ajax para digitalizar um sistema. Embora o Ajax não abra novas vulnerabilidades per se, ele as otimiza do ponto de vista de um atacante. Um primeiro passo comum para um atacante é pegar o rastro do ambiente alvo para entender que ataques irão funcionar. Como a pegada baseia-se na enumeração, o padrão de conversa de solicitações e respostas rápidas e múltiplas que são típicas nos aplicativos Ajax permitem que um atacante procure por muitas vulnerabilidades, portas conhecidas, localizações de rede e assim por diante. O conhecimento adquirido através do Ajax fingerprinting pode ser usado para suportar outros ataques, como o XSS. Usando um navegador ou uma ferramenta automatizada, um adversário envia solicitações para uma página da Web e registra a resposta HTML recebida. Os adversários então analisam o HTML para identificar quaisquer arquiteturas JavaScript subjacentes conhecidas. Isso pode ajudar no mapepiong vulnerabilidades conhecidas publicamente para a página web e também pode ajudar o adversário a adivinhar a arquitetura da aplicação e o funcionamento interno de um sistema. |
Baixo |
MITRE
Sherlock® flash
Tire uma foto da sua rede informática em poucos cliques !
A solução de auditoria Sherlock® flash permite-lhe realizar uma auditoria para reforçar a segurança dos seus activos informáticos. Vulnerabilidade do seu equipamento físico e virtual. Planeamento de correcções por nível de prioridade e tempo disponível. Relatórios detalhados e intuitivos.
Descubra esta oferta
