Kingdom: Input Validation and Representation

Input validation and representation problems ares caused by metacharacters, alternate encodings and numeric representations. Security problems result from trusting input. The issues include: "Buffer Overflows," "Cross-Site Scripting" attacks, "SQL Injection," and many others.

Header Manipulation: SMTP

Abstract

Including unvalidated data in an SMTP header can enable attackers to add arbitrary headers, such as CC or BCC that they can use to leak the mail contents to themselves or use the mail server as a spam bot.

Explanation

SMTP Header Manipulation vulnerabilities occur when:

1. Data enters an application through an untrusted source, most frequently an HTTP request in a web application.

2. The data is included in an SMTP header sent to a mail server without validation.

As with many software security vulnerabilities, SMTP Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an SMTP header.

One of the most common SMTP Header Manipulation attacks is to distribute spam emails. If an application contains a vulnerable "Contact us" form that allows setting the subject and the body of the email, an attacker can set any arbitrary content and inject a CC header with a list of email addresses to spam anonymously because the email is sent from the victim's server.

Example: The following code segment reads the subject and body of a "Contact us" form:


    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)
        }
    }

Assuming a string consisting of standard alphanumeric characters, such as "Page not working" is submitted in the request, the SMTP headers might take the following form:


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

However, because the value of the header is constructed from unvalidated user input the response only maintains this form if the value submitted for subject does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", then the SMTP headers would be of the following form:


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

This effectively enables an attacker to craft spam messages or to send anonymous emails amongst other attacks.

References

[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0

[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial

[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1

[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1

[5] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial

[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity

[7] Standards Mapping - CIS Kubernetes Benchmark complete

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

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

[10] Standards Mapping - FIPS200 SI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation

[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

desc.dataflow.golang.header_manipulation_smtp

Abstract

Explanation

SMTP Header Manipulation vulnerabilities occur when:

1. Data enters an application through an untrusted source, most frequently an HTTP request in a web application.

2. The data is included in an SMTP header sent to a mail server without being validated.

As with many software security vulnerabilities, SMTP Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an SMTP header.

One of the most common SMTP Header Manipulation attacks is used for distributing spam emails. If an application contains a vulnerable "Contact us" form that allows setting the subject and the body of the email, an attacker will be able to set any arbitrary content and inject a CC header with a list of email addresses to spam anonymously since the email will be sent from the victim server.

Example: The following code segment reads the subject and body of a "Contact us" form:


  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);

Assuming a string consisting of standard alphanumeric characters, such as "Page not working" is submitted in the request, the SMTP headers might take the following form:


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

However, because the value of the header is constructed from unvalidated user input the response will only maintain this form if the value submitted for subject does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", then the SMTP headers would be of the following form:


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

This will effectively allow an attacker to craft spam messages or to send anonymous emails amongst other attacks.

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 - CIS Azure Kubernetes Service Benchmark 2.0

[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial

[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1

[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1

[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial

[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity

[9] Standards Mapping - CIS Kubernetes Benchmark complete

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

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

[12] Standards Mapping - FIPS200 SI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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.1 Requirement 6.5.1

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

[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.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 Abuse of Functionality (WASC-42)

desc.dataflow.java.header_manipulation_smtp

Abstract

Explanation

SMTP Header Manipulation vulnerabilities occur when:

1. Data enters an application through an untrusted source, most frequently an HTTP request in a web application.

2. The data is included in an SMTP header sent to a mail server without being validated.

As with many software security vulnerabilities, SMTP Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an SMTP header.

One of the most common SMTP Header Manipulation attacks is for the use of distributing spam emails. If an application contains a vulnerable "Contact us" form that allows setting the subject and the body of the email, an attacker will be able to set any arbitrary content and inject a CC header with a list of email addresses to spam anonymously since the email will be sent from the victim server.

Example: The following code segment reads the subject and body of a "Contact us" form:


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

Assuming a string consisting of standard alphanumeric characters, such as "Page not working" is submitted in the request, the SMTP headers might take the following form:


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


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