Don’t let code injections mess up your Christmas ecommerce season


The holidays are just around the corner. It’s a well-deserved time to spend with your friends and family, and this is likely to translate into higher sales online. However, more e-commerce activity also means increased cybersecurity risks.
Most eCommerce companies use cybersecurity measures such as Content Security Policies (CPSs) to protect their website and protect their customers’ personal data from being breached. Specifically, CSPs act to defend websites against online scripts that can cause fraud or steal credit card information.
And while CSPs are a solid first line of defense, as we’ll explore shortly, there is still a lot more businesses need to do to protect themselves from malicious scripts and code injections. That’s because CSPs are only as effective as your allow list. So if a hacker is targeting services that are already in use by your CSPs, attacks are easy to carry out.
In this article, you will learn how and why code injections pose a threat to your web applications, why CSPs are effective but not enough to stop injections, and additional measures to protect against code injections.
How do code injections pose a threat to your web applications?
“Code injection” is a general security term used to refer to cyberattacks that introduce malicious code that is then used by the infected application. It’s worth noting that code injection is quite different from the similarly named command injection, as the latter does not limit the hacker to the functionality of the injected code.
Injection failures are still one of the most critical forms of web application security risk. Code injections are usually made possible by poor handling of data. In particular, code injections can occur if there is no input or output data validation, which for laypeople means that the stored data has not been properly “cleaned up”.
The application receiving the user input expects to receive only certain types of input, but if a developer is negligent about what can be accepted (e.g. about the format or the characters accepted), the hacker can be successful. If a code injection attack is successful, the attacker has access to the application’s database.
What are CSPs … and are they enough?
A CSP is a set of rules defined by a web developer to either allow or block types of requests. This is intended to increase the safety of website visitors by reducing the chance that they will open an application that is running malicious coding. For example, developers can use CSPs to prevent any code (like JavaScript) from being uploaded from unknown domains.
It is ultimately the responsibility of the web application owner to define the CSP for their site, but it is often the developers who set and enforce these guidelines. An example of a CSP would be that all forms of visual media uploaded to a site must come from domains that have been individually approved. This prevents hackers from injecting malicious JavaScript into embedded videos or photos.
Establishing good CSPs like these is effective, but at the same time they should never be treated as the only line of defense. There are several reasons for this. The first is that CSPs can struggle to keep up with innovations in web development. To put this in perspective, if your website development team is constrained by a strict CSP, it is possible that your website will lag behind competitors in terms of innovative deployments
Another problem is that, according to a recent survey by the Enterprise Strategy Group, over 76 percent of developers in their college IT programs have never received security training. Your developer may be unfamiliar with secure coding best practices and may not be able to identify certain forms of malicious activity. You can remedy this by offering safe code training.
Protect yourself from code injections
One of the best cybersecurity strategies to use to protect your web applications from code injection is to keep dynamic code from running in your application. Do not allow constructs like ‘function’ or ‘eval’. Avoid 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 allowed special characters in your allow list. Look for escape symbols and characters (especially line terminators, comment characters, and command separators). Allow a very limited set of values ​​and characters, and make sure your application only accepts these characters and nothing else.
Assume that all data is untrustworthy from the start until it has been verified. This is one of the basic principles for protecting your data on the Internet. Be aware of all vulnerable injection vectors in your application, including HTML, data files, cookies, and queries.
Require SSO or Single Sign On to avoid authentication errors. Set up web application firewalls (WAFs) that filter and monitor suspicious traffic coming to your applications. Monitor user actions on your network regularly at least once a week to detect suspicious activity.
Most importantly, you have a strong application security program (AppSec) in place. With the right AppSec scans, you can find and fix errors quickly and accurately. Best practice is to automate and integrate AppSec scans early in your software development lifecycle (SDLC). The earlier errors are detected, the faster and more cost-effectively they can be remedied.
What can you do in the event of a code injection attack?
Using the strategies described above to protect against code injection attacks is important, but at the same time you need a fallback plan if a vulnerability that you did not identify leads to a security breach.
The very first thing to do after a security breach is to find out which applications and servers have been compromised. Do it as soon as you can to make sure nothing else is affected. Communicate with any contractors or employees on your IT team to let them know what happened.
If you have an AppSec program, the scanner recommends the necessary security steps to protect your application. Depending on the recommendation, you may need to reconfigure your allow list for valid statements, set parameterized queries with prepared statements, remove other features to reduce the attack surface of your application, and set more stringent access rights.
Other precautionary measures include investing in an insurance policy to cover financial damage in the event of a breach. Finally, you have a game plan for alerting customers to news about the security breach. It is important to be transparent about the violation and efforts to contain it. This helps you communicate that you are doing everything possible to protect your data.
Don’t fall victim to a cyber attack this holiday season. Protect your applications proactively.
For more tips on how to avoid a security breach or for more information about Veracode’s application security solutions, visit the Veracode product page.
Would you like to stay up to date with the latest Veracode news? Sign up for our monthly newsletter.

*** This is a syndicated blog from the Security Bloggers Network from Application safety research, news, and education blog written by [email protected] (sjones). Read the original article at:

Source link


About Author

Comments are closed.