One Article Review
| Source |  Veracode |
|---|---|
| Identifiant | 3699259 |
| Date de publication | 2021-11-23 14:21:23 (vue: 2021-11-23 20:05:27) |
| Titre | Don\'t Let Code Injections Mess Up Your Holiday eCommerce Season |
| Texte | 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 |
| Envoyé | Oui |
| Condensat | able about above accept accepted access according accurately act actions activity additional affected after against alert all allow already also another any application applications approved appsec are arise around article assume attack attacker attacks audit authentication automate avoiding aware because been behind being best block breach but can card cause certain characters check clear code coding college come coming command comment communicate competitors compromised conclusion constructs contain content contractors cookies core corner costly could cover cpss credit critical csp csps customer customers cyberattack cyberattacks cybersecurity damages data database defend defense define defined delimiters depending deploy deployments described deserved detect detected developer developers development different distinctively dive doing domains don during dynamic earlier early easy ecommerce effective efforts either else embedded employees enforce enough ensure enterprise errors escape eval event everything example execute executed expects experienced explore fact failed fall fallback family faster figure files filter finally financial find firewalls first fix flaws format forms fraud friends from function functionalities functionality game general good group guard guarding hacker hackers handling happened has have help holiday holidays how html identifiable important importantly include including increased individually infected information inherently inject injected injecting injection injections injections innovations innovative input insurance integrate intended investing involve javascript keep know latter layman learn least less let lifecycle like likely limit limited line list made make malicious marks may means measures media mess monitor more most much must named necessary need negligent network never news normal not nothing noting odds offering often once one online only open organizations out output over owner page parameterized per percent permissible permit personally perspective photos place plan policies policy poor possible practice practices precautions prepared prevent principles privileges proactive problem process products program programs properly protect protecting put queries quickly reasons receive received receiving recent recognize recommend recommended reconfigure reduce reduces refer regarding regards regularly remediate remedy remove represent requests require responsibility result results right risk risks rules running safe sales same sanitized scan scanner scans scripts sdlc season secure security serialization servers services set setting should sign similarly since single site software solid solutions soon special specifically spend sso start statements steal steer steps stop stored strategies strategy strict stricter strong stronger struggle successful such surface survey suspicious symbols take targets team term termination terms that them then thing those threat time tips traffic training translates transparent treated types ultimately unfamiliar until untrustworthy uploaded use used user usually utilizing valid validation values vectors veracode verified very victim videos visitors visual vulnerability vulnerable wafs web websites week well what when which who why will worth would your yourself |
| Tags | Vulnerability Threat |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.