[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
	708/1000 Why? Proof of Concept exploit, Recently disclosed, Has a fix available, CVSS 6.3	Directory Traversal SNYK-JS-GRUNT-2635969	Yes	Proof of Concept

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

Commit messages

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:

🦉 Directory Traversal

[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: Directory traversal (Detected by phrase)

Matched on "Directory Traversal"

What is this? (2min video)

Path traversal vulnerabilities occur when inputs that have not been sufficiently validated or sanitised are used to build directory or file paths. If an attacker can influence the path being accessed by the server, they may be able to gain unauthorised access to files or even execute arbitrary code on the server (when coupled with file upload functionality).

Try this challenge in Secure Code Warrior

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

[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