[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
	461/1000 Why? Recently disclosed, Has a fix available, CVSS 3.5	Regular Expression Denial of Service (ReDoS) SNYK-JS-DEBUG-3227433	Yes	No Known Exploit

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

Commit messages

Package name: axios

The new version differs by 185 commits.

• 5c8095e Releasing 0.16.1
• 982183c Updating changelog
• fa58223 Merge pull request #828 from mzabriskie/feature/return-last-request-in-redirects
• a18f039 Merge pull request #829 from jcready/patch-3
• df6b46c Add caret
• 04982a2 Update follow-redirects dependency
• 19644ba Adding documentation for Buffer data
• 1883344 support node buffers less than 8192 bytes (#773)
• bbfbeff Minor grammar/line length changes (#547)
• a784774 Adding comment about header names (#778)
• 88cc84c Adding documentation for response.request
• 84d9a41 Adding code to assign the last request to axios response
• e5beab0 Adding test checking the request in axios response is the last in a redirect
• 08eb985 Merge pull request #818 from carlosromel/patch-1
• 21b43ed Merge pull request #826 from mzabriskie/github-templates
• 34b63f8 Adding additional instruction line
• bb57daa Adding templates for issues and pull requests
• 23c4dfc Update README.md
• a8dab57 Merge pull request #741 from model3volution/Update/readme
• 19b7948 Releasing 0.16.0
• e6ffc52 Updating Upgrage Guide
• 8d675bb Merge branch 'master' of github.com:mzabriskie/axios
• 5b904d5 Updating changelog
• efc1f11 Merge pull request #781 from TomyJaya/TomyJaya-patch-1

See the full diff

Package name: newrelic

The new version differs by 250 commits.

• a7416c9 release: published 4.0.0
• a09e021 added security bulletin link
• 93eff8a updated the migration guide for v4
• 279dbc0 fixed double wrapping issue caused by updated agent-base
• b31f182 updated tests for using the new https-proxy-agent
• 0e439e1 update travis, pin https-proxy-agent to v2.2.0
• b950b5d updated changelog for v4.0.0
• 4c5362d change version check to a minimum node version of v4
• 55a93bf updated https-proxy-agent to v2.2.0
• f0516b0 release: published 3.3.1
• 67f5a6a chore: add methods to dev deps
• b8f150f docs: release notes typos
• b29fb93 chore(mongo): pin versioned tests to <3.0.6
• b729e1c Update changelog for v3.3.1
• bc0157d Merge pull request #1401 from NodeJS-agent/psvet/attribute-types
• b199f99 test(attributes): add test for attribute value types
• c736c44 fix(attributes): restrict attribute values to primitive types
• 21190ee Merge pull request #1399 from NodeJS-agent/bclement/recordQuery-after
• ac28f90 Merge pull request #1398 from NodeJS-agent/bclement/specified-inactive-parent
• c9b0233 allow after handlers in DatastoreShim#recordQuery
• 04dde7d errant whitespace squashing
• 9443202 check that the parent specified to Shim#record belongs to an active transaction
• e444e35 release: published 3.3.0
• 153535a Update README.md

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:

🦉 Regular Expression Denial of Service (ReDoS)

[secureflag-knowledge-base]

Cross-Site Request Forgery

Play Labs on this vulnerability with SecureFlag!

Start Cross-Site Request Forgery 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: 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 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 a challenge in Secure Code Warrior

Helpful references

• Securing Rails Applications - Cross-Site Request Forgery (CSRF) - A Rails Guide that describes common security problems in web applications and how to avoid them with Rails.
• Spring Security - Cross Site Request Forgery (CSRF) - A Spring Security article that describes Spring support for protecting against Cross Site Request Forgery attacks.
• csurf Node.js CSRF protection middleware - Documentation on CSRF protection provided by the csurf middleware for Express.
• XSRF/CSRF Prevention in ASP.NET MVC and Web Pages - A detailed Microsoft article on how to prevent cross-site request forgery in ASP.NET MVC and Web Pages.
• Django Documentation - Cross Site Request Forgery protection - Documentation on CSRF protection provided by the Django framework.
• OWASP Cross-Site Request Forgery Prevention Cheat Sheet - This cheatsheet is focused on providing clear, simple, actionable guidance for preventing cross-site request forgery flaws in your applications.
• Laravel Docs - CSRF Protection - Documentation on CSRF protection provided by the Laravel framework.
• OWASP Cross Site Request Forgery (CSRF) - OWASP community page with comprehensive information about cross-site request forgery, and links to various OWASP resources to help detect or prevent it.
• Preventing Cross-Site Request Forgery (CSRF) Attacks in ASP.NET MVC Application - A detailed Microsoft article on how to prevent cross-site request forgery in ASP.NET MVC.

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