SCW Icons
hero bg no divider
Blog

코더즈 컨커 시큐리티: 셰어 앤 런 시리즈 - 이메일 헤더 인젝션

Jaap Karan Singh
Published Mar 21, 2019
Last updated on Mar 09, 2026

It's common these days for websites and applications to allow users to send feedback, appointment reminders and various other bits of information through an application using email. Normally this process is fairly benign, and most people don't even think about it in terms of a potential security risk.

However, like any other design element that allows for user input, if not properly configured, these seemingly inconsequential features can be manipulated by malicious users for nefarious purposes. All it takes is giving the user the ability to enter code into the input field that is then mistakenly processed by the server. Suddenly, an email application can become weaponized.

In this episode we will learn:

  • How attackers can trigger an email header injection
  • Why email header injections are dangerous
  • Techniques that can fix this vulnerability.

How do Attackers Trigger an Email Header Injection?

Although it's not often thought of as programmable, most email contact applications or features put into websites or applications can accept input that changes the nature of the query. It's just normally done automatically by the server after a user has entered their information, such as their email address, into the contract field. The program then configures the message, adds the appropriate recipients, and sends the message out using its default email server.

A typical email POST request might look like this:

POST /contact.php HTTP/1.1
Host: www.example.com

And generate code that looks like this after a user has entered their information:

name=RealName&replyTo=RealName@ValidServer.com&message=YourAppointmentReminder

The trouble occurs when hackers begin to inject code into the process instead of just their contact information. This is not unlike a SQL injection-type attack, but made against the email application. An example of a manipulated query that would instead send spam from your application to a targeted user might look like this:

name=FakeName\nbcc: SpammedVictim@TargetAddress.com&replyTo= FakeName@ValidServer.com&message=Spammed message

Why is Email Header Injection Dangerous?

Depending on the skill of the malicious user and their intentions, email header injection attacks can range from simply annoying to highly dangerous in terms of severity. On the low end of the severity scale, they might be able to insert their contact information into the BCC field of an outgoing message sent to a secret or undisclosed mailbox within your company, thus revealing it to a hacker.

More concerning, it might allow them to completely control your email server to send spam, phishing or other attack emails from your organization. They would not need to try and fake the fact that the email is coming from your internal servers, because it actually would be originating there. And if you are not monitoring that activity, they can even automate the process, sending out hundreds or thousands of emails using your organization's servers, and in such a way that it looks like you are actually instigating that activity.

Eliminating the Email Header Injection Problem

As with SQL injection and other attacks of this nature, the key to eliminating the possibility that a malicious user will exploit an email header vulnerability is never trusting user input. If a user is able to enter information, even if it seems like a trivial process such as entering their email address, you have to assume the worst. Or at least assume that the worst is possible.

Input validation should be performed for all parameters, and this includes when adding an email contact ability to an app or website. Whitelisting can be used to specifically enable processes and fields that you consider valid, while denying everything else. In fact, most frameworks have libraries available that can be used to help lock down functions to just those needed. Doing that will prevent any code or commands entered by malicious users from being recognized and processed by your servers.

More Information about Email Header Injections

For further reading, you can take a look at what OWASP says about email header injections. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Think youre ready to find and fix an email injection right now? Head to the platform and test your skills: [Start Here]

리소스 보기
리소스 보기

웹 사이트와 애플리케이션에서는 사용자가 이메일을 사용하여 애플리케이션을 통해 피드백 및 기타 다양한 정보를 보낼 수 있도록 하는 것이 일반적입니다.그리고 대부분의 사람들은 잠재적인 보안 위험 측면에서는 이에 대해 생각조차 하지 않습니다.

더 많은 것에 관심이 있으세요?

Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.

learn more

Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.

데모 예약
공유 대상:
linkedin brandsSocialx logo
작성자
Jaap Karan Singh
Published Mar 21, 2019

Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.

공유 대상:
linkedin brandsSocialx logo

It's common these days for websites and applications to allow users to send feedback, appointment reminders and various other bits of information through an application using email. Normally this process is fairly benign, and most people don't even think about it in terms of a potential security risk.

However, like any other design element that allows for user input, if not properly configured, these seemingly inconsequential features can be manipulated by malicious users for nefarious purposes. All it takes is giving the user the ability to enter code into the input field that is then mistakenly processed by the server. Suddenly, an email application can become weaponized.

In this episode we will learn:

  • How attackers can trigger an email header injection
  • Why email header injections are dangerous
  • Techniques that can fix this vulnerability.

How do Attackers Trigger an Email Header Injection?

Although it's not often thought of as programmable, most email contact applications or features put into websites or applications can accept input that changes the nature of the query. It's just normally done automatically by the server after a user has entered their information, such as their email address, into the contract field. The program then configures the message, adds the appropriate recipients, and sends the message out using its default email server.

A typical email POST request might look like this:

POST /contact.php HTTP/1.1
Host: www.example.com

And generate code that looks like this after a user has entered their information:

name=RealName&replyTo=RealName@ValidServer.com&message=YourAppointmentReminder

The trouble occurs when hackers begin to inject code into the process instead of just their contact information. This is not unlike a SQL injection-type attack, but made against the email application. An example of a manipulated query that would instead send spam from your application to a targeted user might look like this:

name=FakeName\nbcc: SpammedVictim@TargetAddress.com&replyTo= FakeName@ValidServer.com&message=Spammed message

Why is Email Header Injection Dangerous?

Depending on the skill of the malicious user and their intentions, email header injection attacks can range from simply annoying to highly dangerous in terms of severity. On the low end of the severity scale, they might be able to insert their contact information into the BCC field of an outgoing message sent to a secret or undisclosed mailbox within your company, thus revealing it to a hacker.

More concerning, it might allow them to completely control your email server to send spam, phishing or other attack emails from your organization. They would not need to try and fake the fact that the email is coming from your internal servers, because it actually would be originating there. And if you are not monitoring that activity, they can even automate the process, sending out hundreds or thousands of emails using your organization's servers, and in such a way that it looks like you are actually instigating that activity.

Eliminating the Email Header Injection Problem

As with SQL injection and other attacks of this nature, the key to eliminating the possibility that a malicious user will exploit an email header vulnerability is never trusting user input. If a user is able to enter information, even if it seems like a trivial process such as entering their email address, you have to assume the worst. Or at least assume that the worst is possible.

Input validation should be performed for all parameters, and this includes when adding an email contact ability to an app or website. Whitelisting can be used to specifically enable processes and fields that you consider valid, while denying everything else. In fact, most frameworks have libraries available that can be used to help lock down functions to just those needed. Doing that will prevent any code or commands entered by malicious users from being recognized and processed by your servers.

More Information about Email Header Injections

For further reading, you can take a look at what OWASP says about email header injections. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Think youre ready to find and fix an email injection right now? Head to the platform and test your skills: [Start Here]

리소스 보기
리소스 보기

보고서를 다운로드하려면 아래 양식을 작성하세요.

당사 제품 및/또는 관련 보안 코딩 주제에 대한 정보를 보내실 수 있도록 귀하의 동의를 구합니다.당사는 항상 귀하의 개인 정보를 최대한의 주의를 기울여 취급하며 마케팅 목적으로 다른 회사에 절대 판매하지 않습니다.

제출
scw success icon
scw error icon
양식을 제출하려면 'Analytics' 쿠키를 활성화하십시오.완료되면 언제든지 다시 비활성화할 수 있습니다.

It's common these days for websites and applications to allow users to send feedback, appointment reminders and various other bits of information through an application using email. Normally this process is fairly benign, and most people don't even think about it in terms of a potential security risk.

However, like any other design element that allows for user input, if not properly configured, these seemingly inconsequential features can be manipulated by malicious users for nefarious purposes. All it takes is giving the user the ability to enter code into the input field that is then mistakenly processed by the server. Suddenly, an email application can become weaponized.

In this episode we will learn:

  • How attackers can trigger an email header injection
  • Why email header injections are dangerous
  • Techniques that can fix this vulnerability.

How do Attackers Trigger an Email Header Injection?

Although it's not often thought of as programmable, most email contact applications or features put into websites or applications can accept input that changes the nature of the query. It's just normally done automatically by the server after a user has entered their information, such as their email address, into the contract field. The program then configures the message, adds the appropriate recipients, and sends the message out using its default email server.

A typical email POST request might look like this:

POST /contact.php HTTP/1.1
Host: www.example.com

And generate code that looks like this after a user has entered their information:

name=RealName&replyTo=RealName@ValidServer.com&message=YourAppointmentReminder

The trouble occurs when hackers begin to inject code into the process instead of just their contact information. This is not unlike a SQL injection-type attack, but made against the email application. An example of a manipulated query that would instead send spam from your application to a targeted user might look like this:

name=FakeName\nbcc: SpammedVictim@TargetAddress.com&replyTo= FakeName@ValidServer.com&message=Spammed message

Why is Email Header Injection Dangerous?

Depending on the skill of the malicious user and their intentions, email header injection attacks can range from simply annoying to highly dangerous in terms of severity. On the low end of the severity scale, they might be able to insert their contact information into the BCC field of an outgoing message sent to a secret or undisclosed mailbox within your company, thus revealing it to a hacker.

More concerning, it might allow them to completely control your email server to send spam, phishing or other attack emails from your organization. They would not need to try and fake the fact that the email is coming from your internal servers, because it actually would be originating there. And if you are not monitoring that activity, they can even automate the process, sending out hundreds or thousands of emails using your organization's servers, and in such a way that it looks like you are actually instigating that activity.

Eliminating the Email Header Injection Problem

As with SQL injection and other attacks of this nature, the key to eliminating the possibility that a malicious user will exploit an email header vulnerability is never trusting user input. If a user is able to enter information, even if it seems like a trivial process such as entering their email address, you have to assume the worst. Or at least assume that the worst is possible.

Input validation should be performed for all parameters, and this includes when adding an email contact ability to an app or website. Whitelisting can be used to specifically enable processes and fields that you consider valid, while denying everything else. In fact, most frameworks have libraries available that can be used to help lock down functions to just those needed. Doing that will prevent any code or commands entered by malicious users from being recognized and processed by your servers.

More Information about Email Header Injections

For further reading, you can take a look at what OWASP says about email header injections. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Think youre ready to find and fix an email injection right now? Head to the platform and test your skills: [Start Here]

웨비나 보기
시작하기
learn more

아래 링크를 클릭하고 이 리소스의 PDF를 다운로드하십시오.

Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.

보고서 보기데모 예약
리소스 보기
공유 대상:
linkedin brandsSocialx logo
더 많은 것에 관심이 있으세요?

공유 대상:
linkedin brandsSocialx logo
작성자
Jaap Karan Singh
Published Mar 21, 2019

Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.

공유 대상:
linkedin brandsSocialx logo

It's common these days for websites and applications to allow users to send feedback, appointment reminders and various other bits of information through an application using email. Normally this process is fairly benign, and most people don't even think about it in terms of a potential security risk.

However, like any other design element that allows for user input, if not properly configured, these seemingly inconsequential features can be manipulated by malicious users for nefarious purposes. All it takes is giving the user the ability to enter code into the input field that is then mistakenly processed by the server. Suddenly, an email application can become weaponized.

In this episode we will learn:

  • How attackers can trigger an email header injection
  • Why email header injections are dangerous
  • Techniques that can fix this vulnerability.

How do Attackers Trigger an Email Header Injection?

Although it's not often thought of as programmable, most email contact applications or features put into websites or applications can accept input that changes the nature of the query. It's just normally done automatically by the server after a user has entered their information, such as their email address, into the contract field. The program then configures the message, adds the appropriate recipients, and sends the message out using its default email server.

A typical email POST request might look like this:

POST /contact.php HTTP/1.1
Host: www.example.com

And generate code that looks like this after a user has entered their information:

name=RealName&replyTo=RealName@ValidServer.com&message=YourAppointmentReminder

The trouble occurs when hackers begin to inject code into the process instead of just their contact information. This is not unlike a SQL injection-type attack, but made against the email application. An example of a manipulated query that would instead send spam from your application to a targeted user might look like this:

name=FakeName\nbcc: SpammedVictim@TargetAddress.com&replyTo= FakeName@ValidServer.com&message=Spammed message

Why is Email Header Injection Dangerous?

Depending on the skill of the malicious user and their intentions, email header injection attacks can range from simply annoying to highly dangerous in terms of severity. On the low end of the severity scale, they might be able to insert their contact information into the BCC field of an outgoing message sent to a secret or undisclosed mailbox within your company, thus revealing it to a hacker.

More concerning, it might allow them to completely control your email server to send spam, phishing or other attack emails from your organization. They would not need to try and fake the fact that the email is coming from your internal servers, because it actually would be originating there. And if you are not monitoring that activity, they can even automate the process, sending out hundreds or thousands of emails using your organization's servers, and in such a way that it looks like you are actually instigating that activity.

Eliminating the Email Header Injection Problem

As with SQL injection and other attacks of this nature, the key to eliminating the possibility that a malicious user will exploit an email header vulnerability is never trusting user input. If a user is able to enter information, even if it seems like a trivial process such as entering their email address, you have to assume the worst. Or at least assume that the worst is possible.

Input validation should be performed for all parameters, and this includes when adding an email contact ability to an app or website. Whitelisting can be used to specifically enable processes and fields that you consider valid, while denying everything else. In fact, most frameworks have libraries available that can be used to help lock down functions to just those needed. Doing that will prevent any code or commands entered by malicious users from being recognized and processed by your servers.

More Information about Email Header Injections

For further reading, you can take a look at what OWASP says about email header injections. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Think youre ready to find and fix an email injection right now? Head to the platform and test your skills: [Start Here]

목차

PDF 다운로드
리소스 보기
더 많은 것에 관심이 있으세요?

Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.

learn more

Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.

데모 예약다운로드
공유 대상:
linkedin brandsSocialx logo
리소스 허브

시작하는 데 도움이 되는 리소스

더 많은 게시물
리소스 허브

시작하는 데 도움이 되는 리소스

더 많은 게시물