Se genera una vulnerabilidad de Cross-site Request Forgery (CSRF) cuando:
1. Una aplicación web utiliza cookies de sesión.

2. La aplicación actúa en una solicitud de HTTP sin verificar si la solicitud se realizó con el consentimiento del usuario.

De forma predeterminada, las páginas de Visualforce se representan con campos de formulario ocultos que sirven como tokens anti-CSRF. Estos tokens se incluyen en las solicitudes que se envían desde dentro de la página y el servidor verifica la validez de los tokens antes de ejecutar los métodos o comandos de acción correspondientes. Sin embargo, esta defensa integrada no se aplica a los métodos de acción de página ni a los constructores de controladores de página personalizados porque se ejecutan antes de que se generen los tokens anti-CSRF durante la carga de la página.

Ejemplo 1: La siguiente página de Visualforce declara un controlador personalizado MyAccountActions y un método de acción de página pageAction(). El método pageAction() se ejecuta al visitar la URL de la página y el servidor no comprueba los tokens anti-CSRF.

<apex:page controller="MyAccountActions" action="{!pageAction}">
    ...
</apex:page>

public class MyAccountActions {

    ...
    public void pageAction() {
        Map<String,String> reqParams = ApexPages.currentPage().getParameters();
        if (params.containsKey('id')) {
            Id id = reqParams.get('id');
            Account acct = [SELECT Id,Name FROM Account WHERE Id = :id];
            delete acct;
        }
    }
    ...
}

Un atacante podría configurar un sitio web malintencionado que contuviese el siguiente código:

<img src="http://my-org.my.salesforce.com/apex/mypage?id=YellowSubmarine" height=1 width=1/>

Si un administrador de la página de Visualforce visita la página malintencionada mientras tiene una sesión activa en el sitio, borrará involuntariamente cuentas para el atacante.

Se genera una vulnerabilidad de Cross-site Request Forgery (CSRF) cuando:
1. Una aplicación web utiliza cookies de sesión.
2. La aplicación actúa en una solicitud de HTTP sin verificar si la solicitud se realizó con el consentimiento del usuario.

Ejemplo 1: En el siguiente ejemplo, una aplicación web permite que los administradores creen cuentas nuevas:

  RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");
  body = addToPost(body, new_username);
  body = addToPost(body, new_passwd);
  rb.sendRequest(body, new NewAccountCallback(callback));

Un atacante podría configurar un sitio web malintencionado que contuviese el siguiente código:

  RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "http://www.example.com/new_user");
  body = addToPost(body, "attacker";
  body = addToPost(body, "haha");
  rb.sendRequest(body, new NewAccountCallback(callback));

Si un administrador de example.com visita la página malintencionada mientras tiene una sesión activa en el sitio, creará involuntariamente una cuenta para el atacante. Esto es lo que se denomina un ataque CSRF. Este ataque es posible porque la aplicación no tiene forma de determinar la procedencia de la solicitud. Todas las solicitudes podrían ser acciones válidas elegidas por el usuario o acciones engañosas determinadas por un atacante. El atacante no ve la página web que la solicitud falsa genera, por lo que esta técnica de ataque solo es útil para las solicitudes que alteran el estado de la aplicación.

Las aplicaciones que pasan el identificador de sesión en la URL en lugar de hacerlo en una cookie no tienen problemas de CSRF, ya que el atacante no tiene forma de acceder al identificador de sesión ni incluirlo como parte de la solicitud falsa.

Algunos marcos de trabajo incluyen automáticamente nonces de CSRF para proteger las aplicaciones. Si se deshabilita esta función, la aplicación puede quedar en peligro.

Ejemplo 2: Esta aplicación protegida con Spring Security deshabilita de forma explícita la protección CSRF.

	<http auto-config="true">
        ...
        <csrf disabled="true"/>
	</http>

Una vulnerabilidad de falsificación de solicitud entre sitios (CSRF) ocurre cuando:
1. Una aplicación web utiliza cookies de la sesión.

2. La aplicación actúa con una solicitud de HTTP sin verificar si la solicitud se realizó con el consentimiento del usuario.



Un nonce es un valor aleatorio criptográfico que se envía con un mensaje para evitar ataques de reproducción. Si la solicitud no contiene un nonce que demuestre su procedencia, el código que maneja la solicitud es vulnerable a un ataque CSRF (a menos que no cambie el estado de la aplicación). Esto significa que una aplicación web que utiliza cookies de sesión debe tomar precauciones especiales para garantizar que un atacante no pueda engañar a los usuarios para que envíen solicitudes falsas. Imagine una aplicación web que permita a los administradores crear nuevas cuentas de la siguiente manera:

  var req = new XMLHttpRequest();
  req.open("POST", "/new_user", true);
  body = addToPost(body, new_username);
  body = addToPost(body, new_passwd);
  req.send(body);

Un atacante podría configurar un sitio web malicioso que contuviese el siguiente código.

  var req = new XMLHttpRequest();
  req.open("POST", "http://www.example.com/new_user", true);
  body = addToPost(body, "attacker");
  body = addToPost(body, "haha");
  req.send(body);

Si un administrador de example.com visita la página malintencionada mientras tiene una sesión activa en el sitio, creará sin quererlo una cuenta para el usuario malintencionado. Esto es lo que se denomina un ataque CSRF. Este ataque es posible porque la aplicación no tiene forma de determinar la procedencia de la solicitud. Todas las solicitudes podrían ser acciones válidas elegidas por el usuario o acciones engañosas llevadas a cabo por un atacante. El atacante no ve la página web que la solicitud falsa genera, por lo que esta técnica de ataque solo es útil para las solicitudes que alteran el estado de la aplicación.

Las aplicaciones que pasan el identificador de sesión en la URL en lugar de hacerlo en una cookie no tienen problemas de CSRF, ya que no hay forma de que el usuario malintencionado acceda al identificador de sesión y lo incluya como parte de la solicitud falsa.
CSRF es la entrada situada en la posición cinco de la lista de las diez vulnerabilidades principales de OWASP 2007.

Una vulnerabilidad de falsificación de solicitud entre sitios (CSRF) ocurre cuando:
1. Una aplicación web utiliza cookies de la sesión.

2. La aplicación actúa con una solicitud de HTTP sin verificar si la solicitud se realizó con el consentimiento del usuario.

Un nonce es un valor criptográfico aleatorio que se envía con un mensaje para prevenir ataques de reproducción. Si la solicitud no contiene un nonce que demuestre su procedencia, el código que administra la solicitud será vulnerable a un ataque de CSRF (a menos que no modifique el estado de la aplicación). Esto implica que una aplicación web que utilice cookies de sesión debe tomar precauciones especiales para garantizar que un atacante no pueda engañar a los usuarios para que envíen solicitudes falsas. Imagine una aplicación web que permite a los administradores crear cuentas nuevas enviando este formulario:

<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>

Un atacante podría establecer un sitio web con lo siguiente:

<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>

Si un administrador de example.com visita la página malintencionada mientras tiene una sesión activa en el sitio, creará sin quererlo una cuenta para el usuario malintencionado. Esto es lo que se denomina un ataque CSRF. Este ataque es posible porque la aplicación no tiene forma de determinar la procedencia de la solicitud. Todas las solicitudes podrían ser acciones válidas elegidas por el usuario o acciones engañosas llevadas a cabo por un atacante. El atacante no ve la página web que la solicitud falsa genera, por lo que esta técnica de ataque solo es útil para las solicitudes que alteran el estado de la aplicación.

Las aplicaciones que pasan el identificador de sesión en la URL en lugar de hacerlo en una cookie no tienen problemas de CSRF, ya que no hay forma de que el usuario malintencionado acceda al identificador de sesión y lo incluya como parte de la solicitud falsa.

Una vulnerabilidad de falsificación de solicitud entre sitios (CSRF) ocurre cuando:
1. Una aplicación web utiliza cookies de la sesión.

2. La aplicación actúa con una solicitud de HTTP sin verificar si la solicitud se realizó con el consentimiento del usuario.



Un nonce es un valor criptográfico aleatorio que se envía con un mensaje para prevenir ataques de reproducción. Si la solicitud no contiene un nonce que demuestre su procedencia, el código que administra la solicitud será vulnerable a un ataque de CSRF (a menos que no modifique el estado de la aplicación). Esto implica que una aplicación web que utilice cookies de sesión debe tomar precauciones especiales para garantizar que un atacante no pueda engañar a los usuarios para que envíen solicitudes falsas. Imagine una aplicación web que permite a los administradores crear cuentas nuevas enviando este formulario:

<form method="POST" action="/new_user" >
  Name of new user: <input type="text" name="username">
  Password for new user: <input type="password" name="user_passwd">
    <input type="submit" name="action" value="Create User">
</form>

Un atacante podría establecer un sitio web con lo siguiente:

<form method="POST" action="http://www.example.com/new_user">
  <input type="hidden" name="username" value="hacker">
  <input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
  document.usr_form.submit();
</script>

Si un administrador de example.com visita la página malintencionada mientras tiene una sesión activa en el sitio, creará sin quererlo una cuenta para el usuario malintencionado. Esto es lo que se denomina un ataque CSRF. Este ataque es posible porque la aplicación no tiene forma de determinar la procedencia de la solicitud. Todas las solicitudes podrían ser acciones válidas elegidas por el usuario o acciones engañosas llevadas a cabo por un atacante. El atacante no ve la página web que la solicitud falsa genera, por lo que esta técnica de ataque solo es útil para las solicitudes que alteran el estado de la aplicación.

Las aplicaciones que pasan el identificador de sesión en la URL en lugar de hacerlo en una cookie no tienen problemas de CSRF, ya que no hay forma de que el usuario malintencionado acceda al identificador de sesión y lo incluya como parte de la solicitud falsa.

CSRF es la entrada situada en la posición cinco de la lista de las diez vulnerabilidades principales de OWASP 2007.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.