Reino: Input Validation and Representation

Problemas de validação e representação da entrada são causados por metacaracteres, codificações alternativas e representações numéricas. Confiar na entrada resulta em problemas de segurança. Os problemas incluem: “Buffer Overflows”, ataques de “Cross-Site Scripting”, “SQL Injection”, entre outros.

175 itens encontrados
Vulnerabilidades
Abstract
Concatenar uma entrada não validada em uma conexão de banco de dados pode permitir que um invasor substitua o valor de um parâmetro de solicitação. Um invasor pode ser capaz de substituir os valores dos parâmetros existentes, injetar um novo parâmetro ou explorar variáveis fora de um alcance direto.
Explanation
Ataques de Connection String Parameter Pollution (CSPP) consistem em injetar parâmetros de cadeia de conexão em outros parâmetros existentes. Essa vulnerabilidade é semelhante a outras vulnerabilidades, e é talvez mais bem conhecida que, em ambientes HTTP nos quais a poluição de parâmetros também pode ocorrer. No entanto, também pode se aplicar a outros lugares, como cadeias de conexão do banco de dados. Se um aplicativo não limpar a entrada do usuário adequadamente, um usuário malicioso poderá comprometer a lógica do aplicativo para executar ataques: de roubo de credenciais até a recuperação de todo o banco de dados. Ao enviar parâmetros adicionais para uma aplicativo, e se esses parâmetros tiverem o mesmo nome de um parâmetro existente, a conexão de banco de dados poderá reagir de uma das seguintes maneiras:

Ela poderá obter somente os dados do primeiro parâmetro
Ela poderá obter os dados do último parâmetro
Ela poderá obter os dados de todos os parâmetros e concatená-los

Isso pode depender do driver utilizado, do tipo de banco de dados ou até mesmo de como as APIs são utilizadas.

Exemplo 1: Este código usa entradas de uma solicitação HTTP para se conectar a um banco de dados:


...
string password = Request.Form["db_pass"]; //gets POST parameter 'db_pass'
SqlConnection DBconn = new SqlConnection("Data Source = myDataSource; Initial Catalog = db; User ID = myUsername; Password = " + password + ";");
...


Neste exemplo, o programador não considerou que um invasor poderia fornecer um parâmetro db_pass, como:
"xxx; Integrated Security = true", a cadeia de conexão se torna:

"Data Source = myDataSource; Initial Catalog = db; User ID = myUsername; Password = xxx; Integrated Security = true; "

Isso fará com que o aplicativo se conecte ao banco de dados usando a conta do sistema operacional sob a qual o aplicativo está em execução para ignorar a autenticação normal. Isso significaria que o atacante conseguiu se conectar ao banco de dados sem uma senha válida e realizar consultas diretamente no banco de dados.
References
[1] Chema Alonso, Manuel Fernandez, Alejandro Martin and Antonio Guzmán Connection String Parameter Pollution Attacks
[2] Eric P. Maurice A New Threat To Web Applications: Connection String Parameter Pollution (CSPP)
desc.dataflow.dotnet.connection_string_parameter_pollution
Abstract
Concatenar uma entrada não validada em uma conexão de banco de dados pode permitir que um invasor substitua o valor de um parâmetro de solicitação. Um invasor pode substituir os valores de parâmetros existentes, injetar um novo parâmetro ou explorar variáveis fora do alcance direto.
Explanation
Ataques de Connection String Parameter Pollution (CSPP) consistem em injetar parâmetros de cadeia de conexão em outros parâmetros existentes. Essa vulnerabilidade é semelhante a outras vulnerabilidades, e é talvez mais bem conhecida que, em ambientes HTTP nos quais a poluição de parâmetros também pode ocorrer. No entanto, também pode se aplicar a outros lugares, como cadeias de conexão do banco de dados. Se um aplicativo não limpar a entrada do usuário adequadamente, um usuário malicioso poderá comprometer a lógica do aplicativo para executar ataques: de roubo de credenciais até a recuperação de todo o banco de dados. Enviando parâmetros adicionais com o mesmo nome que um parâmetro existente para um aplicativo, o banco de dados pode reagir de uma das seguintes maneiras:

Pode usar apenas os dados do primeiro parâmetro
Pode usar os dados do último parâmetro
Pode usar os dados de todos os parâmetros e concatená-los juntos

Isso depende do driver usado, do tipo de banco de dados ou até mesmo de como as APIs são usadas.


Exemplo 1: Este código usa entradas de uma solicitação HTTP para se conectar a um banco de dados:


...
password := request.FormValue("db_pass")
db, err := sql.Open("mysql", "user:" + password + "@/dbname")
...


Neste exemplo, o programador não considerou que um invasor poderia fornecer um parâmetro db_pass, como:
"xxx@/attackerdb?foo=" então a cadeia de conexão se torna:

"user:xxx@/attackerdb?foo=/dbname"

Isso fará com que o aplicativo se conecte a um banco de dados controlado pelo invasor, permitindo que ele controle quais dados são retornados ao aplicativo.
References
[1] Chema Alonso, Manuel Fernandez, Alejandro Martin and Antonio Guzmán Connection String Parameter Pollution Attacks
desc.dataflow.golang.connection_string_parameter_pollution
Abstract
Concatenar uma entrada não validada em uma conexão de banco de dados pode permitir que um invasor substitua o valor de um parâmetro de solicitação. Um invasor pode ser capaz de substituir os valores dos parâmetros existentes, injetar um novo parâmetro ou explorar variáveis fora de um alcance direto.
Explanation
Ataques de Connection String Parameter Pollution (CSPP) consistem em injetar parâmetros de cadeia de conexão em outros parâmetros existentes. Essa vulnerabilidade é semelhante a outras vulnerabilidades, e é talvez mais bem conhecida que, em ambientes HTTP nos quais a poluição de parâmetros também pode ocorrer. No entanto, também pode se aplicar a outros lugares, como cadeias de conexão do banco de dados. Se um aplicativo não limpar a entrada do usuário adequadamente, um usuário malicioso poderá comprometer a lógica do aplicativo para executar ataques: de roubo de credenciais até a recuperação de todo o banco de dados. Ao enviar parâmetros adicionais para uma aplicativo, e se esses parâmetros tiverem o mesmo nome de um parâmetro existente, a conexão de banco de dados poderá reagir de uma das seguintes maneiras:

Ela poderá obter apenas os dados do primeiro parâmetro
Poderá obter os dados do último parâmetro
Poderá obter os dados de todos os parâmetros e concatená-los

Isto pode depender da unidade utilizada, do tipo de base de dados, ou mesmo de como as APIs são utilizadas.

Exemplo 1: Este código usa entradas de uma solicitação HTTP para se conectar a um banco de dados:


username = req.field('username')
password = req.field('password')
...
client = MongoClient('mongodb://%s:%s@aMongoDBInstance.com/?ssl=true' % (username, password))
...


Neste exemplo, o programador não considerou que um invasor poderia fornecer um parâmetro password, como:
"myPassword@aMongoDBInstance.com/?ssl=false&", em seguida, a string de conexão se torna (considerando um nome de usuário "scott"):

"mongodb://scott:myPassword@aMongoDBInstance.com/?ssl=false&@aMongoDBInstance.com/?ssl=true"

Isso fará com que "@aMongoDBInstance.com/?ssl=true" seja tratado como um argumento inválido adicional, ignorando "ssl=true" e conectando-se ao banco de dados sem criptografia.
References
[1] Chema Alonso, Manuel Fernandez, Alejandro Martin and Antonio Guzmán Connection String Parameter Pollution Attacks
desc.dataflow.python.connection_string_parameter_pollution
Abstract
Concatenar uma entrada não validada em uma conexão de banco de dados pode permitir a um invasor substituir o valor de um parâmetro de solicitação. Um invasor pode ser capaz de substituir os valores dos parâmetros existentes, injetar um novo parâmetro ou explorar variáveis fora de um alcance direto.
Explanation
Ataques de Connection String Parameter Pollution (CSPP) consistem em injetar parâmetros de cadeia de conexão em outros parâmetros existentes. Essa vulnerabilidade é semelhante a outras vulnerabilidades, e é talvez mais bem conhecida que, em ambientes HTTP nos quais a poluição de parâmetros também pode ocorrer. No entanto, também pode se aplicar a outros lugares, como cadeias de conexão do banco de dados. Se um aplicativo não limpar a entrada do usuário adequadamente, um usuário malicioso poderá comprometer a lógica do aplicativo para executar ataques: de roubo de credenciais até a recuperação de todo o banco de dados. Ao enviar parâmetros adicionais para uma aplicativo, e se esses parâmetros tiverem o mesmo nome de um parâmetro existente, a conexão de banco de dados poderá reagir de uma das seguintes maneiras:

Ela poderá obter apenas os dados do primeiro parâmetro
Poderá obter os dados do último parâmetro
Poderá obter os dados de todos os parâmetros e concatená-los

Isto pode depender da unidade utilizada, do tipo de base de dados, ou mesmo de como as APIs são utilizadas.

Exemplo 1: Este código usa entradas de uma solicitação HTTP para se conectar a um banco de dados:


hostname = req.params['host'] #gets POST parameter 'host'
...
conn = PG::Connection.new("connect_timeout=20 dbname=app_development user=#{user} password=#{password} host=#{hostname}")
...


Neste exemplo, o programador não considerou que um invasor poderia fornecer um parâmetro host, como:
"myevilsite.com%20port%3D4444%20sslmode%3Ddisable", então a cadeia de conexão se tornaria (supondo-se um nome de usuário "scott" e senha "5up3RS3kR3t"):

"dbname=app_development user=scott password=5up3RS3kR3t host=myevilsite.com port=4444 sslmode=disable"

Isso realizará uma pesquisa por "myevilsite.com" e de conectará ao banco de dados na porta 4444, desabilitando o SSL. Isso significa que o invasor poderia roubar as credenciais do usuário "scott" e depois usá-las para executar um ataque intermediário entre a máquina dele e o banco de dados real, ou apenas acessar o banco de dados real e realizar consultas no diretamente nele.
References
[1] Chema Alonso, Manuel Fernandez, Alejandro Martin and Antonio Guzmán Connection String Parameter Pollution Attacks
[2] Eric P. Maurice A New Threat To Web Applications: Connection String Parameter Pollution (CSPP)
desc.dataflow.ruby.connection_string_parameter_pollution
Abstract
Construir uma instrução de Provedor de Conteúdo que contém entradas do usuário pode permitir que um invasor acesse registros não autorizados.
Explanation
Vulnerabilidades de injeção de string de consulta ocorrem quando:

1. Os dados entram em um programa por uma fonte não confiável.



2. Os dados são usados para construir dinamicamente uma URL de consulta de Provedor de Conteúdo.



Provedores de conteúdo Android permitem que os desenvolvedores gravem consultas sem SQL simplesmente construindo URIs de provedor de conteúdo. URIs de consulta de provedores de conteúdo são vulneráveis a ataques de injeção e, portanto, os desenvolvedores devem evitar o uso da concatenação de strings com entradas de dados corrompidas para construir o URI, sem garantir que os metacaracteres estão devidamente validados ou codificados.

Exemplo 1: Considerando um aplicativo que expõe vários provedores de conteúdo em URIs:

content://my.authority/messagescontent://my.authority/messages/123content://my.authority/messages/deleted

Se os desenvolvedores construírem os URIs de consulta concatenando strings, os invasores poderão incluir barras no caminho ou outros metacaracteres de URI que modificarão o significado dessa consulta. No seguinte trecho de código, um invasor pode chamar content://my.authority/messages/deleted fornecendo um código msgId com o valor deleted:


// "msgId" is submitted by users
Uri dataUri = Uri.parse(WeatherContentProvider.CONTENT_URI + "/" + msgId);
Cursor wCursor1 = getContentResolver().query(dataUri, null, null, null, null);
desc.dataflow.java.content_provider_uri_injection
Abstract
O programa usa uma entrada de usuário não validada para carregar um arquivo SWF, o que pode fazer com que um conteúdo arbitrário seja referenciado e possivelmente executado pelo aplicativo Flash intencionado.
Explanation
APIs Flash fornecem uma interface para carregar arquivos SWF remotos no ambiente de execução existente. Mesmo que a política entre domínios definida só permita o carregamento de arquivos SWF a partir de uma lista de domínios confiáveis, na maioria dos casos, ela é excessivamente permissiva. Permitir que uma entrada de usuário não confiável defina quais arquivos SWF devem ser carregados pode fazer com que um conteúdo arbitrário seja referenciado e possivelmente executado pelo aplicativo intencionado, resultando em um ataque de criação de flash entre sites.

Vulnerabilidades de criação de flash entre sites ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são usados para carregar um arquivo SWF remoto.
Exemplo: O código a seguir usa o valor de um dos parâmetros para o arquivo SWF carregado como a URL a partir da qual carregar um arquivo SWF remoto.


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var url:String = String(params["url"]);
var ldr:Loader = new Loader();
var urlReq:URLRequest = new URLRequest(url);
ldr.load(urlReq);
...
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
desc.dataflow.actionscript.cross_site_flashing
Abstract
O envio de dados não validados para um navegador da Web pode fazer com que esse navegador execute código mal-intencionado.
Explanation
Vulnerabilidades de XSS (criação de script entre sites) ocorrem quando:

1. Dados entram em um aplicativo Web por meio de uma fonte não confiável. No caso da Inteligência Artificial (IA), a fonte não confiável é normalmente a resposta retornada por um sistema de IA. No caso de XSS refletido, normalmente é uma solicitação da web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. Embora a exploração não seja tão simples quanto outras formas de XSS, a natureza imprevisível da entrada do usuário e as respostas dos modelos de IA significam que essas respostas nunca devem ser tratadas como seguras.

Exemplo 1: O código Python a seguir recupera uma resposta de um modelo de conclusão de bate-papo OpenAI, message, e a exibe ao usuário.


client = openai.OpenAI()
res = client.chat.completions.create(...)

message = res.choices[0].message.content

self.writeln(f"<p>{message}<\p>")


O código nesse exemplo se comportará conforme o esperado, desde que a resposta do modelo contenha apenas caracteres alfanuméricos. No entanto, se metacaracteres HTML não codificados forem incluídos na resposta, o XSS será possível. Por exemplo, a resposta ao prompt "repita exatamente a seguinte instrução '<script>alert(1);</script>'" a seguir pode retornar uma prova de conceito XSS, dependendo do modelo e do contexto que estão sendo usados.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[16] Standards Mapping - FIPS200 SI
[17] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[20] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[21] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2021 A03 Injection
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[27] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[28] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[40] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[41] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[42] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[43] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[64] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[65] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.python.cross_site_scripting_ai
Abstract
O envio de dados não validados para um navegador da Web pode fazer com que certos navegadores executem código mal-intencionado.
Explanation
Vulnerabilidades de XSS (cross-site scripting) ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Para o navegador renderizar a resposta como HTML ou outro documento que possa executar scripts, ele deve especificar um tipo MIME text/html. Portanto, o XSS só será possível se a resposta usar esse tipo MIME ou qualquer outro que também force o navegador a renderizar a resposta como HTML ou outro documento que possa executar scripts, como imagens SVG. (image/svg+xml), documentos XML (application/xml), etc.

A maioria dos navegadores modernos não renderiza HTML ou executa scripts quando fornece uma resposta com tipos MIME, como application/octet-stream. No entanto, alguns navegadores, como o Internet Explorer, executam o que é conhecido como Content Sniffing. O Content Sniffing envolve ignorar o tipo MIME fornecido e tentar inferir o tipo MIME correto pelo conteúdo da resposta.
Vale a pena notar, no entanto, que um tipo MIME de text/html é apenas um tipo MIME que pode levar a vulnerabilidades de XSS. Outros documentos que podem executar scripts, como imagens SVG (image/svg+xml), documentos XML (application/xml), assim como outros, podem levar a vulnerabilidades de XSS, independentemente de o navegador executar o Content Sniffing.

Portanto, uma resposta, como <html><body><script>alert(1)</script></body></html>, poderia ser renderizada como HTML mesmo se seu cabeçalho content-type estivesse definido como application/octet-stream,multipart-mixed, e assim por diante.

Exemplo 1: O método JAX-RS a seguir reflete os dados do usuário em uma resposta application/octet-stream.


@RestController
public class SomeResource {
@RequestMapping(value = "/test", produces = {MediaType.APPLICATION_OCTET_STREAM_VALUE})
public String response5(@RequestParam(value="name") String name){
return name;
}
}


Se um invasor enviar uma solicitação com o parâmetro name definido como <html><body><script>alert(1)</script></body></html>, o servidor produzirá a seguinte resposta:


HTTP/1.1 200 OK
Content-Length: 51
Content-Type: application/octet-stream
Connection: Closed

<html><body><script>alert(1)</script></body></html>


Mesmo assim, a resposta afirma claramente que deve ser tratada como um documento JSON, um navegador antigo ainda pode tentar processá-lo como um documento HTML, tornando-o vulnerável a um ataque de Cross-Site Scripting.
References
[1] X-Content-Type-Options Mozilla
[2] MIME Type Detection in Windows Internet Explorer Microsoft
[3] Understanding Malicious Content Mitigation for Web Developers CERT
[4] HTML 4.01 Specification W3
[5] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[6] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[7] INJECT-3: XML and HTML generation requires care Oracle
[8] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[9] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[10] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[11] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[12] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[13] Standards Mapping - CIS Kubernetes Benchmark complete
[14] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[15] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[16] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[17] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[18] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[19] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[20] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[21] Standards Mapping - FIPS200 SI
[22] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[23] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[24] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[25] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[26] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[28] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[29] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[30] Standards Mapping - OWASP Top 10 2021 A03 Injection
[31] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[32] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[33] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[40] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[41] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[42] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[43] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[44] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[45] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[46] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[66] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[67] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[68] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.java.cross_site_scripting_content_sniffing
Abstract
O envio de dados não validados para um navegador da Web pode fazer com que certos navegadores executem código mal-intencionado.
Explanation
Vulnerabilidades de XSS (cross-site scripting) ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

O conteúdo mal-intencionado enviado para o navegador da Web muitas vezes assume a forma de um segmento de JavaScript, mas também podem incluir HTML, Flash ou qualquer outro tipo de código que esse navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo da Web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Para o navegador renderizar a resposta como HTML ou outro documento que possa executar scripts, ele deve especificar um tipo MIME text/html. Portanto, o XSS só será possível se a resposta usar esse tipo MIME ou qualquer outro que também force o navegador a renderizar a resposta como HTML ou outro documento que possa executar scripts, como imagens SVG. (image/svg+xml), documentos XML (application/xml), etc.
A maioria dos navegadores modernos não renderiza HTML, nem executa scripts quando recebe uma resposta com tipos MIME, como application/json. No entanto, alguns navegadores, como o Internet Explorer, executam o que é conhecido como Content Sniffing. O Content Sniffing envolve ignorar o tipo MIME fornecido e tentar inferir o tipo MIME correto pelo conteúdo da resposta.Vale a pena notar, no entanto, que um tipo MIME de text/html é apenas um tipo MIME que pode levar a vulnerabilidades de XSS. Outros documentos que podem executar scripts, como imagens SVG (image/svg+xml), documentos XML (application/xml), assim como outros, podem levar a vulnerabilidades de XSS, independentemente de o navegador executar o Content Sniffing.

Portanto, uma resposta, como <html><body><script>alert(1)</script></body></html>, poderia ser renderizada como HTML, mesmo se o cabeçalho content-type estiver definido como application/json.

Exemplo 1: A função AWS Lambda a seguir reflete os dados do usuário em uma resposta application/json.


def mylambda_handler(event, context):
name = event['name']
response = {
"statusCode": 200,
"body": "{'name': name}",
"headers": {
'Content-Type': 'application/json',
}
}
return response


Se um invasor enviar uma solicitação com o parâmetro name definido como <html><body><script>alert(1)</script></body></html>, o servidor produzirá a seguinte resposta:


HTTP/1.1 200 OK
Content-Length: 88
Content-Type: application/json
Connection: Closed

{'name': '<html><body><script>alert(1)</script></body></html>'}


Mesmo assim, a resposta afirma claramente que deve ser tratada como um documento JSON, um navegador antigo ainda pode tentar processá-lo como um documento HTML, tornando-o vulnerável a um ataque de Cross-Site Scripting.
References
[1] X-Content-Type-Options Mozilla
[2] MIME Type Detection in Windows Internet Explorer Microsoft
[3] Understanding Malicious Content Mitigation for Web Developers CERT
[4] HTML 4.01 Specification W3
[5] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[6] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[7] INJECT-3: XML and HTML generation requires care Oracle
[8] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[9] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[10] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[11] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[12] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[13] Standards Mapping - CIS Kubernetes Benchmark complete
[14] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[15] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[16] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[17] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[18] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[19] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[20] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[21] Standards Mapping - FIPS200 SI
[22] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[23] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[24] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[25] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[26] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[28] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[29] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[30] Standards Mapping - OWASP Top 10 2021 A03 Injection
[31] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[32] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[33] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[40] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[41] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[42] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[43] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[44] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[45] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[46] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[66] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[67] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[68] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.python.cross_site_scripting_content_sniffing
Abstract
O envio de dados não validados para um navegador da Web pode fazer com que esse navegador execute código mal-intencionado.
Explanation
Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável. No caso do XSS baseado em DOM, os dados são lidos a partir de um parâmetro de URL ou de outro valor dentro do navegador e gravados de volta na página com o código do lado do cliente. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação. No caso do XSS baseado em DOM, o conteúdo malicioso é executado como parte da criação do DOM (Document Object Model) sempre que o navegador da vítima analisar a página HTML.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo: O seguinte segmento de código JavaScript lê uma ID de funcionário, eid, de uma solicitação HTTP e a exibe para o usuário.


String queryString = Window.Location.getQueryString();
int pos = queryString.indexOf("eid=")+4;
HTML output = new HTML();
output.setHTML(queryString.substring(pos, queryString.length()));


O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.


Como o exemplos demonstra, as vulnerabilidades XSS são causadas por códigos que incluem dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- O aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] INJECT-3: XML and HTML generation requires care Oracle
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[11] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[12] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[13] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[15] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[16] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[17] Standards Mapping - FIPS200 SI
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[20] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[21] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[22] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2021 A03 Injection
[27] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[28] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[29] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[41] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[42] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[43] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[65] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[66] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.java.cross_site_scripting_dom
Abstract
O envio de dados não validados para um navegador da Web pode fazer com que esse navegador execute código mal-intencionado.
Explanation
Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável. No caso do XSS baseado em DOM, os dados são lidos a partir de um parâmetro de URL ou de outro valor dentro do navegador e gravados de volta na página com o código do lado do cliente. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação. No caso do XSS baseado em DOM, o conteúdo malicioso é executado como parte da criação do DOM (Document Object Model) sempre que o navegador da vítima analisar a página HTML.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: Este segmento de código JavaScript lê uma ID do funcionário, eid, a partir de uma URL e a exibe ao usuário.


<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>

Exemplo 2: Considere o formulário HTML:


<div id="myDiv">
Employee ID: <input type="text" id="eid"><br>
...
<button>Show results</button>
</div>
<div id="resultsDiv">
...
</div>


Este segmento de código jQuery lê uma ID do funcionário no formulário e a exibe ao usuário.


$(document).ready(function(){
$("#myDiv").on("click", "button", function(){
var eid = $("#eid").val();
$("resultsDiv").append(eid);
...
});
});


Esses exemplos de código funcionarão corretamente se a ID do funcionário na entrada de texto com a ID eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.

Exemplo 3: O código a seguir mostra um exemplo de um XSS baseado em DOM em um aplicativo do React:


let element = JSON.parse(getUntrustedInput());
ReactDOM.render(<App>
{element}
</App>);


No Example 3, se um invasor conseguir controlar todo o objeto JSON recuperado de getUntrustedInput(), poderá fazer o React renderizar o element como um componente e, portanto, poderá passar um objeto com o dangerouslySetInnerHTML com seu próprio valor controlado, um típico ataque de Cross-Site Scripting.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém forneceria uma entrada com código malicioso a ser executado no próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como o exemplos demonstra, as vulnerabilidades XSS são causadas por códigos que incluem dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- O aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] XSS via a spoofed React element Daniel LeCheminant
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[11] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[12] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[13] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[15] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[16] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[17] Standards Mapping - FIPS200 SI
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[20] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[21] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[22] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2021 A03 Injection
[27] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[28] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[29] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[41] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[42] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[43] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[65] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[66] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.javascript.cross_site_scripting_dom
Abstract
O envio de dados não validados para um navegador web pode causar a execução de códigos mal-intencionados. As configurações na configuração podem minimizar e reduzir a exposição a scripts entre sites
Explanation
Vulnerabilidades de XSS (criação de script entre sites) ocorrem quando:

1. Dados entram em um aplicativo Web por meio de uma fonte não confiável, mais frequentemente uma solicitação web ou banco de dados.

2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Como os ataques contra vulnerabilidades XSS geralmente envolvem comunicação ou redirecionamento para um site mal-intencionado controlado pelo invasor, a capacidade de injetar referências a conteúdo em outros domínios é parte integrante de muitas explorações. O AntiSamy pode ser configurado para evitar links para domínios externos, o que diminui os danos que um invasor pode causar por meio de um ataque XSS. No entanto, essa proteção é apenas uma solução parcial e não aborda a ameaça geral representada pelas vulnerabilidades XSS.

Exemplo 1: A seguinte entrada de configuração do AntiSamy permite links para URLs fora do domínio no qual o aplicativo está sendo executado.

<attribute name="href" onInvalid="filterTag">
<regexp-list>
<regexp name="onsiteURL"/>
<regexp name="offsiteURL"/>
</regexp-list>
</attribute>
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167, CCI-001310
[16] Standards Mapping - FIPS200 SI
[17] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[20] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[21] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2021 A03 Injection
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[27] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[28] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[40] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[41] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[42] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[43] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-003300 CAT II
[64] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[65] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.config.java.xss_external_links