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.

Sign up for GitHub

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

Jump to bottom

[Snyk] Upgrade @types/node from 20.10.4 to 22.8.6 #17

Merged
merged 1 commit into from
Nov 29, 2024
Merged

[Snyk] Upgrade @types/node from 20.10.4 to 22.8.6 #17

merged 1 commit into from
Nov 29, 2024

Conversation

JhayceFrancis
Copy link
Owner

snyk-top-banner

Snyk has created this PR to upgrade @types/node from 20.10.4 to 22.8.6.

ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

⚠️ Warning: This PR contains major version upgrade(s), and may be a breaking change.

  • The recommended version is 127 versions ahead of your current version.

  • The recommended version was released on 21 days ago.

Issues fixed by the recommended upgrade:

Issue Score Exploit Maturity
high severity Uncontrolled resource consumption
SNYK-JS-BRACES-6838727		 169 Proof of Concept
high severity Regular Expression Denial of Service (ReDoS)
SNYK-JS-CROSSSPAWN-8303230		 169 Proof of Concept
high severity Regular Expression Denial of Service (ReDoS)
SNYK-JS-CROSSSPAWN-8303230		 169 Proof of Concept
high severity Inefficient Regular Expression Complexity
SNYK-JS-MICROMATCH-6838728		 169 No Known Exploit
medium severity Cross-site Scripting (XSS)
SNYK-JS-SERIALIZEJAVASCRIPT-6147607		 169 Proof of Concept
medium severity Cross-site Scripting (XSS)
SNYK-JS-WEBPACK-7840298		 169 Proof of Concept
Release notes
Package name: @types/node
  • 22.8.6 - 2024-10-31
  • 22.8.5 - 2024-10-31
  • 22.8.4 - 2024-10-29
  • 22.8.3 - 2024-10-29
  • 22.8.2 - 2024-10-28
  • 22.8.1 - 2024-10-25
  • 22.8.0 - 2024-10-25
  • 22.7.9 - 2024-10-23
  • 22.7.8 - 2024-10-22
  • 22.7.7 - 2024-10-19
  • 22.7.6 - 2024-10-16
  • 22.7.5 - 2024-10-07
  • 22.7.4 - 2024-09-27
  • 22.7.3 - 2024-09-26
  • 22.7.2 - 2024-09-25
  • 22.7.1 - 2024-09-25
  • 22.7.0 - 2024-09-25
  • 22.6.2 - 2024-09-25
  • 22.6.1 - 2024-09-23
  • 22.6.0 - 2024-09-23
  • 22.5.5 - 2024-09-14
  • 22.5.4 - 2024-09-04
  • 22.5.3 - 2024-09-04
  • 22.5.2 - 2024-09-01
  • 22.5.1 - 2024-08-28
  • 22.5.0 - 2024-08-21
  • 22.4.2 - 2024-08-21
  • 22.4.1 - 2024-08-19
  • 22.4.0 - 2024-08-16
  • 22.3.0 - 2024-08-14
  • 22.2.0 - 2024-08-09
  • 22.1.0 - 2024-08-02
  • 22.0.3 - 2024-08-02
  • 22.0.2 - 2024-07-31
  • 22.0.1 - 2024-07-31
  • 22.0.0 - 2024-07-28
  • 20.17.6 - 2024-11-03
  • 20.17.5 - 2024-10-31
  • 20.17.4 - 2024-10-31
  • 20.17.3 - 2024-10-29
  • 20.17.2 - 2024-10-28
  • 20.17.1 - 2024-10-25
  • 20.17.0 - 2024-10-23
  • 20.16.15 - 2024-10-23
  • 20.16.14 - 2024-10-22
  • 20.16.13 - 2024-10-19
  • 20.16.12 - 2024-10-16
  • 20.16.11 - 2024-10-07
  • 20.16.10 - 2024-09-27
  • 20.16.9 - 2024-09-25
  • 20.16.8 - 2024-09-25
  • 20.16.7 - 2024-09-25
  • 20.16.6 - 2024-09-23
  • 20.16.5 - 2024-09-04
  • 20.16.4 - 2024-09-04
  • 20.16.3 - 2024-09-01
  • 20.16.2 - 2024-08-28
  • 20.16.1 - 2024-08-19
  • 20.16.0 - 2024-08-18
  • 20.15.0 - 2024-08-16
  • 20.14.15 - 2024-08-09
  • 20.14.14 - 2024-08-02
  • 20.14.13 - 2024-07-28
  • 20.14.12 - 2024-07-23
  • 20.14.11 - 2024-07-16
  • 20.14.10 - 2024-07-05
  • 20.14.9 - 2024-06-25
  • 20.14.8 - 2024-06-22
  • 20.14.7 - 2024-06-20
  • 20.14.6 - 2024-06-19
  • 20.14.5 - 2024-06-18
  • 20.14.4 - 2024-06-17
  • 20.14.3 - 2024-06-17
  • 20.14.2 - 2024-06-05
  • 20.14.1 - 2024-06-03
  • 20.14.0 - 2024-06-02
  • 20.13.0 - 2024-05-31
  • 20.12.14 - 2024-05-31
  • 20.12.13 - 2024-05-29
  • 20.12.12 - 2024-05-14
  • 20.12.11 - 2024-05-08
  • 20.12.10 - 2024-05-06
  • 20.12.9 - 2024-05-06
  • 20.12.8 - 2024-05-01
  • 20.12.7 - 2024-04-09
  • 20.12.6 - 2024-04-09
  • 20.12.5 - 2024-04-05
  • 20.12.4 - 2024-04-03
  • 20.12.3 - 2024-04-02
  • 20.12.2 - 2024-03-30
  • 20.12.1 - 2024-03-30
  • 20.12.0 - 2024-03-30
  • 20.11.30 - 2024-03-19
  • 20.11.29 - 2024-03-18
  • 20.11.28 - 2024-03-15
  • 20.11.27 - 2024-03-13
  • 20.11.26 - 2024-03-11
  • 20.11.25 - 2024-03-06
  • 20.11.24 - 2024-02-29
  • 20.11.23 - 2024-02-29
  • 20.11.22 - 2024-02-28
  • 20.11.21 - 2024-02-27
  • 20.11.20 - 2024-02-22
  • 20.11.19 - 2024-02-15
  • 20.11.18 - 2024-02-15
  • 20.11.17 - 2024-02-08
  • 20.11.16 - 2024-02-01
  • 20.11.15 - 2024-02-01
  • 20.11.14 - 2024-01-31
  • 20.11.13 - 2024-01-30
  • 20.11.12 - 2024-01-30
  • 20.11.11 - 2024-01-30
  • 20.11.10 - 2024-01-28
  • 20.11.9 - 2024-01-28
  • 20.11.8 - 2024-01-27
  • 20.11.7 - 2024-01-26
  • 20.11.6 - 2024-01-24
  • 20.11.5 - 2024-01-17
  • 20.11.4 - 2024-01-16
  • 20.11.3 - 2024-01-15
  • 20.11.2 - 2024-01-15
  • 20.11.1 - 2024-01-15
  • 20.11.0 - 2024-01-11
  • 20.10.8 - 2024-01-09
  • 20.10.7 - 2024-01-07
  • 20.10.6 - 2023-12-30
  • 20.10.5 - 2023-12-17
  • 20.10.4 - 2023-12-07
from @types/node GitHub release notes

Important

  • Warning: This PR contains a major version upgrade, and may be a breaking change.
  • Check the changes in this PR to ensure they won't cause issues with your project.
  • This PR was automatically created by Snyk using the credentials of a real user.
  • Max score is 1000. Note that the real score may have changed since the PR was raised.

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

For more information:

@snyk-bot
feat: upgrade @types/node from 20.10.4 to 22.8.6
861c138 
Snyk has created this PR to upgrade @types/node from 20.10.4 to 22.8.6.

See this package in npm:
@types/node

See this project in Snyk:
https://app.snyk.io/org/jhaycefrancis/project/8a725092-e41a-453d-8246-885c6516b584?utm_source=github&utm_medium=referral&page=upgrade-pr
@secureflag-knowledge-base SecureFlag Knowledge Base
Copy link

Cross-Site Scripting

Play SecureFlag Play Labs on this vulnerability with SecureFlag!

Description

Cross-site scripting (otherwise known as XSS) is a vulnerability that allows a malicious actor to manipulate a legitimate user's interactions with a vulnerable web application. Attackers exploit this to inject code into other legitimate users' browsers, often allowing them to perform any actions that the target user would normally perform, including gaining access to their data. In cases where the victim user has privileged application access, the attacker may use XSS to seize control of the application.

XSS attacks typically occur in web applications when data is received, frequently in the form of a web request, and the data is reflected back in the HTTP response to the user without validation.

XSS attacks can generally be divided into the following three categories.

Read more

Reflected XSS

Reflected XSS attacks arise when a web server reflects an injected script, such as a search result, an error message, or any other response that includes some or all of the input sent to the server as part of the request.

The attack is then delivered to the victim through another route (e.g., e-mail or an alternative website), thus tricking the user into clicking on a malicious link. The injected code travels to the vulnerable website, which reflects the attack payload back to the user's browser. The browser then executes the code because it came from a "trusted" server.

Stored XSS

In the Stored XSS attack, the injected script is stored on the target application as legitimate content, such as a message in a forum or a comment in a blog post. The injected code is stored in the database and sent to the users when it is retrieved, thus executing the attack payload in the victim's browser.

DOM-based XSS

DOM-based XSS vulnerabilities usually occur when the JavaScript in a page takes user-provided data from a source in the HTML, such as the document.location, and passes it to a JavaScript function that allows JavaScript code to be run, such as innerHTML(). The classic attack delivers the payload to the victim through another route (e.g., e-mail or an alternative website), thus tricking the user into visiting a malicious link. The exploitation is client-side, and the code is immediately executed in the user's browser.

Impact

XSS attacks can result in the disclosure of the user's session cookie, allowing an attacker to hijack the user's session and take over the account. Even though HTTPOnly is used to protect cookies, an attacker can still execute actions on behalf of the user in the context of the affected website.

As with all of the severe vulnerabilities that make up a part of the OWASP Top 10, XSS attacks can result in the complete compromise of a user's system, as stated in the description, if an attacker compromises a user holding the 'keys to the kingdom,' i.e., privileged access to applications/administrator rights, the results can be devastating.

Prevention

XSS attacks can be mitigated by performing appropriate server-side validation and escaping. Remediation relies on performing Output Encoding (e.g., using an escape syntax) for the type of HTML context into which untrusted data is reflected.

Input Validation

  • Exact Match: Only accept values from a finite list of known values.
  • Allow list: If a list of all the possible values can't be created, accept only known good data and reject all unexpected input.
  • Deny list: If an allow-list approach is not feasible (on free-form text areas, for example), reject all known bad values.

Output Encoding

Output Encoding is used to convert untrusted input into a safe form where the input is displayed as data to the user without executing as code in the browser. Output Encoding is performed when the data leaves the application to a downstream component. The table below lists the possible downstream contexts where the untrusted input could be used:

Context Code Encoding
HTML Body <div>USER-CONTROLLED-DATA</div> HTML Encoding
HTML Attribute <input type="text" value="USER-CONTROLLED-DATA"> HTML Attribute Encoding
URL Parameter <a href="/search?value=USER-CONTROLLED-DATA">Search</a> URL Encoding
CSS <div style="width: USER-CONTROLLED-DATA;">Selection</div> CSS Hex Encoding
JavaScript <script>var lang ='USER-CONTROLLED-DATA';</script>
<script>setLanguage('USER-CONTROLLED-DATA');</script>		 JavaScript Encoding

The following chart details a list of critical output encoding methods required to mitigate Cross-Site Scripting:

Encoding Type Encoding Mechanism
HTML Entity Encoding Convert &to &amp;
Convert <to &lt;
Convert >to &gt;
Convert "to &quot;
Convert 'to &#x27;
Convert /to &#x2F;
HTML Attribute Encoding Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value)
URL Encoding For standard percent encoding see here. URL encoding should only be used to encode parameter values, not the entire URL or path fragments of a URL.
JavaScript Encoding Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (XX = Integer)
CSS Hex Encoding CSS escaping supports \XX and \XXXXXX. Using a two-character escape can cause problems if the next character continues the escape sequence. There are two solutions:
- Add a space after the CSS escape (the CSS parser will ignore it)
- Use the full amount of CSS escaping possible by zero-padding the value.

Defense in Depth

Content Security Policy (CSP)

The Content Security Policy (CSP) is a browser mechanism that enables the creation of source allow lists for client-side resources of web applications, e.g., JavaScript, CSS, images, etc. CSP, via a special HTTP header, instructs the browser to only execute or render resources from those sources.

For example:

Content-Security-Policy: default-src: 'self'; script-src: 'self' static.domain.tld

The above CSP will instruct the web browser to load all resources only from the page's origin and JavaScript source code files from static.domain.tld. For more details on the Content Security Policy, including what it does and how to use it, see this article.

Content Types

To prevent non-HTML HTTP responses from embedding data, that might be dangerously interpreted as HTML or JavaScript, it is recommended to always send the Content-Type header in the HTTP response to ensure that browsers interpret it in the way it's intended.

Modern Frameworks

JavaScript frameworks (e.g., Angular, React) or server-side templating systems (e.g., Go Templates) have robust built-in protections against Reflected Cross-Site Scripting.

Testing

Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM-based XSS.

View this in the SecureFlag Knowledge Base

@secure-code-warrior-for-github Secure Code Warrior for GitHub
Copy link

Micro-Learning Topic: Regular expression denial of service (Detected by phrase)

Matched on "Regular Expression Denial of Service"

What is this? (2min video)

Denial of Service (DoS) attacks caused by Regular Expression which causes the system to hang or cause them to work very slowly when attacker sends a well-crafted input(exponentially related to input size).Denial of service attacks significantly degrade the service quality experienced by legitimate users. These attacks introduce large response delays, excessive losses, and service interruptions, resulting in direct impact on availability.

Try a challenge in Secure Code Warrior

Micro-Learning Topic: Cross-site scripting (Detected by phrase)

Matched on "Cross-site Scripting"

What is this? (2min video)

Cross-site scripting vulnerabilities occur when unescaped input is rendered into a page displayed to the user. When HTML or script is included in the input, it will be processed by a user's browser as HTML or script and can alter the appearance of the page or execute malicious scripts in their user context.

Try a challenge in Secure Code Warrior

Helpful references

Micro-Learning Topic: Denial of service (Detected by phrase)

Matched on "Denial of Service"

The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others. Source: https://www.owasp.org/index.php/Denial_of_Service

Try a challenge in Secure Code Warrior

Micro-Learning Topic: Inefficient regular expression (Detected by phrase)

Matched on "Inefficient Regular Expression"

What is this? (2min video)

A regular expression that requires exponential time to match certain inputs can be a performance bottleneck, and may be vulnerable to denial-of-service attacks.

Try a challenge in Secure Code Warrior

@secure-code-warrior-for-github Secure Code Warrior for GitHub
Copy link

Micro-Learning Topic: DOM-based cross-site scripting (Detected by phrase)

Matched on "DOM-Based Cross Site Scripting"

What is this? (2min video)

DOM-based cross-site scripting vulnerabilities occur when unescaped input is processed by client-side script and insecurely written into the page Document Object Model (DOM). This will result in immediate changes to the page, potentially without any call to the server. When HTML or script is included in the input, it will be processed by a user's browser as HTML or script and can alter the appearance of the page or execute malicious scripts in their user context.

Try a challenge in Secure Code Warrior

Micro-Learning Topic: Reflected cross-site scripting (Detected by phrase)

Matched on "Reflected Cross-Site Scripting"

What is this? (2min video)

Reflected cross-site scripting vulnerabilities occur when unescaped input is displayed in the resulting page displayed to the user. When HTML or script is included in the input, it will be processed by a user's browser as HTML or script and can alter the appearance of the page or execute malicious scripts in their user context.

Try a challenge in Secure Code Warrior

Micro-Learning Topic: Stored cross-site scripting (Detected by phrase)

Matched on "Stored Cross Site Scripting"

What is this? (2min video)

Stored cross-site scripting vulnerabilities happen when unescaped input is displayed by the application after successful storage in persistence layers (e.g. database or cache). When HTML or script is included in the input that is stored in the database, and is then rendered into a page without escaping or encoding, it will be processed by a user's browser as HTML or script and can alter the appearance of the page or execute malicious scripts in their user context.

Try a challenge in Secure Code Warrior

@JhayceFrancis
Copy link
Owner Author

🎉 Snyk checks have passed. No issues have been found so far.

✅ security/snyk check is complete. No issues have been found. (View Details)

@JhayceFrancis JhayceFrancis merged commit 36cecfb into main Nov 29, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@JhayceFrancis @snyk-bot