Reino: Input Validation and Representation

Problemas de validação e representação da entrada são causados por metacaracteres, codificações alternativas e representações numéricas. Confiar na entrada resulta em problemas de segurança. Os problemas incluem: “Buffer Overflows”, ataques de “Cross-Site Scripting”, “SQL Injection”, entre outros.

Header Manipulation: SMTP

Abstract

Incluir dados não validados em um cabeçalho SMTP pode permitir que invasores adicionem cabeçalhos arbitrários, como CC ou BCC, que eles podem usar para vazar o conteúdo do e-mail para eles mesmos ou usar o servidor de correio como um bot de spam.

Explanation

As vulnerabilidades de SMTP Header Manipulation ocorrem quando:

1. Os dados entram em um aplicativo por meio de uma fonte não confiável, mais frequentemente, uma solicitação HTTP em um aplicativo Web.

2. Os dados são incluídos em um cabeçalho SMTP enviado a um servidor de correio sem validação.

Como acontece com muitas vulnerabilidades de segurança de software, SMTP Header Manipulation é um meio para um fim, não um fim por si só. Em sua raiz, a vulnerabilidade é direta: um invasor passa dados mal-intencionados para um aplicativo vulnerável e o aplicativo inclui os dados em um cabeçalho SMTP.

Um dos ataques de SMTP Header Manipulation mais comuns é distribuir e-mails de spam. Se um aplicativo contiver um formulário vulnerável "Fale conosco" que permite definir o assunto e o corpo do e-mail, um invasor poderá definir qualquer conteúdo arbitrário e injetar um cabeçalho CC com uma lista de endereços de e-mail para distribuição anônima como spam, já que o e-mail será enviado a partir do servidor da vítima.

Exemplo: O seguinte segmento de código lê o assunto e o corpo de um formulário "Fale conosco":


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

Supondo que uma string formada por caracteres alfanuméricos padrão, como "A página não funciona", seja enviada na solicitação, os cabeçalhos SMTP podem assumir o seguinte formato:


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

No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta só manterá esse formato se o valor enviado para subject não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Parabéns!! Você ganhou na loteria!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", os cabeçalhos SMTP serão:


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

De fato, isso permite que um invasor crie mensagens de spam ou envie e-mails anônimos entre outros ataques.

References

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

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

[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 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 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

A inclusão de dados não validados em um cabeçalho SMTP pode permitir que invasores adicionem cabeçalhos arbitrários, como CC ou BCC, que eles podem usar para deixar vazar o conteúdo de e-mails para si ou que podem usar o servidor de e-mail como um robô de spam.

Explanation

Vulnerabilidades de Manipulação de Cabeçalho SMTP ocorrem quando:

1. Dados entram em um aplicativo através de uma fonte não confiável, mais frequentemente uma solicitação HTTP em um aplicativo Web.

2. Os dados são incluídos em um cabeçalho SMTP enviado para um servidor de e-mail sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho SMTP é um meio para um fim, e não um fim em si mesma. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho SMTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho SMTP é usado para distribuir emails de spam. Se um aplicativo contiver um formulário vulnerável "Fale conosco" que permite definir o assunto e o corpo do e-mail, um invasor poderá definir qualquer conteúdo arbitrário e injetar um cabeçalho CC com uma lista de endereços de e-mail para distribuição anônima como spam, já que o e-mail será enviado a partir do servidor da vítima.

Exemplo: O segmento de código a seguir lê o assunto e o corpo de um formulário "Fale conosco":


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

Supondo que uma string formada por caracteres alfanuméricos padrão, como "A página não funciona", seja enviada na solicitação, os cabeçalhos SMTP podem assumir o seguinte formato:


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

No entanto, como o valor do cabeçalho é construído a partir de uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para subject não contiver caracteres de CR e LF. Se um invasor enviasse uma string mal-intencionada, como "Parabéns!!! Você ganhou na loteria!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", os cabeçalhos SMTP teriam o seguinte formato:


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

Isso permitirá efetivamente que um invasor elabore mensagens de spam ou envie e-mails anônimos entre outros 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 - CIS Azure Kubernetes Service Benchmark 2

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

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

[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.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

Vulnerabilidades de Manipulação de Cabeçalho SMTP ocorrem quando:

1. Dados entram em um aplicativo através de uma fonte não confiável, mais frequentemente uma solicitação HTTP em um aplicativo Web.

2. Os dados são incluídos em um cabeçalho SMTP enviado para um servidor de e-mail sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho SMTP é um meio para um fim, e não um fim em si mesma. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho SMTP.

Um dos ataques mais comuns de Manipulação de cabeçalho SMTP é para o uso da distribuição de e-mails de spam. Se um aplicativo contiver um formulário vulnerável "Fale conosco" que permite definir o assunto e o corpo do e-mail, um invasor poderá definir qualquer conteúdo arbitrário e injetar um cabeçalho CC com uma lista de endereços de e-mail para distribuição anônima como spam, já que o e-mail será enviado a partir do servidor da vítima.

Exemplo: O segmento de código a seguir lê o assunto e o corpo de um formulário "Fale conosco":


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

Supondo que uma string formada por caracteres alfanuméricos padrão, como "A página não funciona", seja enviada na solicitação, os cabeçalhos SMTP podem assumir o seguinte formato:


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


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