界: Input Validation and Representation

入力の検証や表現の問題は、メタキャラクター、代替エンコーディング、数値表現などによって引き起こされます。セキュリティの問題は、入力を信頼することに起因します。この問題に含まれるのは、「Buffer Overflow」、「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 攻撃の最もよくある手段の 1 つは、スパム電子メールの配布です。アプリケーションに脆弱な [Contact us] (お問い合わせ) フォームが含まれていて、メールの件名と本文を設定できる場合、攻撃者は任意の内容を設定し、メールアドレスのリストを使用して CC ヘッダーを挿入し、匿名で (電子メールは攻撃を受けたサーバーから送信されるため) スパムを送信できます。

例 1: 次のコードセグメントは、[Contact us] (お問い合わせ) フォームの件名と本文を読み取ります。


    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 Data Security Standard Version 4.0.1 Requirement 6.2.4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 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 5.1 APSC-DV-002560 CAT I

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

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

[49] Standards Mapping - Security Technical Implementation Guide Version 6.1 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.golang.header_manipulation_smtp

Abstract

未検証のデータを SMTP ヘッダーに追加すると、攻撃者は CC や BCC など任意のヘッダーを追加して電子メールの内容を盗み見たり、メールサーバーをスパムボットとして使用したりできます。

Explanation

SMTP Header Manipulation (SMTP ヘッダー操作) の脆弱性が発生するのは次の場合です。

1.信頼されていないソース (多くは Web アプリケーションの HTTP リクエスト) からデータがアプリケーションに入り込んだ場合。

2.メールサーバーに送信される SMTP ヘッダーにデータが検証せずに追加された場合。

多くのソフトウェアセキュリティの脆弱性と同様、SMTP Header Manipulation (SMTP ヘッダー操作) は目的を達成するための手段であって、目的そのものではありません。基本的には、この脆弱性は単純なものです。攻撃者は脆弱なアプリケーションに悪意のあるデータを渡し、アプリケーションがそのデータを SMTP ヘッダーに追加します。

SMTP Header Manipulation (SMTP ヘッダー操作) 攻撃の最もよくある利用法の 1 つは、スパム電子メールの配布です。アプリケーションに脆弱な [Contact us] (お問い合わせ) フォームが含まれていて、メールの件名と本文を設定できる場合、攻撃者は任意の内容を設定し、メールアドレスのリストを使用して CC ヘッダーを挿入し、匿名で (電子メールは攻撃を受けたサーバーから送信されるため) スパムを送信できます。

例 1: 次のコードセグメントは、[Contact us] (お問い合わせ) フォームの件名と本文を読み取ります。


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


  ...
  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 Data Security Standard Version 4.0.1 Requirement 6.2.4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[52] 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 (SMTP ヘッダー操作) の脆弱性が発生するのは次の場合です。

1.信頼されていないソース (多くは Web アプリケーションの HTTP リクエスト) からデータがアプリケーションに入り込んだ場合。

2.メールサーバーに送信される SMTP ヘッダーにデータが検証せずに追加された場合。

多くのソフトウェアセキュリティの脆弱性と同様、SMTP Header Manipulation (SMTP ヘッダー操作) は目的を達成するための手段であって、目的そのものではありません。基本的には、この脆弱性は単純なものです。攻撃者は脆弱なアプリケーションに悪意のあるデータを渡し、アプリケーションがそのデータを SMTP ヘッダーに追加します。

SMTP Header Manipulation 攻撃の最もよくある利用法の 1 つは、スパム電子メールの配布です。アプリケーションに脆弱な [Contact us] (お問い合わせ) フォームが含まれていて、メールの件名と本文を設定できる場合、攻撃者は任意の内容を設定し、メールアドレスのリストを使用して CC ヘッダーを挿入し、匿名で (電子メールは攻撃を受けたサーバーから送信されるため) スパムを送信できます。

例 1: 次のコードセグメントは、[Contact us] (お問い合わせ) フォームの件名と本文を読み取ります。


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


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


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