Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Snyk] Fix for 1 vulnerabilities #58

Open
wants to merge 1 commit into
base: next
Choose a base branch
from

Conversation

harunpehlivan
Copy link
Owner

This PR was automatically created by Snyk using the credentials of a real user.


Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.

Changes included in this PR

  • Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
    • packages/react-scripts/package.json

Vulnerabilities that will be fixed

With an upgrade:
Severity Priority Score (*) Issue Breaking Change Exploit Maturity
high severity 661/1000
Why? Recently disclosed, Has a fix available, CVSS 7.5
Prototype Pollution
SNYK-JS-LOADERUTILS-3043105
Yes No Known Exploit

(*) Note that the real score may have changed since the PR was raised.

Commit messages
Package name: css-loader The new version differs by 249 commits.

See the full diff

Package name: eslint-loader The new version differs by 73 commits.

See the full diff

Package name: file-loader The new version differs by 64 commits.

See the full diff

Package name: html-webpack-plugin The new version differs by 250 commits.
  • 74fae99 chore(release): 5.0.0
  • 94a20df chore: update to webpack 5.20.0
  • c5c8212 feat: add meta attribute for html tags
  • d0ab774 feat: provide public path to the alterAssetTagGroups hook
  • 5200ae6 feat: provide public path to the alterAssetTags hook
  • ccbe93a chore: update examples to latest webpack version
  • 33cbd59 fix: generate html files even if no webpack entry exists
  • 826739f feat: allow to use the latest loader-utils and tapable version
  • 81d7b2c feat: add typings for options and version
  • 8d34b81 fix: use correct casing for webpack type import
  • 36f9aca chore: upgrade dev dependencies
  • 1755962 chore: fix css-loader for unit testing
  • a79ab17 chore: drop support for appcache-webpack-plugin as it is not compatible to webpack 5
  • 7c3146d feat: allow to set publicPath to empty string ’’
  • b109213 docs: update installation instructions for webpack 4
  • 833b46b fix: inject javascripts in the <head> tag for inject:true and scriptLoading:'defer'
  • 13af0fb feat: add full support for public paths inside templates
  • fd5fe58 refactor: move the publicPath generation into a seperate function
  • 60a6ef8 test: add test for experiments: { outputModule: true }
  • a43ab72 feat: overrule module output
  • 10a0c5e fix: adjust tests as webpack 5 will no longer emit files for builds with errors
  • 2975a6a feat: process html during the processAssets stage PROCESS_ASSETS_STAGE_OPTIMIZE_INLINE
  • 0f9c239 fix: add support for publicPath: 'auto' in combination with type: 'asset/resource'
  • ab8b195 fix: support loaders like raw-loader

See the full diff

Package name: postcss-loader The new version differs by 87 commits.

See the full diff

Package name: style-loader The new version differs by 109 commits.

See the full diff

Package name: thread-loader The new version differs by 38 commits.

See the full diff

Package name: url-loader The new version differs by 57 commits.

See the full diff

Package name: webpack The new version differs by 250 commits.

See the full diff

Check the changes in this PR to ensure they won't cause issues with your project.


Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information:
🧐 View latest project report

🛠 Adjust project settings

📚 Read more about Snyk's upgrade and patch logic


Learn how to fix vulnerabilities with free interactive lessons:

🦉 Prototype Pollution

@secureflag-knowledge-base
Copy link

Code Injection

Click here to find a Code Injection training lab

Description

Code Injection, also known as Remote Code Execution (RCE), is possible when unsafe user-supplied data is used to run server-side code. This is typically as a result of an application executing code without prior validation, thus allowing an attacker to execute arbitrary code within the context of the vulnerable application.

Not to be confused with OS Command Injection, Code Injection attacks allow the attacker to add their own code to be executed by the application, whereas OS Command Injection extends the preset functionality of the application to execute system commands, usually within the context of a shell.

Code Injection attacks are only limited by the functionality of the language the attacker has injected i.e. not very limited at all! If PHP code is the language chosen for the injection and is executed successfully, the attacker has every utility available in PHP at her/his disposal.

The Code Injection attack category encompasses multiple types of injection attacks, all of which are very prevalent and capable of extremely high levels of compromise. Indeed, OWASP has listed injection attacks as one of the most dangerous web application security risk since 2013.

Read more

Impact

Malicious attackers can leverage Code Injection vulnerabilities to gain a foothold in the hosting infrastructure, pivot to connected systems throughout the organization, execute unauthorized commands, and fully compromise the confidentiality, integrity, and availability of the application. Depending on the injection, this can usually lead to the complete compromise of the underlying operating system.

The list of devastating Code Injection attacks, both public and behind closed doors, is far too long to list. Hot off the press in 2020, this Code Injection discovery was shown to affect the default Mail application on stock iPhones and iPads, resulting in remote code execution.

In this particular instance, the vulnerability was identified by a security company which notified the vendor, Apple, of the issue. However, it is important as a developer to internalize the glaring reality that poorly written, unsecure code opens the way for attackers to potentially wreak havoc, which is why learning secure codeing skills from the beginning can potentially prevent an employer-destroying headline down the track.

Prevention

Code Injection attacks leveraging any language can be avoided by simply following some basic, yet essential, security practices. Overarching these general practices is the rule that a developer should treat all data as untrusted.

Developers must not dynamically generate code that can be interpreted or executed by the application using user-provided data. Evaluating code that contains user input should only be implemented if there is no other way of achieving the same result without code execution.

Testing

Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed.

View this in the SecureFlag Knowledge Base

@secure-code-warrior-for-github

Micro-Learning Topic: Prototype pollution (Detected by phrase)

Matched on "Prototype Pollution"

What is this? (2min video)

By adding or modifying attributes of an object prototype, it is possible to create attributes that exist on every object, or replace critical attributes with malicious ones. This can be problematic if the software depends on existence or non-existence of certain attributes, or uses pre-defined attributes of object prototype (such as hasOwnProperty, toString or valueOf).

Try a challenge in Secure Code Warrior

@secure-code-warrior-for-github

Micro-Learning Topic: OS command injection (Detected by phrase)

Matched on "OS Command Injection"

What is this? (2min video)

In many situations, applications will rely on OS provided functions, scripts, macros and utilities instead of reimplementing them in code. While functions would typically be accessed through a native interface library, the remaining three OS provided features will normally be invoked via the command line or launched as a process. If unsafe inputs are used to construct commands or arguments, it may allow arbitrary OS operations to be performed that can compromise the server.

Try a challenge in Secure Code Warrior

Helpful references
  • OWASP Command Injection - OWASP community page with comprehensive information about command injection, and links to various OWASP resources to help detect or prevent it.
  • OWASP testing for Command Injection - This article is focused on providing testing techniques for identifying command injection flaws in your applications

Micro-Learning Topic: Code injection (Detected by phrase)

Matched on "Code Injection"

What is this? (2min video)

Code injection happens when an application insecurely accepts input that is subsequently used in a dynamic code evaluation call. If insufficient validation or sanitisation is performed on the input, specially crafted inputs may be able to alter the syntax of the evaluated code and thus alter execution. In a worst case scenario, an attacker could run arbitrary code in the server context and thus perform almost any action on the application server.

Try a challenge in Secure Code Warrior

Helpful references

Micro-Learning Topic: Injection attack (Detected by phrase)

Matched on "Injection attack"

Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. Source: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Try a challenge in Secure Code Warrior

Helpful references

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants