界: Input Validation and Representation

输入验证与表示问题是由元字符、交替编码和数字表示引起的。安全问题源于信任输入。这些问题包括：“Buffer Overflows”、“Cross-Site Scripting”攻击、“SQL Injection”等其他问题。

Header Manipulation: SMTP

Abstract

在 SMTP 标头中包含未经验证的数据使得攻击者可以添加任意标头（如 CC 或 BCC），从而利用这些标头向其本身泄露邮件内容或将邮件服务器用作垃圾邮件自动程序。

Explanation

SMTP Header Manipulation 漏洞会在以下情况下发生：

1.数据通过不可信数据源进入应用程序，最常见的是 Web 应用程序中的 HTTP 请求。

2.数据包含在未经验证就发送给邮件服务器的 SMTP 标头中。

如同许多软件安全漏洞一样，SMTP Header Manipulation 只是通向终端的一个途径，它本身并不是终端。从本质上看，该漏洞是显而易见的：攻击者可将恶意数据传送到易受攻击的应用程序，然后该应用程序将这些数据包含在 SMTP 标头中。

一种最常见的 SMTP Header Manipulation 攻击是分发垃圾邮件。如果应用程序包含一个易受攻击的“联系我们”表单，该表单允许设置电子邮件的主题和正文，攻击者就能够设置任意内容，并将包含电子邮件地址列表的 CC 标头匿名注入垃圾邮件，因为电子邮件是从受害者服务器发送的。

示例：以下代码段将读取“联系我们”表单的主题和正文：


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

假设在请求中提交了一个由标准字母和数字字符组成的字符串，如“Page not working”，那么 SMTP 头可能表现为以下形式：


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

然而，因为标头值是使用未经验证的用户输入构造的，所以仅当提交给 subject 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交恶意字符串，例如“Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...”，则 SMTP 标头将采用以下形式：


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

这使得攻击者可以在其他攻击中制作垃圾邮件或发送匿名电子邮件。

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

在 SMTP 头中包括未经验证的数据使得攻击者可以添加任意标题（如 CC 或 BCC），从而利用这些标题向其本身泄露邮件内容或将邮件服务器用作垃圾邮件自动程序。

Explanation

在以下情况下会发生 SMTP Header Manipulation 漏洞：

1. 数据通过一个不可信赖的数据源进入应用程序，最常见的是 Web 应用程序中的 HTTP 请求。

2. 数据包含在一个 SMTP 头中，该 SMTP 头未经验证就发送给了邮件服务器。

如同许多软件安全漏洞一样，SMTP Header Manipulation 只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传送到易受攻击的应用程序，且该应用程序将这些数据包含在 SMTP 头中。

一种最常见的 SMTP Header Manipulation 攻击是分发垃圾邮件。如果应用程序包含一个易受攻击的“联系我们”表单，该表单允许设置电子邮件的主题和正文，攻击者就能够设置任意内容，并将包含电子邮件地址列表的 CC 标题匿名注入垃圾邮件，因为电子邮件会从受害者服务器进行发送。

示例：以下代码段读取“联系我们”表单的主题和正文：


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

假设在请求中提交了一个由标准字母和数字字符组成的字符串，如“Page not working”，那么 SMTP 头可能表现为以下形式：


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

然而，因为该头的值是利用未经验证的用户输入构造的，所以仅当提交给 subject 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。如果攻击者提交恶意字符串，例如“Congratulations!!You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...”，则 SMTP 头将表现为以下形式：


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

这将有效地允许攻击者制造垃圾邮件，或者发送匿名电子邮件等攻击。

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 漏洞：

1. 数据通过一个不可信赖的数据源进入应用程序，最常见的是 Web 应用程序中的 HTTP 请求。

2. 数据包含在一个 SMTP 头中，该 SMTP 头未经验证就发送给了邮件服务器。

如同许多软件安全漏洞一样，SMTP Header Manipulation 只是通向终端的一个途径，它本身并不是终端。从本质上看，这些漏洞是显而易见的：攻击者可将恶意数据传送到易受攻击的应用程序，且该应用程序将这些数据包含在 SMTP 头中。

一种最常见的 SMTP Header Manipulation 攻击用于分发垃圾邮件。如果应用程序包含一个允许设置电子邮件主题和正文的易受攻击的“联系我们”表单，攻击者将能够设置任意内容，并注入包含匿名（因为电子邮件是从受害者服务器发送的）指向垃圾邮件的电子邮件地址列表的 CC 标题。

示例：以下代码段读取“联系我们”表单的主题和正文：


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

假设在请求中提交了一个由标准字母和数字字符组成的字符串，如“Page not working”，那么 SMTP 头可能表现为以下形式：


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


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