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

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

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

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

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

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

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

[12] Standards Mapping - FIPS200 SI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[62] 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;
...

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 Top 10 2004 A4 Cross Site Scripting

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 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 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I

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

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

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

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

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

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

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

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

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

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

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

[11] Standards Mapping - FIPS200 SI

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

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

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

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

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

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

[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.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