[Snyk] Fix for 1 vulnerabilities

[harunpehlivan]

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

Vulnerabilities that will be fixed

With an upgrade:

Severity	Priority Score (*)	Issue	Breaking Change	Exploit Maturity
	696/1000 Why? Proof of Concept exploit, Has a fix available, CVSS 7.5	Regular Expression Denial of Service (ReDoS) SNYK-JS-ANSIREGEX-1583908	Yes	Proof of Concept

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

Commit messages

Package name: grunt-sass

The new version differs by 12 commits.

• 2b662db 3.0.0
• 64f6444 Add support for Dart Sass (Workspace should be shared between code blocks in community examples datacamp/rdocumentation-app#283)
• 683ad07 Meta tweaks
• 12138d1 Fix linting
• 26c31c0 Require Node.js 8
• 276257e 2.1.0
• cfb6b53 Force the latest verison of node-sass
• b7087c6 Travis CI: Add Node.js 7 (Remove ability to submit placeholder example datacamp/rdocumentation-app#270)
• e9187e2 Lock the XO dependency
• c0486d9 2.0.0
• ef34efe ⬆️ node-sass@4
• f8015a3 Make XO happy

See the full diff

Package name: node-sass

The new version differs by 250 commits.

• 99242d7 7.0.1
• 77049d1 build(deps): bump sass-graph from 2.2.5 to 4.0.0 (#3224)
• c929f25 build(deps): bump node-gyp from 7.1.2 to 8.4.1 (#3209)
• 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

See the full diff

Package name: sails

The new version differs by 250 commits.

• 6e73a65 1.0.0
• 5f1d8b3 1.0.0-49
• 616e4e1 Insist on the latest sails-generate.
• 6ab0a5a 1.0.0-48
• 1e28823 Lifting with --redis now sets @ sailshq/connect-redis and @ sailshq/socket.io-redis.
• 9f29a03 Change approach from what was begun in 520a3c8cac5db1d9698c50efff82e476ec64fca8 so that we maintain the correct package name for the purpose of require().
• 520a3c8 Tolerate '@ sailshq/connect-redis' as session adapter.
• e2813f5 1.0.0-47
• 6768743 Tweak warning message.
• ce95c84 Update comments to reflect that req.setLocale() is fully supported as of Sails v1.0 and beyond.
• 0753a99 Trivial
• 3bdd786 Tweak troubleshooting tips.
• e8f9bee Check dev-dependencies for sails-hook-grunt
• e8493a6 1.0.0-46
• d1b6061 run tests on Node 9
• b3afed7 Fix issue with CSRF black/whitelists and routes containing optional params when the requested URL contains a querystring but NOT the optional param (whew!)
• 663527f Fix test error output
• 69ead96 Revert 35ae3ccba472bf4a8edb8ffd7d579d18391d1ba0 in favor of clarifying some of the wording.
• 35ae3cc Experiment with customizable www path
• a89d7a4 extrapolate www path
• a2a0789 Tolerate sails-hook-grunt specified in devDependencies when running sails www
• 0b42c59 Don't attempt to create a Redis connection if "client" is provided.
• 1700788 Update LICENSE.md
• 9c532dc Merge pull request #4267 from luislobo/patch-3

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:

🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

[secureflag-knowledge-base]

Cross-Site Request Forgery

Click here to find a Cross-Site Request Forgery training lab

Description

Cross-site Request Forgery (CSRF / XSRF) is a type of attack that occurs when a victim's web browser is forced to perform an unwanted action, on a trusted site, while the user is authenticated by a malicious site, blog, email, program, or instant message.

For most sites, browser requests automatically include any credentials (session cookie, Windows domain credentials, IP address etc.) associated with the site. As such, the site is unable to differentiate between a legitimate or forged request sent by the victim.

Attackers executing CSRF attacks have no way of seeing the response to the forged request, since the target of the attacks are transient i.e. state-changing requests. However, when paired with a social engineering attack on an administrative user, this method can devolve into full application compromise.

Read more

Impact

CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response of the forged request. The impact of a successful CSRF attack is limited to the capabilities exposed by the vulnerable application. For example, this attack could result in a transfer of funds, changing a password, or making a purchase with the user's credentials.

Scenarios

CSRF attacks typically comprise two actions: tricking the victim into clicking a link or loading page by social engineering or phishing, then sending a legitimate-looking, crafted request to the website from the victim's browser. The attacker is able to send the request with values, including cookies the website associates with the victim, meaning the website presumes the victim can execute certain actions on the site.

The following neatly exemplifies the application of the term 'cross-site' in this attack:

1. A user logs into www.vulnerablebank.com using forms authentication.

2. The server authenticates the user. The response from the server includes an authentication cookie.

3. Without logging out, the user visits a malicious web site, e.g. www.attackerwebsite.com. The malicious site contains the following HTML form:

   <form action="https://www.vulnerablebank.com/api/account" method="POST">
     <input type="hidden" name="action" value="pay">
     <input type="hidden" name="amount" value="1000">
     <input type="submit" value="Click Me">
   </form>

   Notice that the form action posts to the vulnerable site, not to the malicious site. This is the 'cross-site' part of CSRF.

4. The user clicks the submit button. The browser includes the authentication cookie with the request.

5. The request runs on the server with the user's authentication context and can do anything that an authenticated user is allowed to do.

Prevention

A number of code patterns that prevent CSRF attacks exist, and more than one can be applied at the same time as part of a defence in depth security strategy.

• Developers should require anti-forgery tokens for any unsafe methods (POST, PUT, DELETE) and ensure that safe methods (GET, HEAD) do not have any side effects.

• Developers should consider implementing a Synchronizer Token Pattern:

  A random token is generated server-side upon successful authentication and associated with the user's session. The token is returned to the user as part of an HTML response (e.g. a hidden field in a form or retrieved by AJAX).

  When the user needs to perform a sensitive operation, the token is included in the request. The application verifies the correctness of the token, and then performs the requested action only if the token in the request matches the token stored in the user's session.

• If maintaining the state for a CSRF token at the server side is problematic, developers can adopt the Double Submit Cookie Pattern. This is an easy to implement, stateless alternative that assigns a random value to both a cookie, and a request parameter, with the server verifying if the cookie value and request value match:

  1. The client requests an HTML page that contains a form.
  2. The server includes two tokens in the response. One token is sent as a cookie. The other is placed in a hidden form field. The tokens are generated randomly so that an adversary cannot guess the values.
  3. When the client submits the form, it must send both tokens back to the server. The client sends the cookie token as a cookie, and it sends the form token inside the form data.
  4. If a request does not include both tokens, the server disallows the request.

• If the origin header is present, developers should verify that its value matches the target origin. Unlike the Referer, the Origin header will be present in HTTP requests that originate from an HTTPS URL.

• If the origin header is not present, developers should verify that the hostname in the Referer header matches the target origin. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state, which is required to keep track of a synchronization token.

• Importantly, developers should enforce User Interaction based CSRF Defense:

  • Re-Authentication (password or stronger)
  • One-time Token
  • CAPTCHA

Testing

Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality.

• OWASP ASVS: 4.2.2
• OWASP Testing Guide: Testing for Cross Site Request Forgery

View this in the SecureFlag Knowledge Base

[secure-code-warrior-for-github]

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

Matched on "Cross-Site Request Forgery"

What is this? (2min video)

Session-related but not session-based, this attack is based on the ability of an attacker to force an action on a user’s browser (commonly in the form of a POST request) to perform an unauthorized action on behalf of the user. This can often occur without the user even noticing it… or only noticing when it is too late. The root cause is that browsers automatically send session cookies with all requests to a given domain, regardless of where the source of the request came from, and the application server cannot differentiate between a request that came from pages it served or a request that came from an unrelated page.

Try this challenge in Secure Code Warrior

[secure-code-warrior-for-github]

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

Matched on "CSRF"

What is this? (2min video)

Session-related but not session-based, this attack is based on the ability of an attacker to force an action on a user’s browser (commonly in the form of a POST request) to perform an unauthorized action on behalf of the user. This can often occur without the user even noticing it… or only noticing when it is too late. The root cause is that browsers automatically send session cookies with all requests to a given domain, regardless of where the source of the request came from, and the application server cannot differentiate between a request that came from pages it served or a request that came from an unrelated page.

Try this challenge in Secure Code Warrior

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 this challenge in Secure Code Warrior

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 this challenge in Secure Code Warrior