[Snyk] Security upgrade node-sass from 3.13.1 to 7.0.0

[snyk-bot]

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:
  • package.json

Vulnerabilities that will be fixed

With an upgrade:

Severity	Priority Score (*)	Issue	Breaking Change	Exploit Maturity
	479/1000 Why? Has a fix available, CVSS 5.3	Improper Certificate Validation SNYK-JS-NODESASS-1059081	Yes	No Known Exploit
	550/1000 Why? Has a fix available, CVSS 6.5	Out-of-bounds Read SNYK-JS-NODESASS-535499	Yes	No Known Exploit
	726/1000 Why? Proof of Concept exploit, Has a fix available, CVSS 8.1	Out-of-bounds Read SNYK-JS-NODESASS-535501	Yes	Proof of Concept
	600/1000 Why? Has a fix available, CVSS 7.5	Uncontrolled Recursion SNYK-JS-NODESASS-535503	Yes	No Known Exploit
	646/1000 Why? Proof of Concept exploit, Has a fix available, CVSS 6.5	Resource Exhaustion SNYK-JS-NODESASS-535504	Yes	Proof of Concept
	761/1000 Why? Proof of Concept exploit, Has a fix available, CVSS 8.8	NULL Pointer Dereference SNYK-JS-NODESASS-535505	Yes	Proof of Concept
	589/1000 Why? Has a fix available, CVSS 7.5	Uncontrolled Recursion SNYK-JS-NODESASS-540960	Yes	No Known Exploit
	589/1000 Why? Has a fix available, CVSS 7.5	Out-of-bounds Read SNYK-JS-NODESASS-540962	Yes	No Known Exploit
	589/1000 Why? Has a fix available, CVSS 7.5	Improper Input Validation SNYK-JS-NODESASS-540966	Yes	No Known Exploit
	589/1000 Why? Has a fix available, CVSS 7.5	Improper Input Validation SNYK-JS-NODESASS-540968	Yes	No Known Exploit
	589/1000 Why? Has a fix available, CVSS 7.5	Uncontrolled Recursion SNYK-JS-NODESASS-540970	Yes	No Known Exploit
	589/1000 Why? Has a fix available, CVSS 7.5	Out-of-bounds Read SNYK-JS-NODESASS-540972	Yes	No Known Exploit
	761/1000 Why? Proof of Concept exploit, Has a fix available, CVSS 8.8	NULL Pointer Dereference SNYK-JS-NODESASS-540974	Yes	Proof of Concept
	646/1000 Why? Proof of Concept exploit, Has a fix available, CVSS 6.5	Denial of Service (DoS) SNYK-JS-NODESASS-540982	Yes	Proof of Concept
	539/1000 Why? Has a fix available, CVSS 6.5	Out-of-bounds Read SNYK-JS-NODESASS-540984	Yes	No Known Exploit
	589/1000 Why? Has a fix available, CVSS 7.5	Out-of-bounds Read SNYK-JS-NODESASS-540986	Yes	No Known Exploit
	589/1000 Why? Has a fix available, CVSS 7.5	Denial of Service (DoS) SNYK-JS-NODESASS-540988	Yes	No Known Exploit
	509/1000 Why? Has a fix available, CVSS 5.9	Denial of Service (DoS) SNYK-JS-NODESASS-542662	Yes	No Known Exploit

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

Commit messages

Package name: node-sass

The new version differs by 250 commits.

• 918dcb3 Lint fix
• 0a21792 Set rejectUnauthorized to true by default (#3149)
• e80d4af chore: Drop EOL Node 15 (#3122)
• d753397 feat: Add Node 17 support (#3195)
• dcf2e75 build(deps-dev): bump eslint from 7.32.0 to 8.0.0
• bfa1a3c build(deps): bump actions/setup-node from 2.4.0 to 2.4.1
• 80d6c00 chore: Windows x86 on GitHub Actions (#3041)
• 566dc27 build(deps-dev): bump fs-extra from 0.30.0 to 10.0.0 (#3102)
• 7bb5157 build(deps): bump npmlog from 4.1.2 to 5.0.0 (#3156)
• 2efb38f build(deps): bump chalk from 1.1.3 to 4.1.2 (#3161)
• fca5257 build(deps): bump actions/setup-node from 2.3.0 to 2.4.0
• 6200b21 docs: Double word "support" (#3159)
• eaf791a build(deps): bump actions/setup-node from 2.1.5 to 2.3.0
• 16b8d4b build(deps): bump coverallsapp/github-action from 1.1.2 to 1.1.3
• c167004 6.0.1
• 911d4db remove mkdirp dep (#3108)
• 30a52f7 build(deps): bump meow from 3.7.0 to 9.0.0
• 7e08463 build(deps-dev): bump mocha from 8.4.0 to 9.0.1
• cfcbb2c chore: Use default Apline version from docker-node (#3121)
• 886319b chore: Drop Node 10 support
• c908f4f fix: Bump OSX minimum to 10.11
• 8ab02da fix: Remove old compiler gyp settings
• 3d7b9d0 chore: Add Node 16 support
• 4115e9d build(deps): bump actions/setup-node from v2.1.4 to v2.1.5

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:

🦉 Resource Exhaustion
🦉 Uncontrolled Recursion
🦉 Out-of-bounds Read
🦉 More lessons are available in Snyk Learn

[secureflag-knowledge-base]

Cross-Site Scripting

Click here to find a Cross-Site Scripting training lab

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 bypass the same-origin policy, 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 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) and thus tricks 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 (it will be ignored by the CSS parser) - 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 Content Security Policy, including what it does and how to use it, see this article.

X-XSS-Protection Header

This HTTP response header enables the Cross-Site Scripting (XSS) filter built into some modern web browsers. The header is usually enabled by default anyway, so its role is to re-enable the filter for a particular website if it was disabled by the user.

Content Types

To prevent non-HTML HTTP responses from embedding data which 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

Modern JavaScript frameworks (e.g., AngularJS, ReactJS) 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.

• OWASP ASVS: 5.3.1, 5.3.3
• OWASP Testing Guide: Testing for Reflected Cross Site Scripting, Testing for Stored Cross Site Scripting, Testing for DOM-Based Cross Site Scripting

View this in the SecureFlag Knowledge Base

[secure-code-warrior-for-github]

Micro-Learning Topic: Weak input validation (Detected by phrase)

Matched on "Improper Input Validation"

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

• OWASP Top Ten 2021 A03: Injection - OWASP Top Ten articles provide basic techniques to protect against these high risk problem areas, and guidance on where to go next.
• OWASP Injection Prevention Cheat Sheet in Java - This article is focused on providing clear, simple, actionable guidance for preventing injection flaws in your Java applications.
• OWASP Input Validation Cheat Sheet - This cheatsheet is focused on providing clear, simple, actionable guidance for preventing injection and input validation flaws in your applications.
• OWASP Injection Prevention Cheat Sheet - This article is focused on providing clear, simple, actionable guidance for preventing injection flaws in your applications.
• OWASP Top Ten Proactive Controls 2018 C5: Validate All Inputs - Detailed article on input validation as a programming technique for ensuring that only properly formatted data may enter a software system component.

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: Resource exhaustion (Detected by phrase)

Matched on "Resource Exhaustion"

What is this? (2min video)

Allocating objects or timers with user-controlled sizes or durations can cause resource exhaustion.

Try a challenge in Secure Code Warrior

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

Matched on "xss"

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

• Prevent Cross-Site Scripting (XSS) in ASP.NET Core - A detailed Microsoft article on how to prevent cross-site scripting in ASP.NET Core.
• OWASP Cross Site Scripting (XSS) Software Attack - OWASP community page with comprehensive information about cross site scripting, and links to various OWASP resources to help detect or prevent it.
• OWASP Cross Site Scripting Prevention Cheat Sheet - This article provides a simple positive model for preventing XSS using output encoding properly.

[secure-code-warrior-for-github]

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

• Prevent Cross-Site Scripting (XSS) in ASP.NET Core - A detailed Microsoft article on how to prevent cross-site scripting in ASP.NET Core.
• OWASP Cross Site Scripting (XSS) Software Attack - OWASP community page with comprehensive information about cross site scripting, and links to various OWASP resources to help detect or prevent it.
• OWASP Cross Site Scripting Prevention Cheat Sheet - This article provides a simple positive model for preventing XSS using output encoding properly.

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