界: 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 - 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

將未驗證的資料包含在 SMTP 表頭中，會讓攻擊者新增如 CC 或 BCC 任意表頭，攻擊者可使用這些表頭將郵件內容洩漏給他們自己，或將郵件伺服器用作垃圾郵件機器人。

Explanation

SMTP Header Manipulation 弱點會在以下情況中出現：

1. 資料透過不可信賴的來源進入應用程式，通常是 Web 應用程式中的 HTTP 要求。

2. 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 - 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

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 弱點會在以下情況中出現：

1. 資料透過不可信賴的來源進入應用程式，通常是 Web 應用程式中的 HTTP 要求。

2. 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
...