Details

    • Message:
      Make sure that this email is sent in a safe manner.
    • Default Severity:
      Critical
    • Impact:
      High
    • Likelihood:
      Low
    • Default Quality Profiles:
      Sonar way
    • Targeted languages:
      ABAP, APEX, C#, C, C++, Cobol, CSS, Flex, Go, HTML, JavaScript, Kotlin, Objective-C, PHP, PL/I, PL/SQL, Python, RPG, Ruby, Rust, Scala, Solidity, Swift, T-SQL, TypeScript, VB.Net, VB6
    • Covered Languages:
      Java
    • Irrelevant for Languages:
      XML
    • Analysis Scope:
      Main Sources
    • CWE:
      CWE-93, CWE-80
    • OWASP:
      A1
    • SANS Top 25:
      Insecure Interaction Between Components

      Description

      Sending emails is security-sensitive. For example, it has led in the past to the following vulnerabilities:

      Emails can create multiple vulnerabilities:

      Information exposure
      Emails often contain sensitive information which might be exposed to an attacker.

      Injecting dangerous content
      Emails can contain html and javascript code, thus they can be used for XSS attacks.

      Email Header Injection
      This is one of the most common attacks.

      Email fields such as subject, to, cc, bcc, from are set in Email "headers". Those headers are separated by CR ("carriage return" often represented as \r) or LF ("line feed" often represented as \n) characters.

      If an unsanitized input is provided to a header field, it becomes vulnerable to Email Header Injection attacks. An attacker can then add fields in the header or even modify the message.

      For example, providing the following value to the From field

      me@example.com\nCc:injectedrecipient@otherexample.com\nBcc:yetanother@myexample.com,andagain@thisisdangerous.net
      

      would result in injecting two additional fields (CC and BCC):

      FROM: me@example.com
      CC: injectedrecipient@otherexample.com
      BCC: yetanother@myexample.com,andagain@thisisdangerous.net
      

      This rule raises an issue when an API sending emails is called.

      Ask Yourself Whether

      • Email headers are provided by users and are not sanitized.
      • Email content contains data provided by users and it is not sanitized.
      • The email is not sent using a strong protocol.

      You are at risk if you answered yes to any of those questions.

      Recommended Secure Coding Practices

      • Use an email library which sanitizes headers.
      • Sanitize every piece of data sent via emails, especially when the mime type is html.
      • Use a strong protocol to send your emails, i.e. secure versions of SSL or TLS.

      See

        Attachments

          Issue Links

          1.
          Java RSPEC-5317 Language-Specification Active Unassigned

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                nicolas.harraudeau Nicolas Harraudeau
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: