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.

Header Manipulation: SMTP

Abstract

Incluir datos no validados en un encabezado SMTP puede permitir que los atacantes agreguen encabezados arbitrarios, como CC o BCC, que pueden usar para filtrar el contenido del correo hacia ellos mismos o para utilizar el servidor de correo como un bot de spam.

Explanation

Se producen vulnerabilidades de SMTP Header Manipulation cuando:

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

2. Los datos se incluyen en un encabezado SMTP enviado a un servidor de correo sin haber sido validados.

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

Uno de los ataques más comunes de SMTP Header Manipulation se utiliza para distribuir mensajes de correo electrónico no deseado. Si una aplicación contiene un formulario de contacto vulnerable que permite definir el asunto y el cuerpo del mensaje de correo electrónico, un usuario malintencionado puede definir cualquier contenido arbitrario e inyectar un encabezado CC con una lista de direcciones a las que enviar correo no deseado de forma anónima, ya que el correo electrónico se enviará desde el servidor de la víctima.

Ejemplo: El siguiente segmento de código lee el asunto y el cuerpo de un formulario de contacto:


    func handler(w http.ResponseWriter, r *http.Request) {
        subject := r.FormValue("subject")
        body := r.FormValue("body")
        auth := smtp.PlainAuth("identity", "user@example.com", "password", "mail.example.com")
        to := []string{"recipient@example.net"}
        msg := []byte("To: " + recipient1 + "\r\n" + subject + "\r\n" + body + "\r\n")
        err := smtp.SendMail("mail.example.com:25", auth, "sender@example.org", to, msg)
        if err != nil {
            log.Fatal(err)
        }
    }

Si una cadena compuesta por caracteres alfanuméricos estándar, como “La página no funciona”, se envía en la solicitud, los encabezados SMTP podrían mostrarse de la siguiente forma:


  ...
  subject: [Contact us query] Page not working
  ...

Sin embargo, como el valor del encabezado se construye a partir de la entrada de usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para subject no contiene ningún carácter CR ni LF. Si un atacante envía una cadena maliciosa, como "¡¡Felicitaciones!! ¡¡Ha ganado la lotería!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", los encabezados SMTP tendrían el siguiente formato:


  ...
  subject: [Contact us query] Congratulations!! You won the lottery
  cc: victim1@mail.com,victim2@mail.com
  ...

Esto permite que un atacante genere mensajes de spam o envíe correos electrónicos anónimos, entre otros ataques.

References

[1] Standards Mapping - Common Weakness Enumeration CWE ID 93

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

[3] Standards Mapping - FIPS200 SI

[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation

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

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

[7] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls

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

[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1

[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input

[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws

[12] Standards Mapping - OWASP Top 10 2010 A1 Injection

[13] Standards Mapping - OWASP Top 10 2013 A1 Injection

[14] Standards Mapping - OWASP Top 10 2017 A1 Injection

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

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1

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

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1

[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1

[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1

[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1

[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1

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

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

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

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

[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I

[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I

[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I

[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I

[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I

[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I

[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[48] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)

desc.dataflow.golang.header_manipulation_smtp

Abstract

La inclusión de datos sin validar en un encabezado SMTP puede permitir a los usuarios malintencionados agregar encabezados arbitrarios, como CC o BCC, que pueden utilizar para acceder al contenido del correo o utilizar el servidor de correo como un bot de correo no deseado.

Explanation

Las vulnerabilidades de manipulación de encabezado SMTP se producen cuando:

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

2. Los datos se incluyen en un encabezado HTTP que se envía a un servidor de correo sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado SMTP 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 SMTP.

Uno de los ataques más comunes de manipulación de encabezado SMTP se utiliza para distribuir mensajes de correo electrónico no deseado. Si una aplicación contiene un formulario de contacto vulnerable que permite definir el asunto y el cuerpo del mensaje de correo electrónico, un usuario malintencionado podrá definir cualquier contenido arbitrario e inyectar un encabezado CC con una lista de direcciones a las que enviar correo no deseado de forma anónima, ya que el correo electrónico se enviará desde el servidor de la víctima.

Ejemplo: el siguiente fragmento de código lee el asunto y el cuerpo de un formulario de contacto:


  String subject = request.getParameter("subject");
  String body = request.getParameter("body");
  MimeMessage message = new MimeMessage(session);
  message.setFrom(new InternetAddress("webform@acme.com"));
  message.setRecipients(Message.RecipientType.TO, InternetAddress.parse("support@acme.com"));
  message.setSubject("[Contact us query] " + subject);
  message.setText(body);
  Transport.send(message);

Si una cadena compuesta por caracteres alfanuméricos estándar, como “La página no funciona”, se envía en la solicitud, los encabezados SMTP podrían mostrarse de la siguiente forma:


  ...
  subject: [Contact us query] Page not working
  ...

Sin embargo, dado que el valor del encabezado se crea a partir de la entrada de un usuario no validado, la respuesta solo mantendrá esta forma si el valor introducido para subject no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, como "¡Felicidades! ¡¡Ha ganado la lotería!!\r\ncc:victim1@mail.com,victim2@mail.com ...", entonces los encabezados SMTP tendrían la siguiente forma:


  ...
  subject: [Contact us query] Congratulations!! You won the lottery
  cc: victim1@mail.com,victim2@mail.com
  ...

En la práctica, esto permitirá a un usuario malintencionado elaborar mensajes de correo no deseado o enviar mensajes anónimos entre otros ataques.

References

[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)

[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers

[3] Standards Mapping - Common Weakness Enumeration CWE ID 93

[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754

[5] Standards Mapping - FIPS200 SI

[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation

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

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

[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls

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

[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1

[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input

[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws

[14] Standards Mapping - OWASP Top 10 2010 A1 Injection

[15] Standards Mapping - OWASP Top 10 2013 A1 Injection

[16] Standards Mapping - OWASP Top 10 2017 A1 Injection

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

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1

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

[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1

[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1

[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1

[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1

[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1

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

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

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

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

[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I

[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I

[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I

[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I

[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I

[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I

[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[50] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)

desc.dataflow.java.header_manipulation_smtp

Abstract

Explanation

Las vulnerabilidades de manipulación de encabezado SMTP se producen cuando:

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

2. Los datos se incluyen en un encabezado HTTP que se envía a un servidor de correo sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado SMTP 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 SMTP.

Uno de los ataques más comunes de manipulación de encabezado SMTP se utiliza para distribuir mensajes de correo electrónico no deseado. Si una aplicación contiene un formario de contacto vulnerable que permite definir el asunto y el cuerpo del mensaje de correo electrónico, un usuario malintencionado podrá definir cualquier contenido arbitrario e inyectar un encabezado CC con una lista de direcciones a las que enviar correo no deseado de forma anónima, ya que el correo electrónico se enviará desde el servidor de la víctima.

Ejemplo: el siguiente fragmento de código lee el asunto y el cuerpo de un formulario de contacto:


$subject = $_GET['subject'];
$body =  $_GET['body'];
mail("support@acme.com", "[Contact us query] " . $subject, $body);

Si una cadena compuesta por caracteres alfanuméricos estándar, como “La página no funciona”, se envía en la solicitud, los encabezados SMTP podrían mostrarse de la siguiente forma:


...
subject: [Contact us query] Page not working
...


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...