Reino: Input Validation and Representation

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

175 elementos encontrados
Debilidades
Abstract
Aceptar los datos proporcionados por el usuario como URL de origen apex:iframe puede provocar que se cargue contenido malintencionado en la página de Visualforce.
Explanation
Las vulnerabilidades de la suplantación de marcos se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable.

2. Los datos se utilizan como una URL de iframe sin que se validen.

De esta forma, un atacante podrá controlar lo que se representa en el marco de la línea. Al modificar la dirección URL del marco para apuntar a un sitio malicioso, se pueden realizar ataques de suplantación de identidad para intentar robar información del usuario, incluidas las credenciales u otros datos confidenciales. Dado que el dominio básico es de confianza, Salesforce.com, la víctima confiará en la página y proporcionará toda la información solicitada.

Ejemplo 1: en el siguiente ejemplo de código, el parámetro URL de iframesrc se utiliza directamente como la dirección URL de apex:iframe de destino.

<apex:page>
<apex:iframe src="{!$CurrentPage.parameters.iframesrc}"></apex:iframe>
</apex:page>


De esta forma, si un atacante proporciona a una víctima el parámetro iframesrc establecido en un sitio web malintencionado, el marco se representará con el contenido del sitio web malintencionado.

<iframe src="http://evildomain.com/">
References
[1] Ryan C. Barnett Content Spoofing - TechTarget
[2] Salesforce Developers Technical Library Secure Coding Guidelines
desc.dataflow.apex.frame_spoofing
Abstract
Se crea un objeto Google Remote Procedure Call (gRPC) Metadata a partir de un objeto que no proviene de una fuente de confianza, lo que podría permitir a un atacante controlar campos de protocolo críticos.
Explanation
La clase Metadata se usa a menudo para albergar datos de cabeceras para un protocolo subyacente que usa Google Remote Procedure Call (gRPC). Cuando el protocolo subyacente es HTTP, el control de los datos en un objeto Metadata puede hacer que el sistema sea vulnerable a la manipulación de cabeceras HTTP. Son posibles otros vectores de ataque y se basan principalmente en el protocolo subyacente.

Ejemplo 1: El siguiente código muestra los datos controlables por el usuario que se usan como entrada para un objeto gRPC Metadata.


...
String badData = getUserInput();
Metadata headers = new Metadata();
headers.put(Metadata.Key.of("sample", Metadata.ASCII_STRING_MARSHALLER), badData);
...
desc.dataflow.java.grpc_metadata_manipulation
Abstract
El programa permite a un usuario malintencionado controlar los componentes centrales del clúster de Hadoop en los que se ejecuta la aplicación cliente.
Explanation
Los errores de control del clúster de Hadoop se producen cuando:

- Los datos entran en un programa desde un origen que no es de confianza.

- Los componentes centrales del clúster de Hadoop como, por ejemplo, NameNode, DataNode o JobTraker consumen los datos para cambiar el estado del clúster.

Los clústeres de Hadoop son un entorno hostil. Si no se establecen correctamente las configuraciones de seguridad que protegen frente al acceso no autorizado a los nodos del clúster, es posible que se produzca un ataque. Esto conlleva la posibilidad de que se manipule cualquier dato proporcionado por el clúster de Hadoop.

Ejemplo 1: el siguiente código muestra un envío de Job en una aplicación de cliente típica que obtiene entradas de la línea de comandos en un equipo maestro de clúster de Hadoop:


public static void run(String args[]) throws IOException {

String path = "/path/to/a/file";
DFSclient client = new DFSClient(arg[1], new Configuration());
ClientProtocol nNode = client.getNameNode();

/* This sets the ownership of a file pointed by the path to a user identified
* by command line arguments.
*/
nNode.setOwner(path, args[2], args[3]);
...
}
desc.dataflow.java.hadoop_cluster_manipulation
Abstract
El elemento Job enviado a un clúster de Hadoop se puede manipular en un entorno hostil.
Explanation
Los errores de manipulación de tareas de Hadoop se producen cuando:

- Los datos entran en un programa desde un origen que no es de confianza.

- Los datos se utilizan para especificar un valor deJobConf que controla la tarea de un cliente.

Los clústeres de Hadoop son un entorno hostil. Si no se establecen correctamente las configuraciones de seguridad que protegen frente al acceso no autorizado a HDFS en equipos de clúster, es posible que se produzca un ataque. Esto conlleva la posibilidad de que se manipule cualquier dato proporcionado por el clúster de Hadoop.

Ejemplo 1: el siguiente código muestra un envío de Job en una aplicación de cliente típica que obtiene entradas de la línea de comandos en un equipo maestro de clúster de Hadoop:


public void run(String args[]) throws IOException {

String inputDir = args[0];
String outputDir = args[1];

// Untrusted command line argument
int numOfReducers = Integer.parseInt(args[3]);
Class mapper = getClassByName(args[4]);
Class reducer = getClassByName(args[5]);

Configuration defaults = new Configuration();
JobConf job = new JobConf(defaults, OptimizedDataJoinJob.class);
job.setNumMapTasks(1);
// An attacker may set random values that exceed the range of acceptable number of reducers
job.setNumReduceTasks(numOfReducers);

return job;
}
Ejemplo 2: el siguiente código muestra un caso en el que un usuario malintencionado controla la tarea en ejecución que se va a anular a través de los argumentos de la línea de comandos:


public static void main(String[] args) throws Exception {

JobID id = JobID.forName(args[0]);
JobConf conf = new JobConf(WordCount.class);
// configure this JobConf instance
...
JobClient.runJob(conf);
RunningJob job = JobClient.getJob(id);
job.killJob();

}
desc.dataflow.java.hadoop_job_manipulation
Abstract
El escape está deshabilitado en las plantillas de Handlebars, lo que puede generar múltiples vulnerabilidades nuevas.
Explanation
El escape predeterminado realizado en las plantillas de Handlebars ayuda a proteger la aplicación de posibles ataques. Esto puede prevenir muchos vectores de ataque a través de diferentes tipos de vulnerabilidades. La protección más destacada es contra ciertos tipos de ataques de secuencias de comandos en sitios cruzados. En esta aplicación, este mecanismo de protección está específicamente desactivado.

Ejemplo 1: El siguiente ejemplo muestra el escape de la plantilla de Handlebars deshabilitado.

let template = Handlebars.compile('{{foo}}', { noEscape: true })
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark complete
[6] Standards Mapping - Common Weakness Enumeration CWE ID 554
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[13] Standards Mapping - FIPS200 CM
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[18] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[24] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.javascript.handlebars_misconfiguration_escaping_disabled
Abstract
Se permiten prototipos en las plantillas de Handlebars, lo que abre la puerta a vulnerabilidades de contaminación de prototipos.
Explanation
Las plantillas de Handlebars no pueden acceder a los prototipos de un objeto, ya que hace que la aplicación sea susceptible a los ataques Prototype Pollution.

Los ataques de contaminación de prototipos ocurren cuando un usuario malintencionado puede controlar funciones o propiedades en los prototipos de objetos. El control de los prototipos de un objeto que se pasa a una plantilla permite muchas vulnerabilidades, incluida la evaluación dinámica de código, las secuencias de comandos en sitios cruzados y la ejecución remota del código.

Ejemplo 1: En el siguiente ejemplo de configuración de plantillas de Handlebars, los métodos prototipo están permitidos de forma predeterminada, así como la función especial __defineGetter__.

let template2 = Handlebars.compile('{{foo}}')
console.log(template2({ foo: argument }, {
allowProtoMethodsByDefault: true,
allowedProtoMethods: {
__defineGetter__: true
}
}))
References
[1] Handlebars Runtime Options: Options to Control Prototype Access Handlebars
[2] Mahmoud Gamal Handlebars template injection and RCE in a Shopify app
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 554
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[15] Standards Mapping - FIPS200 CM
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[19] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[20] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[26] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.structural.javascript.handlebars_misconfiguration_prototypes_allowed
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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 tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.abap.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, cross-site scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies u open redirect.
Explanation
Se producen vulnerabilidades Header Manipulation cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable, de forma más frecuente en una solicitud HTTP.


2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, Header Manipulation es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de Header Manipulation es la división de respuesta HTTP. Para realizar un ataque de división de respuesta HTTP con éxito, la aplicación debe permitir entradas que contengan caracteres CR (retorno de carro, también expresado como %0d o \r) y LF (avance, también expresado como %0a o \n) en el encabezado. Estos caracteres no solo proporcionan a los atacantes el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación pretende enviar, sino que también les permiten crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernos de hoy impiden la inyección de caracteres malintencionados en los encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojan una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a HTTP Response Splitting. Sin embargo, si solo se filtran los caracteres de nueva línea, la aplicación puede quedar expuesta a ataques de Cookie Manipulation u Open Redirect, por lo que hay que tener cuidado al establecer encabezados HTTP con entrada del usuario.

Ejemplo 1: El siguiente código establece un encabezado HTTP cuyo nombre y valor podría controlar un atacante:


@HttpGet
global static void doGet() {
...
Map<String, String> params = ApexPages.currentPage().getParameters();

RestResponse res = RestContext.response;
res.addHeader(params.get('name'), params.get('value'));
...
}


Suponiendo que un par de nombre/valor consta de author y Jane Smith, la respuesta HTTP que incluye este encabezado podría tener la siguiente forma:


HTTP/1.1 200 OK
...
author:Jane Smith
...


Sin embargo, debido a que el valor del encabezado se forma a partir de una entrada de usuario no validada, un atacante podría enviar un par de nombre/valor malicioso, como HTTP/1.1 200 OK\r\n...foo y bar, por lo que la respuesta HTTP se dividiría en dos respuestas de la siguiente forma:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


Claramente, el atacante controla la segunda respuesta, y esta se puede crear con cualquier contenido de cuerpo y encabezado deseado. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y de la Web, Cross-Site Scripting y el secuestro de páginas.

Desfiguración de usuarios de sitios: Un atacante puede realizar una única solicitud en un servidor vulnerable que haga que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparte la misma conexión TCP con el servidor. Esto se puede lograr si se convence al usuario de que envíe la solicitud malintencionada por sí mismo o de forma remota en situaciones donde el atacante y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque y hacer que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un atacante puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación, pero que redirija información privada, como los números de cuenta y las contraseñas, al atacante.

Envenenamiento de caché: El impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilizan varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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 tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas (la respuesta prevista del servidor y la respuesta generada por el atacante), un atacante puede hacer que un nodo intermedio, como un servidor proxy compartido, desvíe al atacante una respuesta generada por el servidor destinada al usuario. Como la solicitud realizada por el atacante genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del atacante, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del atacante ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El atacante envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar toda la información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como Cross-Site Request Forgery, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Open Redirect: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede ayudar a los ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.apex.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchas de las estructuras y los servidores de aplicaciones actuales impiden la introducción de código malintencionado en los encabezados HTTP. Por ejemplo, las versiones recientes de .NET Framework de Microsoft convertirán los caracteres CR, LF y NULL a %0d, %0a y %00 cuando se envíen al método HttpResponse.AddHeader(). Si utiliza la versión más reciente de .NET que impide establecer encabezados con nuevos caracteres de línea, es posible que la aplicación no sea vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para Author.Text no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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 tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.dotnet.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede provocar ataques como el envenenamiento de caché, los Cross-Site Scripting (XSS), la degradación de usuarios o el secuestro de páginas.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin que se hayan validado para comprobar que existe código malintencionado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el siguiente segmento de código lee el nombre del autor de una entrada de blog, author, de un formulario HTML y lo establece en un encabezado de cookies de una respuesta HTTP.


...
EXEC CICS
WEB READ
FORMFIELD(NAME)
VALUE(AUTHOR)
...
END-EXEC.

EXEC CICS
WEB WRITE
HTTPHEADER(COOKIE)
VALUE(AUTHOR)
...
END-EXEC.
...


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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 tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.cobol.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos tienen acceso a una aplicación web a través de una fuente que no es de confianza; la mayoría de las veces mediante una solicitud web.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el siguiente segmento de código lee el nombre del autor de una entrada de blog, author, desde un formulario web y lo establece como encabezado de cookie de una respuesta HTTP.


<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1/1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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 tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] Amit Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Diabolic Crab HTTP Response Splitting
desc.dataflow.cfml.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o ataques de redireccionamiento abierto.
Explanation
Se producen vulnerabilidades Header Manipulation cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin validación.

Al igual que con muchas vulnerabilidades de seguridad de software, Header Manipulation es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de Header Manipulation es la división de respuesta HTTP. Para realizar un ataque de división de respuesta HTTP con éxito, la aplicación debe permitir entradas que contengan caracteres CR (retorno de carro, también expresado como %0d o \r) y LF (avance, también expresado como %0a o \n) en el encabezado. Estos caracteres no solo proporcionan a los atacantes el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación pretende enviar, sino que también les permiten crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernos impiden la inyección de caracteres malintencionados en los encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a HTTP Response Splitting. Sin embargo, si solo se filtran los caracteres de nueva línea, la aplicación puede quedar expuesta a ataques de Cookie Manipulation u Open Redirect, por lo que hay que tener cuidado al establecer encabezados HTTP con entrada del usuario.

Ejemplo: El siguiente segmento de código lee el 'tipo de contenido' de una solicitud HTTP y lo establece en un encabezado de una nueva solicitud HTTP.


final server = await HttpServer.bind('localhost', 18081);
server.listen((request) async {
final headers = request.headers;
final contentType = headers.value('content-type');
final client = HttpClient();
final clientRequest = await client.getUrl(Uri.parse('https://example.com'));
clientRequest.headers.add('Content-Type', contentType as Object);
});


Debido a que el valor del encabezado de tipo de contenido está formado por una entrada de usuario no validada, puede ser manipulado por personas malintencionadas para explotar vulnerabilidades, ejecutar ataques de inyección de código, exponer datos confidenciales, habilitar la ejecución de archivos maliciosos o desencadenar situaciones de denegación de servicio, lo que representa riesgos significativos para la seguridad y la estabilidad de la aplicación.
desc.dataflow.dart.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, cross-site scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies u open redirect.
Explanation
Se producen vulnerabilidades Header Manipulation cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, Header Manipulation es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.


Ejemplo: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...


La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y de la Web, Cross-Site Scripting y el secuestro de páginas.

Desfiguración de usuarios de sitios: Un atacante puede realizar una única solicitud en un servidor vulnerable que haga que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparte la misma conexión TCP con el servidor. Esto se puede lograr si se convence al usuario de que envíe la solicitud malintencionada por sí mismo o de forma remota en situaciones donde el atacante y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque y hacer que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un atacante puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación, pero que redirija información privada, como los números de cuenta y las contraseñas, al atacante.

Envenenamiento de caché: El impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilizan varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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 tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas (la respuesta prevista del servidor y la respuesta generada por el atacante), un atacante puede hacer que un nodo intermedio, como un servidor proxy compartido, desvíe al atacante una respuesta generada por el servidor destinada al usuario. Como la solicitud realizada por el atacante genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del atacante, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del atacante ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El atacante envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar toda la información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como la falsificación de solicitudes entre sitios, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Open Redirect: Si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede contribuir a los ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
desc.dataflow.golang.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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 tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.java.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: envenenamiento de caché de web y explorador, scripts de sitios y suplantación de páginas.


Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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 tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.javascript.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.


2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: en el siguiente segmento de código se asume que name y value pueden ser controlados por un usuario malintencionado. El código establece un encabezado HTTP cuyo nombre y valor son controlados por un usuario malintencionado:


...
NSURLSessionConfiguration * config = [[NSURLSessionConfiguration alloc] init];
NSMutableDictionary *dict = @{};
[dict setObject:value forKey:name];
[config setHTTPAdditionalHeaders:dict];
...


Si se asume un par de nombre/valor que consiste en author y Jane Smith, la respuesta de HTTP incluida en este encabezado podría tomar la siguiente forma:


HTTP/1.1 200 OK
...
author:Jane Smith
...


Sin embargo, debido a que el valor del encabezado se forma con entradas del usuario sin validar, los usuarios malintencionados pueden enviar un par de nombre/valor malintencionado, como HTTP/1.1 200 OK\r\n...foo y bar, y la respuesta de HTTP se dividiría en dos respuestas de la siguiente forma:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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 tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.objc.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de PHP generarán una advertencia y detendrán la creación de encabezados cuando las líneas nuevas se pasen a la función header() . Si su versión de PHP impide la configuración de los encabezados con los nuevos caracteres de línea, la aplicación no será vulnerable a la División de respuestas HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el siguiente segmento de código lee la ubicación desde una solicitud HTTP y establece en un encabezado el campo de ubicación de una respuesta HTTP.


<?php
$location = $_GET['some_location'];
...
header("location: $location");
?>


Si una cadena compuesta por caracteres alfanuméricos, como “index.html”, se envía en la solicitud, la respuesta HTTP que incluye esta cookie podría mostrarse de la siguiente forma:


HTTP/1.1 200 OK
...
location: index.html
...


Sin embargo, dado que el valor de la ubicación se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para some_location no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, como "index.html\r\nHTTP/1.1 200 OK\r\n...", la respuesta HTTP debería dividirse en dos respuestas de la siguiente forma:


HTTP/1.1 200 OK
...
location: index.html

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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 tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.php.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


...
-- Assume QUERY_STRING looks like AUTHOR_PARAM=Name
author := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 14);
OWA_UTIL.mime_header('text/html', false);
OWA_COOKE.send('author', author);
OWA_UTIL.http_header_close;
...


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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 tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.sql.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el siguiente segmento de código lee la ubicación desde una solicitud HTTP y establece en un encabezado el campo de ubicación de una respuesta HTTP.


location = req.field('some_location')
...
response.addHeader("location",location)


Si una cadena compuesta por caracteres alfanuméricos, como “index.html”, se envía en la solicitud, la respuesta HTTP que incluye esta cookie podría mostrarse de la siguiente forma:


HTTP/1.1 200 OK
...
location: index.html
...


Sin embargo, dado que el valor de la ubicación se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para some_location no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, como "index.html\r\nHTTP/1.1 200 OK\r\n...", la respuesta HTTP debería dividirse en dos respuestas de la siguiente forma:


HTTP/1.1 200 OK
...
location: index.html

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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 tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.python.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el siguiente segmento de código lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo utiliza en una solicitud GET para otra parte del sitio.


author = req.params[AUTHOR_PARAM]
http = Net::HTTP.new(URI("http://www.mysite.com"))
http.post('/index.php', "author=#{author}")


Suponiendo que se envía en la solicitud una cadena formada por caracteres alfanuméricos estándar, tales como “Julia Díaz”, la respuesta HTTP podría tener el formato siguiente:


POST /index.php HTTP/1.1
Host: www.mysite.com
author=Jane Smith
...


Sin embargo, dado que el valor de la dirección URL se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, como "Wiley Hacker\r\nPOST /index.php HTTP/1.1\r\n...", la respuesta HTTP se dividiría en dos respuestas de la siguiente forma:


POST /index.php HTTP/1.1
Host: www.mysite.com
author=Wiley Hacker

POST /index.php HTTP/1.1
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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 tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
desc.dataflow.ruby.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar Cache-Poisoning, Cross-Site Scripting, Cross-User Defacement, Page Hijacking, Cookie Manipulation u Open Redirect.
Explanation
Las vulnerabilidades de Header Manipulation se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, Header Manipulation es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de Header Manipulation es HTTP Response Splitting. Para realizar un ataque de HTTP Response Splitting con éxito, la aplicación debe permitir entradas que contengan los caracteres CR (retorno de carro, también expresado como %0d o \r) y LF (avance, también expresado como %0a o \n) en el encabezado. Estos caracteres no solo proporcionan a los atacantes el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permiten crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, Play Framework arrojará una excepción si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a HTTP Response Splitting. Sin embargo, si solo se filtran los caracteres de nueva línea, la aplicación puede quedar expuesta a ataques de Cookie Manipulation u Open Redirect, por lo que hay que tener cuidado al establecer encabezados HTTP con entrada del usuario.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.scala.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.


2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: en el siguiente segmento de código se asume que name y value pueden ser controlados por un usuario malintencionado. El código establece un encabezado HTTP cuyo nombre y valor son controlados por un usuario malintencionado:


...
var headers = []
headers[name] = value
let config = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier("com.acme")
config.HTTPAdditionalHeaders = headers
...


Si se asume un par de nombre/valor que consiste en author y Jane Smith, la respuesta de HTTP incluida en este encabezado podría tomar la siguiente forma:


HTTP/1.1 200 OK
...
author:Jane Smith
...


Sin embargo, debido a que el valor del encabezado se forma con entradas del usuario sin validar, los usuarios malintencionados pueden enviar un par de nombre/valor malintencionado, como HTTP/1.1 200 OK\r\n...foo y bar, y la respuesta de HTTP se dividiría en dos respuestas de la siguiente forma:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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 tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.swift.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP, sin embargo, los servidores que admiten aplicaciones ASP clásicas a menudo carecen de ese mecanismo de protección.

Ejemplo: el segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. 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 tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
desc.dataflow.vb.header_manipulation