Reino: Input Validation and Representation

Los problemas de validación y representación de entradas están causados por metacaracteres, codificaciones alternativas y representaciones numéricas. Los problemas de seguridad surgen de entradas en las que se confía. Estos problemas incluyen: «desbordamientos de búfer», ataques de «scripts de sitios», "SQL injection" y muchas otras acciones.

175 elementos encontrados
Debilidades
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. Con Handlebars, puede crear auxiliares personalizados que se pueden usar para modificar plantillas.


2. Los datos se incluyen en el contenido dinámico que se inserta en una plantilla antes de procesarse sin validación. En el caso del auxiliar de Handlebars, el contenido malintencionado se procesa como la salida de la plantilla.

El contenido malintencionado en un auxiliar de Handlebars adopta la forma de un segmento de código JavaScript o cualquier otro tipo de código que el explorador ejecute. Dado que la salida de una plantilla de Handlebars suele ser contenido HTML que se pasa al explorador, cualquier contenido potencialmente malicioso debe tratarse como no seguro y validarse.

Ejemplo 1: Considere el siguiente código auxiliar de Handlebars:


Handlebars.registerHelper('bolden', function (aString) {
return new Handlebars.SafeString("" + aString + "")
})
// ...
let template = Handlebars.compile('{{bolden someArgument}}')
myElem.innerHTML = template({someArgument: userInput})


El auxiliar bolden recibe los datos controlados por el usuario userInput. Aunque el uso de llaves dobles ({{ y }}) generalmente significa que la salida estará codificada en HTML, en este escenario, el auxiliar bolden anula cualquier validación al pasar la entrada a new Handlebars.SafeString(), lo que hace que la entrada se procese como HTML normal. Cuando el HTML regresa de template(), se pasa a la propiedad innerHTML que conduce a un XSS basado en DOM.
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 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.javascript.cross_site_scripting_handlebars_helper
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web o móvil a través de un origen no confiable. En el caso de XSS por comunicación entre componentes, el origen no confiable son los datos recibidos de otros componentes que residen en el mismo sistema. En el caso de plataformas móviles, se trata de aplicaciones que se ejecutan en el mismo dispositivo. En el caso de XSS reflejado, el origen que no es de confianza suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Algunos piensan que en los entornos móviles las vulnerabilidades de las aplicaciones web clásicas como los scripts de sitios no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 1: el siguiente segmento de código ASP.NET lee un identificador de empleado, eid, a partir de una solicitud HTTP y lo muestra al usuario.


String eid = Request["eid"];
...
EmployeeID.Text = eid;


Donde EmployeeID es un control ASP.NET del lado del servidor como se indica a continuación:


<form runat="server">
...
<asp:Label id="EmployeeID" runat="server"/>
...
</form>


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código ASP.NET consulta una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


...
string name = "";
using (SqlConnection conn = new SqlConnection(_ConnectionString))
{
string eid = Request["eid"];
SqlCommand cmd = new SqlCommand("SELECT * FROM emp WHERE id = @id", conn);
cmd.Parameters.AddWithValue("@id", eid);
conn.Open();
SqlDataReader objReader = cmd.ExecuteReader();

while (objReader.Read())
{
name = objReader["name"];
}
objReader.Close();
}
...

EmployeeName.Text = name;


Donde EmployeeName es un control ASP.NET del lado del servidor como se indica a continuación:


<form runat="server">
...
<asp:Label id="EmployeeName" runat="server"/>
...
</form>


Al igual que en el Example 2, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, Struts y Struts 2). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.
References
[1] Anti-Cross Site Scripting Library MSDN
[2] Understanding Malicious Content Mitigation for Web Developers CERT
[3] HTML 4.01 Specification W3
[4] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[5] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[7] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[11] Standards Mapping - CIS Kubernetes Benchmark complete
[12] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[13] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[15] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[16] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[17] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[18] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[19] Standards Mapping - FIPS200 SI
[20] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[23] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[24] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[28] Standards Mapping - OWASP Top 10 2021 A03 Injection
[29] 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)
[30] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[31] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[32] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[40] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[41] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[42] 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
[43] 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
[44] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[45] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[46] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[47] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[66] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[67] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[68] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[69] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.dotnet.cross_site_scripting_inter_component_communication
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS por comunicación entre componentes, el origen no confiable son los datos recibidos de otros componentes que residen en el mismo sistema. En el caso de Reflected XSS, el origen no confiable suele ser una solicitud web, mientras que en el caso de Persisted XSS (también conocido como Stored XSS) suele ser una base de datos u otro almacén de datos back-end.

2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.


Ejemplo 1: El siguiente segmento de código de Go lee un nombre de usuario, user, de una solicitud HTTP y lo muestra al usuario.

func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}


El código de este ejemplo funciona correctamente si user contiene solo texto alfanumérico estándar. Si user tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: El siguiente segmento de código de Go consulta una base de datos en busca de un empleado con un identificador determinado e imprime el nombre del empleado correspondiente.

func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", name)
}


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación adecuada de las entradas de todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso, ya que el direccionamiento indirecto causado por el almacén de datos dificulta la identificación de la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS se inició de este modo con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Son tres los vectores por los que un ataque XSS puede llegar a una víctima:

- Como se muestra en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un atacante hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, que luego se refleja en el usuario y se ejecuta en el explorador web. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Como se muestra en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el atacante puede realizar operaciones con privilegios en nombre del usuario u obtener acceso a datos confidenciales del usuario.

- Un origen externo a la aplicación almacena los datos peligrosos en una base de datos u otro almacén de datos. Posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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 - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[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.golang.cross_site_scripting_inter_component_communication
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web o móvil a través de un origen no confiable. En el caso de XSS por comunicación entre componentes, el origen no confiable son los datos recibidos de otros componentes que residen en el mismo sistema. En el caso de plataformas móviles, se trata de aplicaciones que se ejecutan en el mismo dispositivo. En el caso de XSS reflejado, el origen que no es de confianza suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Algunos piensan que en los entornos móviles las vulnerabilidades de las aplicaciones web clásicas como los scripts de sitios no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 1: el siguiente código habilita JavaScript en WebView de Android (JavaScript está deshabilitado de manera predeterminada) y carga una página basada en el valor recibido de una finalidad de Android.


...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...


Si el valor de url comienza por javascript:, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.

Ejemplo 2: el siguiente segmento de código JSP lee un identificador de empleado, eid, a partir de una solicitud HTTP y lo muestra al usuario.


<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 3: el siguiente segmento de código JSP consulta una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>

Employee Name: <%= name %>


Al igual que en el Example 2, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.

- Al igual que en el Example 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 3, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, Struts y Struts 2). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[4] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[5] INJECT-3: XML and HTML generation requires care Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[7] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[11] Standards Mapping - CIS Kubernetes Benchmark complete
[12] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[13] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[15] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[16] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[17] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[18] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[19] Standards Mapping - FIPS200 SI
[20] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[23] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[24] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[28] Standards Mapping - OWASP Top 10 2021 A03 Injection
[29] 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)
[30] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[31] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[32] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[40] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[41] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[42] 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
[43] 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
[44] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[45] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[46] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[47] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[66] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[67] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[68] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[69] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.java.cross_site_scripting_inter_component_communication
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS por comunicación entre componentes, el origen no confiable son los datos recibidos de otros componentes que residen en el mismo sistema. En un entorno móvil, se trata de aplicaciones que se ejecutan en el mismo dispositivo. En el caso de Reflected XSS, el origen no confiable suele ser una solicitud web, mientras que en el caso de Persisted XSS (también conocido como Stored XSS) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Algunos piensan que en los entornos móviles las vulnerabilidades de las aplicaciones web clásicas como los scripts de sitios no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 1: el código siguiente habilita JavaScript en WebView de Android (JavaScript está deshabilitado de manera predeterminada) y carga una página basada en el valor recibido de una finalidad de Android.


...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...


Si el valor de url comienza por javascript:, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.

Ejemplo 2: el siguiente código lee un ID de empleado, eid, desde una solicitud de servlet HTTP y, a continuación, muestra el valor al usuario en la respuesta del servlet.


val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 3: el siguiente segmento de código realiza consultas en una base de datos en busca de un empleado con un determinado ID e imprime el nombre del empleado correspondiente en la respuesta del servlet.


val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...


Al igual que en el Example 2, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Son tres los vectores por los que un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.

- Al igual que en el Example 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 3, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.


Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, Struts y Spring MVC). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[4] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[5] INJECT-3: XML and HTML generation requires care Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[7] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[11] Standards Mapping - CIS Kubernetes Benchmark complete
[12] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[13] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[15] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[16] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[17] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[18] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[19] Standards Mapping - FIPS200 SI
[20] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[23] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[24] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[28] Standards Mapping - OWASP Top 10 2021 A03 Injection
[29] 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)
[30] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[31] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[32] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[40] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[41] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[42] 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
[43] 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
[44] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[45] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[46] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[47] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[66] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[67] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[68] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[69] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.kotlin.cross_site_scripting_inter_component_communication
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web o móvil a través de un origen no confiable. En el caso de XSS por comunicación entre componentes, el origen no confiable son los datos recibidos de otros componentes que residen en el mismo sistema. En el caso de plataformas móviles, se trata de aplicaciones que se ejecutan en el mismo dispositivo. En el caso de XSS reflejado, el origen que no es de confianza suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Algunos piensan que en los entornos móviles las vulnerabilidades de las aplicaciones web clásicas como los scripts de sitios no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 1: El siguiente código permite que una aplicación cargue una página HTML en una WKWebView con datos de una solicitud URL que usa el esquema de URL personalizado de la aplicación:

AppDelegate.m:

...
@property (strong, nonatomic) NSString *webContentFromURL;
...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
...
[self setWebContentFromURL:[url host]];
...
...


ViewController.m

...
@property (strong, nonatomic) WKWebView *webView;
...
AppDelegate *appDelegate = (AppDelegate *)[[UIApplication sharedApplication] delegate];
...
[_webView loadHTMLString:appDelegate.webContentFromURL] baseURL:nil];
...


Como la cadena que se pasa a loadHTMLString: puede controlarla el usuario y JavaScript está habilitado de forma predeterminada en una WKWebView, el usuario puede escribir contenido arbitrario (incluidos scripts ejecutables) en WKWebView a través de solicitudes que usan el esquema de URL personalizado de la aplicación.

Ejemplo 2: El siguiente código lee el contenido de un UITextField y lo muestra al usuario en una WKWebView:


...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView loadHTMLString:_inputTextField.text baseURL:nil];
...


El código de este ejemplo funciona correctamente si el texto en inputTextField contiene solo texto alfanumérico estándar. Si el texto en inputTextField incluye metacaracteres o código fuente, el explorador web puede ejecutar la entrada como código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. ¿Por qué alguien escribiría algo que provocara la ejecución de código malintencionado en su propio dispositivo? El peligro real es que un atacante puede usar el correo electrónico o algún tipo de truco de ingeniería social para conseguir que las víctimas realicen tales acciones. Si lo consiguen, las víctimas del ataque pueden reflejar de manera inconsciente el contenido malintencionado en sus propios equipos, a través de la aplicación web vulnerable. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 3: El siguiente segmento de código de consulta una base de datos de un empleado con un identificador determinado y presenta el valor en el contenido visualizado en WKWebView.


...
@property (strong, nonatomic) WKWebView *webView;
...
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:@"Employee" inManagedObjectContext:context];
[fetchRequest setEntity:entity];

NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error];
for (NSManagedObject *info in fetchedObjects) {
NSString msg = @"Hello, " + [info valueForKey:@"name"];
[_webView loadHTMLString:msg baseURL:nil]
...
}
...


Al igual que en el Example 2, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, una fuente externa a la aplicación de destino realiza una solicitud de URL mediante el esquema de URL personalizado de la aplicación de destino, y los datos sin validar de la solicitud de URL se leen posteriormente en la aplicación como datos de confianza y se incluyen en el contenido dinámico.

- Al igual que en el Example 2, los datos se leen directamente desde el componente de la interfaz de usuario controlado por el usuario y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 3, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] MWR Labs Continued Adventures with iOS UIWebViews
[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 - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[40] 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
[41] 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
[42] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[43] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[44] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[45] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[66] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[67] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.objc.cross_site_scripting_inter_component_communication
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web o móvil a través de un origen no confiable. En el caso de XSS por comunicación entre componentes, el origen no confiable son los datos recibidos de otros componentes que residen en el mismo sistema. En el caso de plataformas móviles, se trata de aplicaciones que se ejecutan en el mismo dispositivo. En el caso de XSS reflejado, el origen que no es de confianza suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Algunos piensan que en los entornos móviles las vulnerabilidades de las aplicaciones web clásicas como los scripts de sitios no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 1: El siguiente código permite que una aplicación cargue una página HTML en una WKWebView con datos de una solicitud URL que usa el esquema de URL personalizado de la aplicación:


...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = WKWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...


Como la cadena que se transfiere a loadHTMLString: puede controlarla el usuario y JavaScript está habilitado de forma predeterminada en una WKWebView, el usuario puede escribir contenido arbitrario (incluidos scripts ejecutables) en WKWebView a través de solicitudes que usan el esquema de URL personalizado de la aplicación.

Ejemplo 2: El siguiente código lee el contenido de un UITextField y lo muestra al usuario en una WKWebView:


...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...


El código de este ejemplo funciona correctamente si el texto en inputTextField contiene solo texto alfanumérico estándar. Si el texto en inputTextField incluye metacaracteres o código fuente, el explorador web puede ejecutar la entrada como código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. ¿Por qué alguien escribiría algo que provocara la ejecución de código malintencionado en su propio dispositivo? El peligro real es que un atacante puede usar el correo electrónico o algún tipo de truco de ingeniería social para conseguir que las víctimas realicen tales acciones. Si lo consiguen, las víctimas del ataque pueden reflejar de manera inconsciente el contenido malintencionado en sus propios equipos, a través de la aplicación web vulnerable. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 3: El siguiente segmento de código de consulta una base de datos de un empleado con un identificador determinado y presenta el valor en el contenido visualizado en WKWebView.


let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Employee", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
do {
let results = try managedContext.executeFetchRequest(fetchRequest)
let result : NSManagedObject = results.first!
let name : String = result.valueForKey("name")
let msg : String = "Hello, \(name)"
let webView : UIWebView = UIWebView()
webView.loadHTMLString(msg, baseURL:nil)
} catch let error as NSError {
print("Error \(error)")
}


Al igual que en el Example 2, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, una fuente externa a la aplicación de destino realiza una solicitud de URL mediante el esquema de URL personalizado de la aplicación de destino, y los datos sin validar de la solicitud de URL se leen posteriormente en la aplicación como datos de confianza y se incluyen en el contenido dinámico.

- Al igual que en el Example 2, los datos se leen directamente desde el componente de la interfaz de usuario controlado por el usuario y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 3, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] MWR Labs Continued Adventures with iOS UIWebViews
[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 - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[40] 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
[41] 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
[42] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[43] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[44] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[45] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[66] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[67] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.swift.cross_site_scripting_inter_component_communication
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web alojada en la nube a través de un origen no fiable. En el caso de Inter-Component Communication Cloud XSS, la fuente no fiable son los datos recibidos de otros componentes de la aplicación en la nube a través de los canales de comunicación proporcionados por el host de la nube.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente formulario web de ASP.NET realiza una consulta acerca de un empleado en el servicio de tabla de Azure e imprime el nombre.

<script runat="server">
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;
</script>


Donde EmployeeName es un control de formulario definido como se indica a continuación:


<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Ejemplo 2: El siguiente segmento de código de ASP .NET es equivalente desde una perspectiva funcional al Example 1, pero implementa mediante programación todos los elementos de formulario.

protected System.Web.UI.WebControls.Label EmployeeName;
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;


Estos ejemplos de código funcionan correctamente cuando los valores de Name tienen un comportamiento correcto, pero no funcionan para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de Name se lee desde un servicio de almacenamiento proporcionado por la nube con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de Name se origina desde los datos que administró el usuario, el servicio de almacenamiento proporcionado por la nube puede ser conductor de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como Inter-Component Communication Cloud XSS,es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 3: el siguiente formulario web de ASP.NET lee un número de id. de empleado de una solicitud HTTP y lo muestra al usuario.

<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>


Donde Login y EmployeeID son controles de formulario definidos de la siguiente forma:


<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Ejemplo 4: El siguiente segmento de código de ASP.NET muestra el método de implementación mediante programación del Example 3.

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;


Al igual que en el Example 1 y el Example 2, estos ejemplos funcionan correctamente si Login contiene solo texto alfanumérico estándar. Si Login tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real consiste en que un atacante cree la URL malintencionada y, después, utilice el correo electrónico o algún tipo de truco de ingeniería social para conseguir que las víctimas hagan clic en el vínculo. En ese caso, estos mostrarán de forma inconsciente el contenido malintencionado a través de la aplicación web vulnerable y de nuevo en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1 y el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS en la nube por comunicación entre componentes se producen cuando un usuario malintencionado inyecta contenido peligroso en un almacén de datos que más adelante se lee e incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 3 y el Example 4, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.

Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, validación de solicitudes de ASP.NET y WCF). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Con la validación de solicitudes de ASP .NET, también proporcionamos pruebas cuando la validación se ha deshabilitado explícitamente. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Anti-Cross Site Scripting Library MSDN
[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.dotnet.cross_site_scripting_inter_component_communication__cloud_
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web alojada en la nube a través de un origen no fiable. En el caso de Inter-Component Communication Cloud XSS, la fuente no fiable son los datos recibidos de otros componentes de la aplicación en la nube a través de los canales de comunicación proporcionados por el proveedor de la nube.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: El siguiente segmento de código de Python lee un nombre de usuario, eid, de una solicitud HTTP y lo muestra al usuario.


req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: El siguiente segmento de código de Python consulta una base de datos en busca de un empleado con un identificador determinado e imprime el nombre del empleado correspondiente.


...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Son tres los vectores por los que un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Un origen externo a la aplicación almacena los datos peligrosos en una base de datos u otro almacén de datos. Posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Anti-Cross Site Scripting Library MSDN
[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.python.cross_site_scripting_inter_component_communication__cloud_
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS persistente (también conocido como almacenado), el origen no confiable suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser una solicitud web.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código ABAP realiza una consulta en una base de datos sobre un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.

SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...


Este código funciona correctamente cuando los valores de name tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 2: El siguiente segmento de código ABAP lee un ID de empleado, eid, desde la solicitud HTTP y lo muestra al usuario.


...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...


Al igual que en el Example 1, este código funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
References
[1] SAP OSS notes 1582870, 1582867 and related notes for ABAP XSS support
[2] SAP OSS Notes 822881, 1600317, 1640092, 1671470 and 1638779 for XSS support in BSPs
[3] Understanding Malicious Content Mitigation for Web Developers CERT
[4] HTML 4.01 Specification W3
[5] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[6] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[18] Standards Mapping - FIPS200 SI
[19] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[20] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[21] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[22] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[23] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2021 A03 Injection
[28] 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)
[29] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[30] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[40] 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
[41] 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
[42] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[43] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[44] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[45] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[66] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[67] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.abap.cross_site_scripting_persistent
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS persistente (también conocido como almacenado), el origen no confiable suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser una solicitud web.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código ActionScript consulta una base de datos de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + name;
}


Este código funciona correctamente cuando los valores de name tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 2: el siguiente segmento de código ActionScript lee un identificador de empleado, eid, a partir de una solicitud HTTP y lo muestra al usuario.


var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...


Al igual que en el Example 1, este código funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.actionscript.cross_site_scripting_persistent
Abstract
El envío de datos no validados al explorador web puede dar lugar a la ejecución de código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS persistente, un origen que no es de confianza es, con frecuencia, el resultado de una consulta de base de datos, y en el caso de XSS reflejado, una solicitud web.

2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malicioso suele ser un segmento de código JavaScript, pero también puede ser HTML, Flash o cualquier otro contenido activo que pueda ejecutar el explorador. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código Apex realiza consultas en una base de datos en busca de un nombre de contacto con un determinado ID y devuelve el nombre del empleado correspondiente, que después imprimirá el código de Visualforce.


...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...

<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>


Este código se comporta correctamente cuando los valores de name están definidos correctamente como caracteres alfanuméricos, pero no funciona para comprobar si hay datos malintencionados. Incluso al leer a partir de una base de datos, el valor debe validarse adecuadamente, porque el contenido de la base de datos puede originarse a partir de datos proporcionados por el usuario. De este modo, un atacante puede tener comandos malintencionados ejecutados en el explorador web del usuario sin tener que interactuar con la víctima, como en el caso de XSS reflejado. Este tipo de ataque, conocido como XSS almacenado (o persistente), puede ser muy difícil de detectar ya que los datos se proporcionan indirectamente a la función vulnerable y a que tiene un mayor impacto debido a la posibilidad de que afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 2: el siguiente segmento de código de Visualforce lee un parámetro de solicitud HTTP, username, y lo muestra al usuario.


<script>
document.write('{!$CurrentPage.parameters.username}')
</script>


El código de este ejemplo está pensado para recibir solo texto alfanumérico y mostrarlo. Sin embargo, si username contiene metacaracteres o código fuente, el explorador web lo ejecutará.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay dos vectores, por los cuales un ataque XSS puede ejecutarse:

- Al igual que en el Example 1, la base de datos o cualquier otro almacén de datos puede proporcionar datos peligrosos a la aplicación que se incluirán en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el mejor lugar para almacenar contenido malintencionado es un área accesible a todos los usuarios, especialmente los que cuentan con privilegios elevados, que son los que con más probabilidad manejarán información confidencial o realizarán operaciones críticas.

- Al igual que en el Example 2, los datos se leen de la solicitud HTTP y se reflejan en la respuesta HTTP. El XSS reflejado se produce cuando un atacante proporciona contenido peligroso a una aplicación web vulnerable y después se refleja en el usuario y se ejecuta mediante el explorador. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a la víctima. Las direcciones URL diseñadas de esta forma son el núcleo de muchas tramas de suplantación de identidad, en las que un atacante tienta a la víctima para que visite la dirección URL. Después de que el sitio muestre el contenido al usuario, éste se ejecuta y puede realizar varias acciones, como enviar información confidencial privada, ejecutar operaciones no autorizadas en el equipo de la víctima, etc.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Salesforce Developers Technical Library Secure Coding Guidelines - Cross Site Scripting
[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.apex.cross_site_scripting_persistent
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS persistente (también conocido como almacenado), el origen no confiable suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser una solicitud web.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el formulario web de ASP.NET realiza una consulta en una base de datos en relación con un empleado que dispone de un determinado Id. de empleado e imprime el nombre correspondiente junto con el Id.

<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>


Donde EmployeeName es un control de formulario definido como se indica a continuación:


<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Ejemplo 2: El siguiente segmento de código de ASP .NET es equivalente desde una perspectiva funcional al Example 1, pero implementa mediante programación todos los elementos de formulario.

protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;


Estos ejemplos de código funcionan correctamente cuando los valores de name tienen un comportamiento correcto, pero no funcionan para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 3: el siguiente formulario web de ASP.NET lee un número de id. de empleado de una solicitud HTTP y lo muestra al usuario.

<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>


Donde Login y EmployeeID son controles de formulario definidos de la siguiente forma:


<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Ejemplo 4: El siguiente segmento de código de ASP.NET muestra el método de implementación mediante programación del Example 3.

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;


Al igual que en el Example 1 y el Example 2, estos ejemplos funcionan correctamente si Login contiene solo texto alfanumérico estándar. Si Login tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real consiste en que un atacante cree la URL malintencionada y, después, utilice el correo electrónico o algún tipo de truco de ingeniería social para conseguir que las víctimas hagan clic en el vínculo. En ese caso, estos mostrarán de forma inconsciente el contenido malintencionado a través de la aplicación web vulnerable y de nuevo en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1 y el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 3 y el Example 4, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.

Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, validación de solicitudes de ASP.NET y WCF). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Con la validación de solicitudes de ASP .NET, también proporcionamos pruebas cuando la validación se ha deshabilitado explícitamente. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Anti-Cross Site Scripting Library MSDN
[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.dotnet.cross_site_scripting_persistent
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS persistente (también conocido como almacenado), el origen no confiable suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser una solicitud web.

2. Los datos se incluyen en el contenido dinámico que se envía a un explorador web sin que se validen.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código consulta una base de datos de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.

EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...


El código de este ejemplo funciona correctamente cuando los valores de ENAME tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. De nuevo, este código puede parecer menos peligroso, ya que el valor de ENAME se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de ENAME se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS almacenado, es especialmente insidioso porque el direccionamiento indirecto que causa el almacén de datos dificulta la identificación de la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 2: el siguiente segmento de código lee un identificador de empleado, EID, a partir de un formulario HTML y lo muestra al usuario.


...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.

EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...


Al igual que en el Example 1, este código funciona correctamente si EID contiene solo texto alfanumérico estándar. Si EID tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Las explotaciones de XSS almacenado se producen cuando un atacante

- Al igual que en el Example 2, los datos se leen directamente del formulario HTML y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.cobol.cross_site_scripting_persistent
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS persistente (también conocido como almacenado), el origen no confiable suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser una solicitud web.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código CFML realiza una consulta en una base de datos sobre un empleado con un identificador dado e imprime el nombre del empleado correspondiente.

 
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>


El código de este ejemplo funciona correctamente cuando los valores de name tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 2: el siguiente segmento de código CFML lee un identificador de empleado, eid, de un formulario web y lo muestra al usuario.


<cfoutput>
Employee ID: #Form.eid#
</cfoutput>


Al igual que en el Example 1, este código funciona correctamente si Form.eid contiene solo texto alfanumérico estándar. Si Form.eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] ColdFusion Developer Center: Security Macromedia
[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.cfml.cross_site_scripting_persistent
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de Reflected XSS, el origen no confiable suele ser una solicitud web, mientras que en el caso de Persisted XSS (también conocido como Stored XSS) suele ser una base de datos u otro almacén de datos back-end.

2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.


Ejemplo 1: El siguiente segmento de código de Go lee un nombre de usuario, user, de una solicitud HTTP y lo muestra al usuario.

func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}


El código de este ejemplo funciona correctamente si user contiene solo texto alfanumérico estándar. Si user tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: El siguiente segmento de código de Go consulta una base de datos en busca de un empleado con un identificador determinado e imprime el nombre del empleado correspondiente.

func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", name)
}


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación adecuada de las entradas de todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso, ya que el direccionamiento indirecto causado por el almacén de datos dificulta la identificación de la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS se inició de este modo con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Son tres los vectores por los que un ataque XSS puede llegar a una víctima:

- Como se muestra en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un atacante hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, que luego se refleja en el usuario y se ejecuta en el explorador web. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Como se muestra en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el atacante puede realizar operaciones con privilegios en nombre del usuario u obtener acceso a datos confidenciales del usuario.

- Un origen externo a la aplicación almacena los datos peligrosos en una base de datos u otro almacén de datos. Posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.golang.cross_site_scripting_persistent
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS persistente (también conocido como almacenado), el origen no confiable suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser una solicitud web.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código JSP consulta una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>

Employee Name: <%= name %>


Este código funciona correctamente cuando los valores de name tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 2: el siguiente segmento de código JSP lee un identificador de empleado, eid, a partir de una solicitud HTTP y lo muestra al usuario.


<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>


Al igual que en el Example 1, este código funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Algunos piensan que en los entornos móviles las vulnerabilidades de las aplicaciones web clásicas como los scripts de sitios no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Example 3: The following code enables JavaScript in Android's WebView (by default, JavaScript is disabled) and loads a page based on the value received from an Android intent.


...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...


Si el valor de url comienza por javascript:, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 3, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.

Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, Struts y Struts 2). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[4] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[5] INJECT-3: XML and HTML generation requires care Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[7] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[11] Standards Mapping - CIS Kubernetes Benchmark complete
[12] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[13] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[15] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[16] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[17] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[18] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[19] Standards Mapping - FIPS200 SI
[20] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[23] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[24] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[28] Standards Mapping - OWASP Top 10 2021 A03 Injection
[29] 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)
[30] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[31] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[41] 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
[42] 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
[43] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[44] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[45] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[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_persistent
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS persistente (también conocido como almacenado), el origen no confiable suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser una solicitud web.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código consulta una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


var http = require('http');
...

function listener(request, response){
connection.query('SELECT * FROM emp WHERE eid="' + eid + '"', function(err, rows){
if (!err && rows.length > 0){
response.write('<p>Welcome, ' + rows[0].name + '!</p>');
}
...
});
...
}
...
http.createServer(listener).listen(8080);


Este código funciona correctamente cuando los valores de name tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 2: el siguiente segmento de código Node.js lee un identificador de empleado, eid, a partir de una solicitud HTTP y lo muestra al usuario.


var http = require('http');
var url = require('url');

...

function listener(request, response){
var eid = url.parse(request.url, true)['query']['eid'];
if (eid !== undefined){
response.write('<p>Welcome, ' + eid + '!</p>');
}
...
}
...
http.createServer(listener).listen(8080);


Al igual que en el Example 1, este código funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.
Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.javascript.cross_site_scripting_persistent
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS persistente (también conocido como XSS almacenado), el origen no confiable suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser una solicitud web.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código realiza consultas en una base de datos en busca de un empleado con un determinado ID e imprime el nombre del empleado correspondiente en la respuesta del servlet.


...
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...


Este código funciona correctamente cuando los valores de name tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 2: el siguiente código lee un ID de empleado, eid, desde una solicitud de servlet HTTP y, a continuación, muestra el valor al usuario en la respuesta del servlet.


val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...


Al igual que en el Example 1, este código funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Algunos piensan que en los entornos móviles las vulnerabilidades de las aplicaciones web clásicas como los scripts de sitios no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 3: el código siguiente habilita JavaScript en WebView de Android (JavaScript está deshabilitado de manera predeterminada) y carga una página basada en el valor recibido de una finalidad de Android.


...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...


Si el valor de url comienza por javascript:, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Son tres los vectores por los que un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 3, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.


Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, Struts y Spring MVC). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[4] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[5] INJECT-3: XML and HTML generation requires care Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[7] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[11] Standards Mapping - CIS Kubernetes Benchmark complete
[12] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[13] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[15] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[16] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[17] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[18] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[19] Standards Mapping - FIPS200 SI
[20] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[23] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[24] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[28] Standards Mapping - OWASP Top 10 2021 A03 Injection
[29] 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)
[30] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[31] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[41] 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
[42] 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
[43] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[44] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[45] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[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.kotlin.cross_site_scripting_persistent
Abstract
El método envía datos no validados a un explorador web, lo que puede provocar que el explorador ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una página web a través de un origen que no es de confianza. En el caso de XSS persistente (también conocido como almacenado), el origen que no es de confianza suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser un componente de usuario, un controlador del esquema de URL o una notificación externa.


2. Los datos se incluyen en el contenido dinámico que se envía a un componente UIWebView sin que se validen.


El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.



Este código funciona correctamente cuando los valores de name tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 2: el siguiente segmento de código Objective-C lee la parte de texto de un esquema de URL personalizado que se pasó a la aplicación (myapp://input_to_the_application) y la invocó. Los datos no fiables de la dirección URL se utilizan para representar el resultado HTML en un componente de UIWebView.


...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {

UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]

...


Como se muestran en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en el contenido HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 2, los datos se leen directamente desde un esquema de URL personalizado y se reflejan en el contenido de una respuesta de UIWebView. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación de iOS vulnerable, lo que se reflejará en el usuario y que el navegador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL de esquema personalizado que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL construidas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un intruso convence a las víctimas para que visiten una dirección URL que hace referencia a una aplicación vulnerable. Después de que la aplicación refleje el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] MWR Labs Continued Adventures with iOS UIWebViews
[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.objc.cross_site_scripting_persistent
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS persistente (también conocido como almacenado), el origen no confiable suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser una solicitud web.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código PHP realiza una consulta en una base de datos sobre un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


<?php...
$con = mysql_connect($server,$user,$password);
...
$result = mysql_query("select * from emp where id="+eid);
$row = mysql_fetch_array($result)
echo 'Employee name: ', mysql_result($row,0,'name');
...
?>


Este código funciona correctamente cuando los valores de name tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 2: el siguiente segmento de código PHP lee un identificador de empleado, eid, desde una solicitud HTTP y la muestra al usuario.


<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>


Al igual que en el Example 1, este código funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.php.cross_site_scripting_persistent
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS persistente (también conocido como almacenado), el origen no confiable suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser una solicitud web.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código consulta una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || name || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...


Este código funciona correctamente cuando los valores de name tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 2: el siguiente segmento de código lee un identificador de empleado, eid, a partir de una solicitud HTTP y lo muestra al usuario.


...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || eid || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...


Al igual que en el Example 1, este código funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.sql.cross_site_scripting_persistent
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS persistente (también conocido como almacenado), el origen no confiable suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser una solicitud web.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: El siguiente segmento de código Python lee un ID de empleado, eid, de una solicitud HTTP y la muestra al usuario.


req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: El siguiente segmento de código Python consulta una base de datos de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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_persistent
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS persistente (también conocido como almacenado), el origen no confiable suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser una solicitud web.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.
Ejemplo 1: El siguiente segmento de código de Ruby consulta una base de datos de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...


Este código funciona correctamente cuando los valores de name tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Los tipos alternativos de XSS no pueden provenir de una base de datos, sino de otros lugares de posible entrada del usuario. El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 2: El siguiente segmento de código de Ruby lee un ID de empleado, eid, de una solicitud HTTP y la muestra al usuario.


eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end


Al igual que en el Example 1, el código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como XSS reflejado; sin embargo, tenga en cuenta que si utiliza Rack::Request#params() como se mostró en el Example 2, se observan los parámetros GET y POST, de modo que puede ser vulnerable a diferentes tipos de ataques además de simplemente tener el código malintencionado anexado a la dirección URL.
Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.ruby.cross_site_scripting_persistent
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS persistente (también conocido como almacenado), el origen no confiable suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser una solicitud web.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo: El siguiente segmento de código de controlador de reproducción lee un identificador de empleado, eid, a partir de una consulta de base de datos y lo muestra al usuario.


def getEmployee = Action { implicit request =>

val employee = getEmployeeFromDB()
val eid = employee.id

if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
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.scala.cross_site_scripting_persistent
Abstract
El método envía datos no validados a un explorador web, lo que puede provocar que el explorador ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una página web a través de un origen que no es de confianza. En el caso de XSS persistente (también conocido como almacenado), el origen que no es de confianza suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser un componente de usuario, un controlador del esquema de URL o una notificación externa.


2. Los datos se incluyen en el contenido dinámico que se envía a un componente UIWebView sin que se validen.


El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.



Este código funciona correctamente cuando los valores de name tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 2: El siguiente código lee el contenido de un UITextField y lo muestra al usuario en una WKWebView:


...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...


El código de este ejemplo funciona correctamente si el texto en inputTextField contiene solo texto alfanumérico estándar. Si el texto en inputTextField incluye metacaracteres o código fuente, el explorador web puede ejecutar la entrada como código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. ¿Por qué alguien escribiría algo que provocara la ejecución de código malintencionado en su propio dispositivo? El peligro real es que un atacante puede usar el correo electrónico o algún tipo de truco de ingeniería social para conseguir que las víctimas realicen tales acciones. Si lo consiguen, las víctimas del ataque pueden reflejar de manera inconsciente el contenido malintencionado en sus propios equipos, a través de la aplicación web vulnerable. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 3: El siguiente segmento de código Swift lee la parte de texto de un esquema de URL personalizado que se transfirió a la aplicación (myapp://input_to_the_application) y la invocó. Los datos no fiables de la dirección URL se utilizan para representar el resultado HTML en un componente de UIWebView.


...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...


Como se muestran en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en el contenido HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 2, los datos se leen directamente desde el componente de la interfaz de usuario controlado por el usuario y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 3, una fuente externa a la aplicación de destino realiza una solicitud de URL mediante el esquema de URL personalizado de la aplicación de destino, y los datos sin validar de la solicitud de URL se leen posteriormente en la aplicación como datos de confianza y se incluyen en el contenido dinámico.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] MWR Labs Continued Adventures with iOS UIWebViews
[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.swift.cross_site_scripting_persistent
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS persistente (también conocido como almacenado), el origen no confiable suele ser una base de datos u otro almacén de datos back-end, mientras que en el caso de XSS reflejado suele ser una solicitud web.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código ASP consulta una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & objADORecordSet("name")
objADORecordSet.MoveNext
Wend
...


Este código funciona correctamente cuando los valores de name tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 2: el siguiente segmento de código ASP lee un identificador de empleado, eid, a partir de una solicitud HTTP y lo muestra al usuario.


...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..


Al igual que en el Example 1, este código funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.vb.cross_site_scripting_persistent
Abstract
Confiar en HTML, XML y otros tipos de codificación para validar la entrada de usuario puede provocar que el explorador ejecute código malintencionado.
Explanation
El uso de ciertos módulos de función de codificación, como cl_http_utility=>escape_html, impedirá algunos ataques de XSS, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y " que estén codificados en HTML, y aquellos que van más allá de <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estos módulos de función de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen los datos estáticos, Fortify Secure Coding Rulepacks informa sobre los hallazgos de Cross-Site Scripting incluso cuando se aplica la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, un origen que no es de confianza suele ser una solicitud web y, en el caso de XSS persistente (también conocido como almacenado), es el resultado de una consulta de base de datos.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código ABAP lee un identificador de empleado, eid, a partir de una solicitud HTTP, lo codifica en HTML y lo muestra al usuario.


...
eid = request->get_form_field( 'eid' ).
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = eid
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_eid.
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( e_eid ).
...


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código ABAP realiza una consulta en una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado codificado en HTML correspondiente.


...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.

SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = itab_employees-name
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_name.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( e_name ).
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
References
[1] SAP OSS notes 1582870, 1582867 and related notes for ABAP XSS support
[2] SAP OSS Notes 822881, 1600317, 1640092, 1671470 and 1638779 for XSS support in BSPs
[3] Understanding Malicious Content Mitigation for Web Developers CERT
[4] HTML 4.01 Specification W3
[5] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[6] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[18] Standards Mapping - FIPS200 SI
[19] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[20] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[21] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[22] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[23] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2021 A03 Injection
[28] 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)
[29] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[30] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[40] 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
[41] 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
[42] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[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.abap.cross_site_scripting_poor_validation
Abstract
Confiar en HTML, XML y otros tipos de codificación para validar la entrada de usuario puede provocar que el explorador ejecute código malintencionado.
Explanation
El uso de determinadas funciones de codificación impedirá algunos ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y " que estén codificados en HTML, y aquellos que van más allá de <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estas funciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen los datos estáticos, Fortify Secure Coding Rulepacks informa sobre los hallazgos de Cross-Site Scripting incluso cuando se aplica la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código ActionScript lee un identificador de empleado, eid, a partir de una solicitud HTTP, lo codifica en HTML y lo muestra al usuario.


var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + escape(eid);
...


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código ActionScript realiza una consulta en una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado codificado en HTML correspondiente.


stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + escape(name);
}


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 4
[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 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-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 116
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.actionscript.cross_site_scripting_poor_validation
Abstract
El envío de datos no validados al explorador web puede dar lugar a la ejecución de código malintencionado.
Explanation
Debido a la gran cantidad de posibles interacciones entre los datos proporcionados por el usuario y los analizadores del explorador web, no siempre es posible evaluar correctamente si la codificación aplicada es suficiente para proteger contra la vulnerabilidad XSS. Por lo tanto, Fortify Static Code Analyzer informa de detecciones de ataques de Cross-Site Scripting cuando se realiza la codificación y los presenta como problemas de Ataques de Cross-Site Scripting: validación débil.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable. En el caso de XSS reflejado, la fuente que no es de confianza suele ser una solicitud web, y en el caso de XSS persistente (también conocido como almacenado), es el resultado de una consulta de base de datos.

2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malicioso suele ser un segmento de código JavaScript, pero también puede ser HML, Flash o cualquier otro contenido activo que pueda ejecutar el explorador. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código Apex realiza consultas en una base de datos en busca de un nombre de contacto con un determinado ID y devuelve el nombre del empleado correspondiente, que después imprimirá el código de Visualforce.


...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...

<div onclick="this.innerHTML='Hello {!HTMLENCODE(variable)}'">Click me!</div>


Este código, a pesar del uso de HTMLENCODE, no valida adecuadamente los datos proporcionados por la base de datos y es vulnerable a XSS. Esto ocurre porque el contenido de variable se analiza mediante diferentes mecanismos (analizadores HTML y Javascript) y debe codificarse dos veces. De este modo, un atacante puede tener comandos malintencionados ejecutados en el explorador web del usuario sin tener que interactuar con la víctima, como en el caso de XSS reflejado. Este tipo de ataque, conocido como XSS almacenado (o persistente), puede ser muy difícil de detectar ya que los datos se proporcionan indirectamente a la función vulnerable y a que tiene un mayor impacto debido a la posibilidad de que afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 2: el siguiente segmento de código de Visualforce lee un parámetro de solicitud HTTP, username, y lo muestra al usuario.


<script>
document.write('{!HTMLENCODE($CurrentPage.parameters.username)}')
</script>


El código de este ejemplo está pensado para recibir solo texto alfanumérico y mostrarlo. Sin embargo, si username contiene metacaracteres o código fuente, el explorador web lo ejecutará. En este ejemplo, el uso de HTMLENCODE no es suficiente para evitar el ataque XSS porque la variable se procesa mediante el analizador Javascript.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay dos vectores, por los cuales un ataque XSS puede ejecutarse:

- Al igual que en el Example 1, la base de datos o cualquier otro almacén de datos puede proporcionar datos peligrosos a la aplicación que se incluirán en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el mejor lugar para almacenar contenido malintencionado es un área accesible a todos los usuarios, especialmente los que cuentan con privilegios elevados, que son los que con más probabilidad manejarán información confidencial o realizarán operaciones críticas.

- Al igual que en el Example 2, los datos se leen de la solicitud HTTP y se reflejan en la respuesta HTTP. El XSS reflejado se produce cuando un atacante proporciona contenido peligroso a una aplicación web vulnerable y después se refleja en el usuario y se ejecuta mediante el explorador. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a la víctima. Las direcciones URL diseñadas de esta forma son el núcleo de muchas tramas de suplantación de identidad, en las que un atacante tienta a la víctima para que visite la dirección URL. Después de que el sitio muestre el contenido al usuario, éste se ejecuta y puede realizar varias acciones, como enviar información confidencial privada, ejecutar operaciones no autorizadas en el equipo de la víctima, etc.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Salesforce Developers Technical Library Secure Coding Guidelines - Cross Site Scripting
[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 4
[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 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.apex.cross_site_scripting_poor_validation
Abstract
Confiar en HTML, XML y otros tipos de codificación para validar la entrada de usuario puede provocar que el explorador ejecute código malintencionado.
Explanation
El uso de determinadas funciones de codificación impedirá algunos ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y " que estén codificados en HTML, y aquellos que van más allá de <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estas funciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen los datos estáticos, Fortify Secure Coding Rulepacks informa sobre los hallazgos de Cross-Site Scripting incluso cuando se aplica la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el segmento de código de ASP.NET lee el número de Id. de empleado de una solicitud HTTP, lo codifica en HTML y lo muestra al usuario.

<script runat="server">
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
...
</script>


Donde Login y EmployeeID son controles de formulario definidos de la siguiente forma:


<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Ejemplo 2: el siguiente segmento de código de ASP.NET implementa las mismas funciones que en el Example 1, aunque lo hace mediante programación.

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);


El código de estos ejemplos funciona correctamente si Login contiene solo texto alfanumérico estándar. Si Login tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real consiste en que un atacante cree la URL malintencionada y, después, utilice el correo electrónico o algún tipo de truco de ingeniería social para conseguir que las víctimas hagan clic en el vínculo. En ese caso, estos mostrarán de forma inconsciente el contenido malintencionado a través de la aplicación web vulnerable y de nuevo en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 3: el siguiente segmento de código de ASP.NET realiza una consulta en una base de datos en relación con un empleado que dispone de un determinado Id. de empleado e imprime el nombre codificado en HTML correspondiente junto con el Id.

<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = Server.HtmlEncode(name);
</script>


Donde EmployeeName es un control de formulario definido como se indica a continuación:


<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Ejemplo 4: del mismo modo, el siguiente segmento de código de ASP .NET es equivalente desde una perspectiva funcional al Example 3, pero implementa mediante programación todos los elementos de formulario.

protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = Server.HtmlEncode(name);


Como en el Example 1 y el Example 2, estos segmentos de código funcionan correctamente cuando los valores de name presentan un comportamiento correcto. De lo contrario, no realizan ninguna acción para impedir ataques. Por otra parte, estos ejemplos de código pueden parecer menos peligrosos debido a que el valor de name se lee desde una base de datos, cuyo contenido administra aparentemente la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1 y el Example 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 3 y el Example 4, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.

Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, validación de solicitudes de ASP.NET y WCF). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Con la validación de solicitudes de ASP .NET, también proporcionamos pruebas cuando la validación se ha deshabilitado explícitamente. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Anti-Cross Site Scripting Library MSDN
[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 4
[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 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.dotnet.cross_site_scripting_poor_validation
Abstract
Confiar en HTML, XML y otros tipos de codificación para validar la entrada de usuario puede provocar que el explorador ejecute código malintencionado.
Explanation
El uso de determinadas funciones de codificación impedirá algunos ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y " que estén codificados en HTML, y aquellos que van más allá de <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estas funciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen los datos estáticos, Fortify Secure Coding Rulepacks informa sobre los hallazgos de Cross-Site Scripting incluso cuando se aplica la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, un origen que no es de confianza suele ser una solicitud web y, en el caso de XSS persistente (también conocido como almacenado), es el resultado de una consulta de base de datos.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código se lee en el parámetro text, desde una solicitud HTTP, se codifica mediante HTML y se muestra en un cuadro de alerta entre las etiquetas de secuencia de comandos.


"<script>alert('<CFOUTPUT>HTMLCodeFormat(#Form.text#)</CFOUTPUT>')</script>";


El código de este ejemplo funciona correctamente si text contiene solo texto alfanumérico estándar. Si text tiene una comilla simple, un paréntesis, y un punto y coma, finaliza el cuadro de texto alert tras lo cual se ejecutará el código.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- La aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 4
[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 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-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 116
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.cfml.cross_site_scripting_poor_validation
Abstract
Confiar en HTML, XML y otros tipos de codificación para validar la entrada de usuario puede provocar que el explorador ejecute código malintencionado.
Explanation
El uso de determinadas funciones de codificación impedirá algunos ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y " que estén codificados en HTML, y aquellos que van más allá de <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estas funciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen los datos estáticos, Fortify Secure Coding Rulepacks informa sobre los hallazgos de Cross-Site Scripting incluso cuando se aplica la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de Reflected XSS, el origen no confiable suele ser una solicitud web, mientras que en el caso de Persisted XSS (también conocido como Stored XSS) suele ser una base de datos u otro almacén de datos back-end.

2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.


Ejemplo 1: El siguiente segmento de código de Go lee un nombre de usuario, user, de una solicitud HTTP y lo muestra al usuario.

func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", html.EscapeString(user))
}


El código de este ejemplo funciona correctamente si user contiene solo texto alfanumérico estándar. Si user tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: El siguiente segmento de código de Go consulta una base de datos en busca de un empleado con un identificador determinado e imprime el nombre del empleado correspondiente.

func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", html.EscapeString(name))
}


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación adecuada de las entradas de todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso, ya que el direccionamiento indirecto causado por el almacén de datos dificulta la identificación de la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS se inició de este modo con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Son tres los vectores por los que un ataque XSS puede llegar a una víctima:

- Como se muestra en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un atacante hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, que luego se refleja en el usuario y se ejecuta en el explorador web. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Como se muestra en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el atacante puede realizar operaciones con privilegios en nombre del usuario u obtener acceso a datos confidenciales del usuario.

- Un origen externo a la aplicación almacena los datos peligrosos en una base de datos u otro almacén de datos. Posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 4
[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 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-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 116
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.golang.cross_site_scripting_poor_validation
Abstract
Confiar en HTML, XML y otros tipos de codificación para validar la entrada de usuario puede provocar que el explorador ejecute código malintencionado.
Explanation
El uso de determinadas construcciones de codificación como, por ejemplo, la etiqueta <c:out/> con el atributo escapeXml="true" (el comportamiento predeterminado), impide algunos de los ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que excedan los básicos <, >, & y " que estén codificados en código HTML, y aquellos que excedan <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estas construcciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen de forma estática los datos, Fortify Static Code Analyzer informa sobre las detecciones de ataques de Cross-Site Scripting incluso cuando se realiza la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, un origen que no es de confianza suele ser una solicitud web y, en el caso de XSS persistente (también conocido como almacenado), es el resultado de una consulta de base de datos.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Example 1: The following JSP code segment reads an employee ID, eid, from an HTTP request and displays it to the user via the <c:out/> tag.


Employee ID: <c:out value="${param.eid}"/>


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Example 2: The following JSP code segment queries a database for an employee with a given ID and prints the corresponding employee's name via the <c:out/> tag.


<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>

Employee Name: <c:out value="${name}"/>


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Algunos piensan que en los entornos móviles las vulnerabilidades de las aplicaciones web clásicas como los scripts de sitios no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Example 3: The following code enables JavaScript in Android's WebView (by default, JavaScript is disabled) and loads a page based on the value received from an Android intent.


...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(URLEncoder.encode(url));
...


Si el valor de url comienza por javascript:, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 3, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.

Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, Struts y Struts 2). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[4] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[5] INJECT-3: XML and HTML generation requires care Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[7] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[11] Standards Mapping - CIS Kubernetes Benchmark complete
[12] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[13] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[15] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[16] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[17] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[18] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[19] Standards Mapping - FIPS200 SI
[20] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[23] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[24] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[28] Standards Mapping - OWASP Top 10 2021 A03 Injection
[29] 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)
[30] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[31] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[41] 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
[42] 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
[43] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[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_poor_validation
Abstract
Confiar en HTML, XML y otros tipos de codificación para validar la entrada de usuario puede provocar que el explorador ejecute código malintencionado.
Explanation
El uso de determinadas funciones de codificación impedirá algunos ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y " que estén codificados en HTML, y aquellos que van más allá de <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estas funciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen los datos estáticos, Fortify Secure Coding Rulepacks informa sobre los hallazgos de Cross-Site Scripting incluso cuando se aplica la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS basado en DOM, los datos se leen desde un parámetro de URL u otro valor dentro del explorador, y se escriben en la página con código del cliente. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación. En el caso de XSS basado en DOM, el contenido malintencionado se ejecuta como parte de la creación de DOM (Modelo de objetos de documento), siempre que el explorador de la víctima analice la página HTML.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo: El siguiente segmento de código JavaScript lee el ID de un empleado, eid, a partir de una solicitud HTTP, escapa y se lo muestra en pantalla al usuario.


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



El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Como se muestra en el ejemplo, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- La aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 4
[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 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-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 116
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.javascript.cross_site_scripting_poor_validation
Abstract
Confiar en HTML, XML y otros tipos de codificación para validar la entrada de usuario puede provocar que el explorador ejecute código malintencionado.
Explanation
El uso de determinadas construcciones de codificación como, por ejemplo, la etiqueta <c:out/> con el atributo escapeXml="true" (el comportamiento predeterminado), impide algunos de los ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que excedan los básicos <, >, & y " que estén codificados en código HTML, y aquellos que excedan <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estas construcciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen de forma estática los datos, Fortify Static Code Analyzer informa sobre las detecciones de ataques de Cross-Site Scripting incluso cuando se realiza la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, un origen que no es de confianza suele ser una solicitud web y, en el caso de XSS persistente (también conocido como XSS almacenado), es el resultado de una consulta de base de datos.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.



El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.



Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Algunos piensan que en los entornos móviles las vulnerabilidades de las aplicaciones web clásicas como los scripts de sitios no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 3: el código siguiente habilita JavaScript en WebView de Android (JavaScript está deshabilitado de manera predeterminada) y carga una página basada en el valor recibido de una finalidad de Android.


...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(URLEncoder.encode(url))
...


Si el valor de url comienza por javascript:, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Son tres los vectores por los que un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 3, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.


Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, Struts y Spring MVC). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[4] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[5] INJECT-3: XML and HTML generation requires care Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[7] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[11] Standards Mapping - CIS Kubernetes Benchmark complete
[12] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[13] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[15] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[16] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[17] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[18] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[19] Standards Mapping - FIPS200 SI
[20] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[23] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[24] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[28] Standards Mapping - OWASP Top 10 2021 A03 Injection
[29] 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)
[30] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[31] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[41] 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
[42] 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
[43] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[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.kotlin.cross_site_scripting_poor_validation
Abstract
El método utiliza HTML, XML u otros tipos de codificación que no siempre son suficientes para impedir que el código malintencionado llegue hasta el explorador web.
Explanation
El uso de determinadas construcciones de codificación, tales como ESAPI o AntiXSS, evitará algunos ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y ", que se codifican con HTML y aquellos que van más allá de <, >, & " y ' que se codifican con XML pueden tener un significado meta. Confiar en estas construcciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen de forma estática los datos, Fortify Static Code Analyzer informa sobre las detecciones de ataques de Cross-Site Scripting incluso cuando se realiza la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una página web a través de un origen que no es de confianza. En el caso de XSS reflejado, el origen que no es de confianza suele ser un componente de usuario, un controlador del esquema de URL o una notificación, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un componente UIWebView sin que se validen.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

En los ejemplos siguientes se resaltan las instancias XSS aprovechables que se codifican mediante una API de codificación:

Ejemplo 1: el siguiente segmento de código Objective-C lee la parte de texto de un esquema de URL personalizado que se pasó a la aplicación (myapp://input_to_the_application) y la invocó. Los datos no fiables de la dirección URL se utilizan para representar el resultado HTML en un componente de UIWebView.


...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
...
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
NSString *htmlPage = [NSString stringWithFormat: @"%@/%@/%@", @"...<input type=text onclick=\"callFunction('",
[DefaultEncoder encodeForHTML:partAfterSlashSlash],
@"')\" />"];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:htmlPage baseURL:nil];
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso porque el valor del name se lee a partir de una base de datos y se codifica en HTML. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Los ataques que proporciona el usuario malintencionado podrían omitir los caracteres codificados o colocar la entrada en un contexto que no se vea afectada por la codificación HTML. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestran en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en el contenido HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente desde un esquema de URL personalizado y se reflejan en el contenido de una respuesta de UIWebView. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación de iOS vulnerable, lo que se reflejará en el usuario y que el navegador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL de esquema personalizado que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL construidas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un intruso convence a las víctimas para que visiten una dirección URL que hace referencia a una aplicación vulnerable. Después de que la aplicación refleje el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] MWR Labs Continued Adventures with iOS UIWebViews
[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 4
[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 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.objc.cross_site_scripting_poor_validation
Abstract
Confiar en HTML, XML y otros tipos de codificación para validar la entrada de usuario puede provocar que el explorador ejecute código malintencionado.
Explanation
El uso de determinadas funciones de codificación, como htmlspecialchars() o htmlentities(), impedirá algunos ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y " que estén codificados en HTML y aquellos que van más allá de <, >, &, " y ' (solo cuando se estableció ENT_QUOTES) que estén codificados en código XML pueden adquirir un significado meta. Confiar en estas funciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen los datos estáticos, Fortify Secure Coding Rulepacks informa sobre los hallazgos de Cross-Site Scripting incluso cuando se aplica la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, un origen que no es de confianza suele ser una solicitud web y, en el caso de XSS persistente (también conocido como almacenado), es el resultado de una consulta de base de datos.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código se lee en el parámetro text, desde una solicitud HTTP, se codifica mediante HTML y se muestra en un cuadro de alerta entre las etiquetas de script.


<?php
$var=$_GET['text'];
...
$var2=htmlspecialchars($var);
echo "<script>alert('$var2')</script>";
?>


El código de este ejemplo funciona correctamente si text contiene solo texto alfanumérico estándar. Si text tiene una comilla simple, un paréntesis, y un punto y coma, finaliza el cuadro de texto alert tras lo cual se ejecutará el código.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- La aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 4
[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 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-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 116
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.php.cross_site_scripting_poor_validation
Abstract
Confiar en HTML, XML y otros tipos de codificación para validar la entrada de usuario puede provocar que el explorador ejecute código malintencionado.
Explanation
El uso de determinadas funciones de codificación impedirá algunos ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y " que estén codificados en HTML, y aquellos que van más allá de <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estas funciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen los datos estáticos, Fortify Secure Coding Rulepacks informa sobre los hallazgos de Cross-Site Scripting incluso cuando se aplica la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código lee un identificador de empleado, eid, a partir de una solicitud HTTP, lo codifica con la dirección URL y lo muestra al usuario.


...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || HTMLDB_UTIL.url_encode(eid) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código realiza una consulta en una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado codificado con la dirección URL correspondiente.


...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || HTMLDB_UTIL.url_encode(name) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 4
[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 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-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 116
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.sql.cross_site_scripting_poor_validation
Abstract
Confiar en HTML, XML y otros tipos de codificación para validar la entrada de usuario puede provocar que el explorador ejecute código malintencionado.
Explanation
El uso de determinadas funciones de codificación impedirá algunos ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y " que estén codificados en HTML, y aquellos que van más allá de <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estas funciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen los datos estáticos, Fortify Secure Coding Rulepacks informa sobre los hallazgos de Cross-Site Scripting incluso cuando se aplica la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código Python lee un identificador de empleado, eid, a partir de una solicitud HTTP, lo codifica en HTML y lo muestra al usuario.


req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + escape(eid))


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código Python realiza una consulta en una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado codificado en HTML correspondiente.


...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + escape(row["emp"]))
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 4
[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 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-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 116
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.python.cross_site_scripting_poor_validation
Abstract
Confiar en HTML, XML y otros tipos de codificación para validar la entrada de usuario puede provocar que el explorador ejecute código malintencionado.
Explanation
El uso de determinadas funciones de codificación impedirá algunos ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y " que estén codificados en HTML, y aquellos que van más allá de <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estas funciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen los datos estáticos, Fortify Secure Coding Rulepacks informa sobre los hallazgos de Cross-Site Scripting incluso cuando se aplica la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código podría lee un identificador de empleado, eid, a partir de una solicitud HTTP, lo codifica en HTML y lo muestra al usuario.


eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como XSS reflejado; sin embargo, tenga en cuenta que si utiliza Rack::Request#params() como se mostró en el Example 1, se observan los parámetros GET y POST, de modo que puede ser vulnerable a diferentes tipos de ataques además de simplemente tener el código malintencionado anexado a la dirección URL.

Ejemplo 2: el siguiente segmento de código Ruby realiza una consulta en una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado codificado en HTML correspondiente.


...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada de todos los datos almacenados en la base de datos, un atacante podría ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 4
[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 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-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 116
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.ruby.cross_site_scripting_poor_validation
Abstract
Confiar en HTML, XML y otros tipos de codificación para validar la entrada de usuario puede provocar que el explorador ejecute código malintencionado.
Explanation
El uso de determinadas construcciones de codificación impedirá algunos ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y " que estén codificados en HTML, y aquellos que van más allá de <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estas construcciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen de forma estática los datos, Fortify Static Code Analyzer informa sobre las detecciones de ataques de Cross-Site Scripting incluso cuando se realiza la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, un origen que no es de confianza suele ser una solicitud web y, en el caso de XSS persistente (también conocido como almacenado), es el resultado de una consulta de base de datos.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo: el siguiente segmento de código de controlador de reproducción lee un identificador de empleado, eid, a partir de una solicitud HTTP y lo muestra al usuario.


def getEmployee = Action { implicit request =>
var eid = request.getQueryString("eid")

eid = StringEscapeUtils.escapeHtml(eid); // insufficient validation

val employee = getEmployee(eid)

if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.
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 4
[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 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.scala.cross_site_scripting_poor_validation
Abstract
El método utiliza HTML, XML u otros tipos de codificación que no siempre son suficientes para impedir que el código malintencionado llegue hasta el explorador web.
Explanation
El uso de determinadas construcciones de codificación, tales como ESAPI o AntiXSS, evitará algunos ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y ", que se codifican con HTML y aquellos que van más allá de <, >, & " y ' que se codifican con XML pueden tener un significado meta. Confiar en estas construcciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen de forma estática los datos, Fortify Static Code Analyzer informa sobre las detecciones de ataques de Cross-Site Scripting incluso cuando se realiza la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una página web a través de un origen que no es de confianza. En el caso de XSS reflejado, el origen que no es de confianza suele ser un componente de usuario, un controlador del esquema de URL o una notificación, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un componente UIWebView sin que se validen.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

En los ejemplos siguientes se resaltan las instancias XSS aprovechables que se codifican mediante una API de codificación:

Ejemplo 1: El siguiente segmento de código Swift lee la parte de texto de un esquema de URL personalizado que se transfirió a la aplicación (myapp://input_to_the_application) y la invocó. Los datos no fiables de la dirección URL se utilizan para representar el resultado HTML en un componente de UIWebView.


...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso porque el valor del name se lee a partir de una base de datos y se codifica en HTML. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Los ataques que proporciona el usuario malintencionado podrían omitir los caracteres codificados o colocar la entrada en un contexto que no se vea afectada por la codificación HTML. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Ejemplo 3: El siguiente código lee el contenido de un UITextField y lo muestra al usuario en una WKWebView:


...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...


El código de este ejemplo funciona correctamente si el texto en inputTextField contiene solo texto alfanumérico estándar. Si el texto en inputTextField incluye metacaracteres o código fuente, el explorador web puede ejecutar la entrada como código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. ¿Por qué alguien escribiría algo que provocara la ejecución de código malintencionado en su propio dispositivo? El peligro real es que un atacante puede usar el correo electrónico o algún tipo de truco de ingeniería social para conseguir que las víctimas realicen tales acciones. Si lo consiguen, las víctimas del ataque pueden reflejar de manera inconsciente el contenido malintencionado en sus propios equipos, a través de la aplicación web vulnerable. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Como se muestran en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en el contenido HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente desde un esquema de URL personalizado y se reflejan en el contenido de una respuesta de UIWebView. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación de iOS vulnerable, lo que se reflejará en el usuario y que el navegador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL de esquema personalizado que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL construidas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un intruso convence a las víctimas para que visiten una dirección URL que hace referencia a una aplicación vulnerable. Después de que la aplicación refleje el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 3, una fuente externa a la aplicación de destino realiza una solicitud de URL mediante el esquema de URL personalizado de la aplicación de destino, y los datos sin validar de la solicitud de URL se leen posteriormente en la aplicación como datos de confianza y se incluyen en el contenido dinámico.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] MWR Labs Continued Adventures with iOS UIWebViews
[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 4
[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 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.swift.cross_site_scripting_poor_validation
Abstract
Confiar en HTML, XML y otros tipos de codificación para validar la entrada de usuario puede provocar que el explorador ejecute código malintencionado.
Explanation
El uso de determinadas funciones de codificación impedirá algunos ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y " que estén codificados en HTML, y aquellos que van más allá de <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estas funciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen los datos estáticos, Fortify Secure Coding Rulepacks informa sobre los hallazgos de Cross-Site Scripting incluso cuando se aplica la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código ASP lee un identificador de empleado, eid, a partir de una solicitud HTTP, lo codifica en HTML y lo muestra al usuario.


...
eid = Request("eid")
Response.Write "Employee ID:" & Server.HTMLEncode(eid) & "<br/>"
..


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código ASP realiza una consulta en una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado codificado en HTML correspondiente.


...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & Server.HTMLEncode(objADORecordSet("name"))
objADORecordSet.MoveNext
Wend
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 4
[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 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-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 116
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.vb.cross_site_scripting_poor_validation
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: El siguiente segmento de código ABAP lee un ID de empleado, eid, desde la solicitud HTTP y lo muestra al usuario.


...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código ABAP realiza una consulta en una base de datos sobre un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.

SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
References
[1] SAP OSS notes 1582870, 1582867 and related notes for ABAP XSS support
[2] SAP OSS Notes 822881, 1600317, 1640092, 1671470 and 1638779 for XSS support in BSPs
[3] Understanding Malicious Content Mitigation for Web Developers CERT
[4] HTML 4.01 Specification W3
[5] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[6] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[7] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[8] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[18] Standards Mapping - FIPS200 SI
[19] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[20] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[21] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[22] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[23] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2021 A03 Injection
[28] 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)
[29] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[30] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[40] 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
[41] 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
[42] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[43] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[44] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[45] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[66] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[67] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.abap.cross_site_scripting_reflected
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código ActionScript lee un identificador de empleado, eid, a partir de una solicitud HTTP y lo muestra al usuario.


var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código ActionScript consulta una base de datos de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + name;
}


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.actionscript.cross_site_scripting_reflected
Abstract
El envío de datos no validados al explorador web puede dar lugar a la ejecución de código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable. En el caso de XSS reflejado, la fuente que no es de confianza suele ser una solicitud web, y en el caso de XSS persistente (también conocido como almacenado), es el resultado de una consulta de base de datos.

2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malicioso suele ser un segmento de código JavaScript, pero también puede ser HTML, Flash o cualquier otro contenido activo que pueda ejecutar el explorador. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.


Ejemplo 1: el siguiente segmento de código de Visualforce lee un parámetro de solicitud HTTP, username, y lo muestra al usuario.


<script>
document.write('{!$CurrentPage.parameters.username}')
</script>


El código de este ejemplo está pensado para recibir solo texto alfanumérico y mostrarlo. Sin embargo, si username contiene metacaracteres o código fuente, el explorador web lo ejecutará.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código Apex realiza consultas en una base de datos en busca de un nombre de contacto con un determinado ID y devuelve el nombre del empleado correspondiente, que después imprimirá el código de Visualforce.


...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...

<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>


Al igual que en el Example 1, este código se comporta correctamente cuando los valores de name están definidos correctamente como caracteres alfanuméricos, pero no funciona para comprobar si hay datos malintencionados. Incluso al leer a partir de una base de datos, el valor debe validarse adecuadamente, porque el contenido de la base de datos puede originarse a partir de datos proporcionados por el usuario. De este modo, un atacante puede tener comandos malintencionados ejecutados en el explorador web del usuario sin tener que interactuar con la víctima, como en el caso de XSS reflejado. Este tipo de ataque, conocido como XSS almacenado (o persistente), puede ser muy difícil de detectar ya que los datos se proporcionan indirectamente a la función vulnerable y a que tiene un mayor impacto debido a la posibilidad de que afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay dos vectores, por los cuales un ataque XSS puede ejecutarse:

- Al igual que en el Example 1, los datos se leen de la solicitud HTTP y se reflejan en la respuesta HTTP. El XSS reflejado se produce cuando un atacante proporciona contenido peligroso a una aplicación web vulnerable y después se refleja en el usuario y se ejecuta mediante el explorador. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a la víctima. Las direcciones URL diseñadas de esta forma son el núcleo de muchas tramas de suplantación de identidad, en las que un atacante tienta a la víctima para que visite la dirección URL. Después de que el sitio muestre el contenido al usuario, éste se ejecuta y puede realizar varias acciones, como enviar información confidencial privada, ejecutar operaciones no autorizadas en el equipo de la víctima, etc.

- Al igual que en el Example 2, la base de datos o cualquier otro almacén de datos puede proporcionar datos peligrosos a la aplicación que se incluirán en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el mejor lugar para almacenar contenido malintencionado es un área accesible a todos los usuarios, especialmente los que cuentan con privilegios elevados, que son los que con más probabilidad manejarán información confidencial o realizarán operaciones críticas.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Salesforce Developers Technical Library Secure Coding Guidelines - Cross Site Scripting
[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.apex.cross_site_scripting_reflected
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente formulario web de ASP.NET lee un número de id. de empleado de una solicitud HTTP y lo muestra al usuario.

<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>


Donde Login y EmployeeID son controles de formulario definidos de la siguiente forma:


<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Ejemplo 2: El siguiente segmento de código de ASP.NET muestra el método de implementación mediante programación del Example 1.

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;


El código de estos ejemplos funciona correctamente si Login contiene solo texto alfanumérico estándar. Si Login tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real consiste en que un atacante cree la URL malintencionada y, después, utilice el correo electrónico o algún tipo de truco de ingeniería social para conseguir que las víctimas hagan clic en el vínculo. En ese caso, estos mostrarán de forma inconsciente el contenido malintencionado a través de la aplicación web vulnerable y de nuevo en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 3: el formulario web de ASP.NET realiza una consulta en una base de datos en relación con un empleado que dispone de un determinado Id. de empleado e imprime el nombre correspondiente junto con el Id.

<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>


Donde EmployeeName es un control de formulario definido como se indica a continuación:


<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Ejemplo 4: El siguiente segmento de código de ASP .NET es equivalente desde una perspectiva funcional al Example 3, pero implementa mediante programación todos los elementos de formulario.

protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;


Como en el Example 1 y el Example 2, estos códigos de muestra funcionan correctamente cuando los valores de name presentan un comportamiento correcto. De lo contrario, no realizan ninguna acción para impedir ataques. Por otra parte, estos ejemplos pueden parecer menos peligros debido a que el valor de name se lee desde una base de datos, cuyo contenido administra aparentemente la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1 y el Example 2, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 3 y el Example 4, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.

Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, validación de solicitudes de ASP.NET y WCF). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Con la validación de solicitudes de ASP .NET, también proporcionamos pruebas cuando la validación se ha deshabilitado explícitamente. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Anti-Cross Site Scripting Library MSDN
[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.dotnet.cross_site_scripting_reflected
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.

2. Los datos se incluyen en el contenido dinámico que se envía a un explorador web sin que se validen.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código lee un identificador de empleado, EID, a partir de un formulario HTML y lo muestra al usuario.


...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.

EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...


El código de este ejemplo funciona correctamente si EID contiene solo texto alfanumérico estándar. Si EID tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código consulta una base de datos de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.

EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de ENAME presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de ENAME se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de ENAME se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS almacenado, es especialmente insidioso porque el direccionamiento indirecto que causa el almacén de datos dificulta la identificación de la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente del formulario HTML y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Las explotaciones de XSS almacenado se producen cuando un atacante

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.cobol.cross_site_scripting_reflected
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código CFML lee un identificador de empleado, eid, de un formulario web y lo muestra al usuario.


<cfoutput>
Employee ID: #Form.eid#
</cfoutput>


El código de este ejemplo funciona correctamente si Form.eid contiene solo texto alfanumérico estándar. Si Form.eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código CFML realiza una consulta en una base de datos sobre un empleado con un identificador dado e imprime el nombre del empleado correspondiente.

 
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] ColdFusion Developer Center: Security Macromedia
[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.cfml.cross_site_scripting_reflected
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de Reflected XSS, el origen no confiable suele ser una solicitud web, mientras que en el caso de Persisted XSS (también conocido como Stored XSS) suele ser una base de datos u otro almacén de datos back-end.

2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.


Ejemplo 1: El siguiente segmento de código de Go lee un nombre de usuario, user, de una solicitud HTTP y lo muestra al usuario.

func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}


El código de este ejemplo funciona correctamente si user contiene solo texto alfanumérico estándar. Si user tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: El siguiente segmento de código de Go consulta una base de datos en busca de un empleado con un identificador determinado e imprime el nombre del empleado correspondiente.

func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", name)
}


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación adecuada de las entradas de todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso, ya que el direccionamiento indirecto causado por el almacén de datos dificulta la identificación de la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS se inició de este modo con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Son tres los vectores por los que un ataque XSS puede llegar a una víctima:

- Como se muestra en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un atacante hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, que luego se refleja en el usuario y se ejecuta en el explorador web. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Como se muestra en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el atacante puede realizar operaciones con privilegios en nombre del usuario u obtener acceso a datos confidenciales del usuario.

- Un origen externo a la aplicación almacena los datos peligrosos en una base de datos u otro almacén de datos. Posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.golang.cross_site_scripting_reflected
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código JSP lee un identificador de empleado, eid, a partir de una solicitud HTTP y lo muestra al usuario.


<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código JSP consulta una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>

Employee Name: <%= name %>


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Algunos piensan que en los entornos móviles las vulnerabilidades de las aplicaciones web clásicas como los scripts de sitios no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Example 3: The following code enables JavaScript in Android's WebView (by default, JavaScript is disabled) and loads a page based on the value received from an Android intent.


...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...


Si el valor de url comienza por javascript:, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 3, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.

Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, Struts y Struts 2). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[4] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[5] INJECT-3: XML and HTML generation requires care Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[7] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[11] Standards Mapping - CIS Kubernetes Benchmark complete
[12] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[13] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[15] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[16] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[17] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[18] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[19] Standards Mapping - FIPS200 SI
[20] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[23] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[24] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[28] Standards Mapping - OWASP Top 10 2021 A03 Injection
[29] 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)
[30] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[31] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[41] 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
[42] 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
[43] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[44] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[45] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[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_reflected
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código Node.js lee un identificador de empleado, eid, a partir de una solicitud HTTP y lo muestra al usuario.


var http = require('http');
var url = require('url');

...

function listener(request, response){
var eid = url.parse(request.url, true)['query']['eid'];
if (eid !== undefined){
response.write('<p>Welcome, ' + eid + '!</p>');
}
...
}
...
http.createServer(listener).listen(8080);


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código consulta una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


var http = require('http');
...

function listener(request, response){
connection.query('SELECT * FROM emp WHERE eid="' + eid + '"', function(err, rows){
if (!err && rows.length > 0){
response.write('<p>Welcome, ' + rows[0].name + '!</p>');
}
...
});
...
}
...
http.createServer(listener).listen(8080);


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.javascript.cross_site_scripting_reflected
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de Reflected XSS, el origen no confiable suele ser una solicitud web, mientras que en el caso de Persisted XSS (también conocido como Stored XSS) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente código lee un ID de empleado, eid, desde una solicitud de servlet HTTP y, a continuación, muestra el valor al usuario en la respuesta del servlet.


val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código realiza consultas en una base de datos en busca de un empleado con un determinado ID e imprime el nombre del empleado correspondiente en la respuesta del servlet.


val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Algunos piensan que en los entornos móviles las vulnerabilidades de las aplicaciones web clásicas como los scripts de sitios no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 3: el código siguiente habilita JavaScript en WebView de Android (JavaScript está deshabilitado de manera predeterminada) y carga una página basada en el valor recibido de una finalidad de Android.


...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...


Si el valor de url comienza por javascript:, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Son tres los vectores por los que un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 3, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.


Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, Struts y Spring MVC). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[4] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[5] INJECT-3: XML and HTML generation requires care Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[7] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[11] Standards Mapping - CIS Kubernetes Benchmark complete
[12] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[13] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[15] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[16] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[17] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[18] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[19] Standards Mapping - FIPS200 SI
[20] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[23] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[24] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[28] Standards Mapping - OWASP Top 10 2021 A03 Injection
[29] 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)
[30] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[31] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[41] 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
[42] 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
[43] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[44] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[45] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[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.kotlin.cross_site_scripting_reflected
Abstract
El método envía datos no validados a un explorador web, lo que puede provocar que el explorador ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una página web a través de un origen que no es de confianza. En el caso de XSS reflejado, el origen que no es de confianza suele ser un componente de usuario, un controlador del esquema de URL o una notificación, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un componente UIWebView sin que se validen.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.


Ejemplo 1: el siguiente segmento de código Objective-C lee la parte de texto de un esquema de URL personalizado que se pasó a la aplicación (myapp://input_to_the_application) y la invocó. Los datos no fiables de la dirección URL se utilizan para representar el resultado HTML en un componente de UIWebView.


- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {

UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]

...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestran en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en el contenido HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente desde un esquema de URL personalizado y se reflejan en el contenido de una respuesta de UIWebView. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación de iOS vulnerable, lo que se reflejará en el usuario y que el navegador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL de esquema personalizado que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL construidas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un intruso convence a las víctimas para que visiten una dirección URL que hace referencia a una aplicación vulnerable. Después de que la aplicación refleje el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] MWR Labs Continued Adventures with iOS UIWebViews
[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.objc.cross_site_scripting_reflected
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código PHP lee un identificador de empleado, eid, desde una solicitud HTTP y la muestra al usuario.


<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código PHP realiza una consulta en una base de datos sobre un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


<?php...
$con = mysql_connect($server,$user,$password);
...
$result = mysql_query("select * from emp where id="+eid);
$row = mysql_fetch_array($result)
echo 'Employee name: ', mysql_result($row,0,'name');
...
?>


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.php.cross_site_scripting_reflected
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código lee un identificador de empleado, eid, a partir de una solicitud HTTP y lo muestra al usuario.


...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || eid || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código consulta una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || name || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.sql.cross_site_scripting_reflected
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: El siguiente segmento de código Python lee un ID de empleado, eid, de una solicitud HTTP y la muestra al usuario.


req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: El siguiente segmento de código Python consulta una base de datos de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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_reflected
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: El siguiente segmento de código de Ruby lee un ID de empleado, eid, de una solicitud HTTP y la muestra al usuario.


eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como XSS reflejado; sin embargo, tenga en cuenta que si utiliza Rack::Request#params() como se mostró en el Example 1, se observan los parámetros GET y POST, de modo que puede ser vulnerable a diferentes tipos de ataques además de simplemente tener el código malintencionado anexado a la dirección URL.

Ejemplo 2: El siguiente segmento de código de Ruby consulta una base de datos de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.ruby.cross_site_scripting_reflected
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de scripts de sitios (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: El siguiente segmento de código de controlador de reproducción lee un identificador de empleado, eid, a partir de una solicitud HTTP y lo muestra al usuario.


def getEmployee = Action { implicit request =>
val eid = request.getQueryString("eid")

val employee = getEmployee(eid)

if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[4] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[5] INJECT-3: XML and HTML generation requires care Oracle
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[7] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[11] Standards Mapping - CIS Kubernetes Benchmark complete
[12] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[13] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[14] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[15] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[16] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[17] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[18] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[19] Standards Mapping - FIPS200 SI
[20] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[23] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[24] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[27] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[28] Standards Mapping - OWASP Top 10 2021 A03 Injection
[29] 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)
[30] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[31] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[41] 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
[42] 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
[43] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[44] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[45] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[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.scala.cross_site_scripting_reflected
Abstract
El método envía datos no validados a un explorador web, lo que puede provocar que el explorador ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una página web a través de un origen que no es de confianza. En el caso de XSS reflejado, el origen que no es de confianza suele ser un componente de usuario, un controlador del esquema de URL o una notificación, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un componente WKWebView sin que se validen.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: El siguiente código lee el contenido de un UITextField y lo muestra al usuario en una WKWebView:


...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...


El código de este ejemplo funciona correctamente si el texto en inputTextField contiene solo texto alfanumérico estándar. Si el texto en inputTextField incluye metacaracteres o código fuente, el explorador web puede ejecutar la entrada como código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. ¿Por qué alguien escribiría algo que provocara la ejecución de código malintencionado en su propio dispositivo? El peligro real es que un atacante puede usar el correo electrónico o algún tipo de truco de ingeniería social para conseguir que las víctimas realicen tales acciones. Si lo consiguen, las víctimas del ataque pueden reflejar de manera inconsciente el contenido malintencionado en sus propios equipos, a través de la aplicación web vulnerable. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: El siguiente segmento de código Swift lee la parte de texto de un esquema de URL personalizado que se transfirió a la aplicación (myapp://input_to_the_application) y la invocó. Los datos no fiables de la dirección URL se utilizan para representar el resultado HTML en un componente de UIWebView.


func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}


Al igual que en el Example 2, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestran en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en el contenido HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente desde el componente de la interfaz de usuario controlado por el usuario y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, una fuente externa a la aplicación de destino realiza una solicitud de URL mediante el esquema de URL personalizado de la aplicación de destino, y los datos sin validar de la solicitud de URL se leen posteriormente en la aplicación como datos de confianza y se incluyen en el contenido dinámico.

- Al igual que en el Example 3, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] MWR Labs Continued Adventures with iOS UIWebViews
[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.swift.cross_site_scripting_reflected
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código ASP lee un identificador de empleado, eid, a partir de una solicitud HTTP y lo muestra al usuario.


...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..


El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código ASP consulta una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.


...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & objADORecordSet("name")
objADORecordSet.MoveNext
Wend
...


Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
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 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.vb.cross_site_scripting_reflected
Abstract
El envío de datos no validados a un explorador web puede dar lugar a que este ejecute código malintencionado.
Explanation
Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En SAPUI5 puede crear controles personalizados extendiendo otros. Dado que estos controles están pensados para su uso genérico, el desarrollador debería esperar que los datos controlados por los usuarios se pasen a uno de sus atributos.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación. En el caso de un control de SAPUI5, el contenido malintencionado se procesa como parte del control.

El contenido malintencionado en un control de SAPUI5 adopta la forma de un segmento de código JavaScript o cualquier otro tipo de código que el explorador ejecute. Dado que se supone que los controles de SAPUI5 generalmente se reutilizan una y otra vez, una instancia de una aplicación podría no pasar directamente datos maliciosos al control, pero se debería tratar de igual modo como una deficiencia estándar de XSS con base en DOM. Un cambio trivial en el código de la aplicación podría suponer un traspaso de información maliciosa. La única excepción se da cuando el control genera dinámicamente HTML de forma insegura, tal como el de la propiedad content de control de sap.ui.core.HTML.

Ejemplo 1: Considere el control personalizado:


sap.ui.define([
'sap/ui/core/Control'
], function (Control) {
return Control.extend('CustomControl', {
metadata: {
properties: {
foo: { type: 'string', defaultValue: '' }
}
},
renderer: {
render: function (oRm, oControl) {
oRm.write('<div>' + oControl.getId() + ':' + oControl.getFoo() + '</div>')
}
},
init: function () { }
})
})


El atributo de foo puede pasarse con datos controlados por el usuario desde otra parte de la aplicación que deberá ser procesada directamente en el DOM.

Este ejemplo de código funciona correctamente si la información pasada al foo de atributo contiene solo texto alfanumérico estándar. Si foo tiene un valor que incluye metacaracteres o código fuente, una vez que el control se haya procesado, el código se agrega al DOM para que el explorador lo ejecute.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Cross-Site Scripting in SAPUI5-based Web Applications SAP
[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_sapui5_control