Coders Conquer Security: Share & Learn Series - Email Header Injection
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]
It's common for websites and applications to allow users to send feedback and various other bits of information through an application using email. And most people don't even think about it in terms of a potential security risk.
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoJaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
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]
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]
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demoJaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
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]
Table of contents
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
The Secure-by-Design movement is the future of secure software development. Learn about the key elements companies need to keep in mind when they think about a Secure-by-Design initiative.
DigitalOcean Decreases Security Debt with Secure Code Warrior
DigitalOcean's use of Secure Code Warrior training has significantly reduced security debt, allowing teams to focus more on innovation and productivity. The improved security has strengthened their product quality and competitive edge. Looking ahead, the SCW Trust Score will help them further enhance security practices and continue driving innovation.
Resources to get you started
Trust Score Reveals the Value of Secure-by-Design Upskilling Initiatives
Our research has shown that secure code training works. Trust Score, using an algorithm drawing on more than 20 million learning data points from work by more than 250,000 learners at over 600 organizations, reveals its effectiveness in driving down vulnerabilities and how to make the initiative even more effective.
Reactive Versus Preventive Security: Prevention Is a Better Cure
The idea of bringing preventive security to legacy code and systems at the same time as newer applications can seem daunting, but a Secure-by-Design approach, enforced by upskilling developers, can apply security best practices to those systems. It’s the best chance many organizations have of improving their security postures.
The Benefits of Benchmarking Security Skills for Developers
The growing focus on secure code and Secure-by-Design principles requires developers to be trained in cybersecurity from the start of the SDLC, with tools like Secure Code Warrior’s Trust Score helping measure and improve their progress.
Driving Meaningful Success for Enterprise Secure-by-Design Initiatives
Our latest research paper, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise is the result of deep analysis of real Secure-by-Design initiatives at the enterprise level, and deriving best practice approaches based on data-driven findings.