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.

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 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 - Common Weakness Enumeration CWE ID 79, CWE ID 80

[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079

[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079

[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079

[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079

[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079

[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754

[13] Standards Mapping - FIPS200 SI

[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data

[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)

[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation

[17] 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)

[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection

[19] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation

[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4

[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 - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4

[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1

[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7

[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7

[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7

[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7

[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7

[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[36] 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

[37] 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

[38] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079

[39] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079

[40] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079

[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.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[58] Standards Mapping - Security Technical Implementation Guide Version 4.1 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 - Security Technical Implementation Guide Version 6.1 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_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


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 - Common Weakness Enumeration CWE ID 79, CWE ID 80

[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079

[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079

[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079

[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079

[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079

[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754

[10] Standards Mapping - FIPS200 SI

[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data

[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)

[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation

[14] 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)

[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection

[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation

[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4

[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting

[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)

[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)

[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)

[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)

[23] Standards Mapping - OWASP Top 10 2021 A03 Injection

[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4

[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1

[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7

[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7

[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7

[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7

[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7

[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[33] 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

[34] 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

[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079

[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079

[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079

[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I

[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I

[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I

[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I

[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I

[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I

[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I

[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I

[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I

[60] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)

[61] 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