Don’t Let Code Injections Mess Up Your Holiday eCommerce Season

The holidays are right around the corner. It’s a well-deserved time to spend with your friends and family, and it likely translates to increased online sales. But more eCommerce activity also means increased cybersecurity risks. 

Most organizations with eCommerce deploy cybersecurity measures such as Content Security Policies (CPSs), to help secure their site and protect their customer’s personally identifiable information from a breach. Specifically, CSPs act to defend websites against online scripts that can cause fraud or steal credit card information. 

And while CSPs do represent a solid first line of defense, as we will soon explore, there is also so much more that organizations need to do to protect against malicious scripts and code injections. That’s because CSPs are only as effective as your allow list, so if a hacker targets any services already used by your CSPs, attacks are easy to execute. 

In this article, we’ll dive into how and why code injections are a threat to your web applications, why CSPs are effective but not enough to stop injections and additional measures that you can take to guard against code injections. 

How are code injections a threat to your web applications?  

A ‘code injection’ is a general security term used to refer to cyberattacks that involve injecting malicious code that will then be used by the infected application. It’s worth noting that code injection is distinctively different from the similarly named command injection, in that with the latter the hacker is not limited by the functionality of the injected code.

Injection flaws are still one of the most critical forms of security risk to web applications. Code injections are usually made possible as a result of poor handling of data. Specifically, code injections can arise as a result of no input or output data validation, which in layman’s terms means that the data stored has not been properly ‘sanitized.’ 

The application receiving the user input expects to receive only certain types of input, but if a developer is negligent in regards to what can be accepted (such as in regards to format or accepted characters), the hacker can be successful. When a code injection attack is successful, the attacker has access to the database of the application. 

What are CSPs...and are they enough?  

A CSP is a set of rules that are defined by a web developer to either allow or block types of requests. This is intended to ensure stronger security for site visitors since it reduces the odds they will open an application on which malicious coding is running. For example, developers can use CSPs to block any code (such as JavaScript) from being uploaded from domains that are unfamiliar. 

It’s ultimately the responsibility of the web application owner to define the CSP for their site, but it’s often the developer(s) who will set and enforce those policies. An example of a CSP would be to make it so that all forms of visual media uploaded to a site must come from domains that are individually approved. This will prevent hackers from injecting malicious JavaScript into embedded videos or photos. 

Setting good CSPs like this is effective but, at the same time, they should never be treated as the only line of defense. There are a few reasons for this. The first is that CSPs can struggle to keep up with innovations in web development. To put this into perspective, if your site’s development team is limited by a strict CSP, it’s possible that your site could fall behind competitors in terms of innovative deployments

Another problem is the fact that according to a recent Enterprise Strategy Group survey, over 76 percent of developers never received security training in their college IT programs. Your developer may not be experienced in, for example, secure coding best practices and may not be able to detect certain forms of malicious activity. You can help remedy this by offering secure code training.

Guarding yourself against code injections   

One of the best cybersecurity strategies to guard your web applications against code injection is to not permit any dynamic code to be executed in your application. Do not allow constructs such as ‘function’ or ‘eval.’ Steer clear of serialization, which is inherently vulnerable to injection attacks that can inject code during the normal serialization process. 

Another good strategy is to limit the use of permissible special characters in your allow-list. Scan for escape symbols and characters (specifically line termination characters, comment marks, and command delimiters). Allow a very limited set of values and characters, and ensure that your application will only accept those characters and nothing else.

Assume that all data is untrustworthy from the start until it has been verified. This is one of the core principles of protecting your data online. Be aware of all vulnerable injection vectors in your application, including HTML, data files, cookies, and queries. 

Require SSO, or Single Sign On, to help stop authentication errors. Set up Web Application Firewalls (WAFs), that will filter and monitor suspicious traffic coming to your applications. Regularly audit user actions in your network at least once per week to help detect suspicious activity as well.

Most importantly, have a strong application security (AppSec) program in place. With the right AppSec scans, you can quickly and accurately find and fix flaws. Best practice is to automate and integrate AppSec scans early in your software development lifecycle (SDLC). The earlier flaws are detected, the faster and less costly it is to remediate them. 

What can you do in the event of a code injection attack?  

Utilizing the strategies we’ve described above to guard against code injection attacks is important but, at the same time, you need to have a fallback plan if a vulnerability you failed to recognize results in a breach. 

The very first thing you need to do after a security breach is to figure out which applications and servers have been compromised. Contain them as quickly as you can to ensure that nothing else is affected. Communicate with all contractors or employees on your IT team to let them know what happened.

If you have an AppSec program in place, the scanner will recommend the necessary security steps to help defend your application. Depending on what’s recommended, you may need to reconfigure your allow list for valid statements, set parameterized queries with prepared statements, remove more functionalities to reduce your application’s attack surface, and set stricter access privileges. 

Additional precautions to take include investing in an insurance policy to help cover financial damages in the event of a breach. Finally, have a game plan for how you will alert customers to news of the breach. It’s important to be transparent regarding the breach and efforts to contain it. This will help communicate that you are doing everything possible to keep their data safe.

Conclusion  

Don’t fall victim to a cyberattack this holiday season. Be proactive in protecting your applications. 

For additional tips on avoiding a breach or to learn more about Veracode’s application security solutions, check out the Veracode products page.

Want to stay up to date on the latest Veracode news? Sign up for our monthly newsletter.