[Snyk] Upgrade @nextcloud/upload from 1.1.1 to 1.4.3

[JhayceFrancis]

Snyk has created this PR to upgrade @nextcloud/upload from 1.1.1 to 1.4.3.

ℹ️ 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.

---

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

• The recommended version was released on a month ago.

Issues fixed by the recommended upgrade:

	Issue	Score	Exploit Maturity
	Server-side Request Forgery (SSRF) SNYK-JS-AXIOS-7361793	255	Proof of Concept

Release notes

Package name: @nextcloud/upload

• 1.4.3 - 2024-08-07
  

  v1.4.3 (2024-08-07)

  Fixed

  • fix: Always request current content when triggering a menu entry by @ susnux in #1313
  • fix: Remove outdated languages that are blocking the real translations by @ susnux in #1282
  • fix(UploadPicker): Do not hardcode the height but use the CSS variable by @ susnux in #1309

  What's Changed

  • chore: Bump @ nextcloud/files from 3.5.1 to 3.7.0 by @ dependabot
  • chore: Bump @ nextcloud/paths from 2.1.0 to 2.2.1 by @ dependabot
  • chore: Bump @ nextcloud/sharing from 0.2.2 to 0.2.3 by @ dependabot
  • chore: Bump @ types/node from 20.14.10 to 22.1.0 by @ dependabot
  • chore: Bump @ vitest/coverage-v8 from 2.0.2 to 2.0.5 by @ dependabot
  • chore: Bump axios from 1.7.2 to 1.7.3 by @ dependabot
  • chore: Bump axios-retry from 4.4.1 to 4.5.0 by @ dependabot
  • chore: Bump blob-polyfill from 7.0.20220408 to 8.0.20240630 by @ dependabot
  • chore: Bump cypress from 13.13.0 to 3.13.2 by @ dependabot
  • chore: Bump cypress-io/github-action from 6.7.1 to 6.7.2 by @ dependabot
  • chore: Bump fast-xml-parser from 4.3.2 to 4.4.1 by @ dependabot
  • chore: Bump jsdom from 24.1.0 to 24.1.1 by @ dependabot
  • chore: Bump typedoc from 0.26.4 to 0.26.5 by @ dependabot
  • chore: Bump typescript from 5.4.5 to 5.5.4 by @ dependabot
  • chore: Bump vite from 5.3.3 to 5.3.5 by @ dependabot
  • chore: Bump webdav from 5.6.0 to 5.7.1 by @ dependabot
  • chore: monitor bundle size with codecov by @ skjnldsv in #1290
  • feat: add cypress selectors for new menu entries by @ skjnldsv in #1289
  • Translations updates

  Full Changelog: v1.4.2...v1.4.3

• 1.4.2 - 2024-07-12
  

  v1.4.2 (2024-07-11)

  Full Changelog

  Fixed

  • fix(uploader): increase max concurrency to 5 #1256 (skjnldsv)
  • fix: Use other menu entries instead of new ones twice #1269 (juliushaertl)
  • fix: Allow remote URL with protocol #1271 (susnux)

  Changed

  • Add SPDX header #1278 (AndyScherzinger)
  • Update translations
  • chore: add transifex-conventional-rebase.yml
  • chore: Bump @ nextcloud/dialogs from 5.3.2 to 5.3.5
  • Update development dependencies
• 1.4.1 - 2024-06-24
  

  v1.4.1 (2024-06-24)

  Fixed

  • fix: Prevent issues with Chromium based browsers #1250 (susnux)
• 1.4.0 - 2024-06-21
  

  v1.4.0 (2024-06-21)

  Full Changelog

  Added

  • Added retry capability for uploading files #1233 (Koc)

  Fixed

  • fix: Adjust isPublic detection for uploader #1234 (susnux)

  Changed

  • refactor: Use getUniqueName from @ nextcloud/files #1244 (susnux)
  • refactor: Use public-share aware functions from @ nextcloud/files and @ nextcloud/sharing #1245 (susnux)
  • chore: Bump @ cypress/vue2 from 2.1.0 to 2.1.1
  • chore: Bump @ nextcloud/dialogs from 5.3.1 to 5.3.2
  • chore: Bump braces from 3.0.2 to 3.0.3
  • chore: Bump codecov/codecov-action from 4.4.1 to 4.5.0
  • chore: Bump cypress-io/github-action from 6.7.0 to 6.7.1
  • chore: Bump ws from 8.17.0 to 8.17.1
  • chore: Bump @ nextcloud/files from 3.4.1 to 3.5.0
  • chore: Bump cypress from 13.11.0 to 13.12.0
  • chore: Bump @ types/node from 20.14.6 to 20.14.7
  • chore: Bump axios-retry from 4.4.0 to 4.4.1
• 1.3.0 - 2024-06-07
  

  v1.3.0 (2024-06-06)

  Full Changelog

  Added

  • feat: Implement upload on public shares using dav endpoint v2 by @ susnux in #1225

  Changed

  • refactor: Only import from nextcloud-axios not axios directly by @ susnux in #1224
  • Updated translations
  • chore(deps): Bump @ nextcloud/files from 3.3.1 to 3.4.0 by @ dependabot in #1220
  • chore(deps): Bump @ types/node to 20.14.2 by @ dependabot in #1227
• 1.2.0 - 2024-05-23
  

  v1.2.0 (2024-05-23)

  Full Changelog

  Added

  • feat(NodesPicker): Add support for FileSystemEntry by @ susnux in #1165
  • feat(ConflictPicker): Allow to use FileSystemEntry by @ susnux in #1166
  • feat: Allow to upload directories and allow bulk upload by @ susnux in #1175
  • feat: Split new-menu entries into upload new and other by @ susnux in #1206
  • feat(ConflictPicker): refresh preview on etag change by @ skjnldsv in #1214

  Fixed

  • fix(ConflictPicker): Ensure component works also if browser does not support FileSystemEntry by @ susnux in #1171
  • fix(ConflictPicker): Allow to set recursive upload note + fix types for conflict utils functions by @ susnux in #1176
  • fix(docs): Add parameter docs for getUploader by @ susnux in #1207

  Changed

  • Updated translations
  • fix(tests): Add tests for filesystem helpers by @ susnux in #1174
  • fix: Refactor logger and fix badges in README by @ susnux in #1173
  • build(deps): Bump @ nextcloud/dialogs to 5.3.1
  • build(deps): Bump @ nextcloud/auth to 2.3.0
  • build(deps): Bump @ nextcloud/router to 3.0.1
  • build(deps): Bump @ nextcloud/files to 3.2.1
  • build(deps): Bump @ nextcloud/l10n to 3.1.0
  • build(deps): Bump @ nextcloud/logger to 3.0.2
  • build(deps): Bump axios to 1.7.2
• 1.1.1 - 2024-04-15
  

  v1.1.1 (2024-04-15)

  Full Changelog

  🐛 Fixed bugs

  • fix: Drop dependency on moment.js by @ susnux in #1155
  • fix(upload): Do not read chunks into memory but just stream file chunks by @ susnux in #1153

  Changed

  • Updated development dependencies
  • Updated translations
  • Updated @ nextcloud/dialogs from 5.2.0 to 5.3.0

from @nextcloud/upload GitHub release notes

---

Important

• 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:

• 🧐 View latest project report
• 📜 Customise PR templates
• 🛠 Adjust upgrade PR settings
• 🔕 Ignore this dependency or unsubscribe from future upgrade PRs

[secure-code-warrior-for-github]

Micro-Learning Topic: Server-side request forgery (Detected by phrase)

Matched on "Server-side Request Forgery"

What is this? (2min video)

Server-Side Request Forgery (SSRF) vulnerabilities are caused when an attacker can supply or modify a URL that reads or sends data to the server. The attacker can create a malicious request with a manipulated URL, when this request reaches the server, the server-side code executes the exploit URL causing the attacker to be able to read data from services that shouldn't be exposed.

Try a challenge in Secure Code Warrior

[secureflag-knowledge-base]

Server-Side Request Forgery

Play Labs on this vulnerability with SecureFlag!

Description

Server-Side Request Forgery (SSRF) attacks are a type of security vulnerability wherein a malicious actor can manipulate a parameter on the web application to create or control requests from a vulnerable server. These attacks are often used by attackers to target internal systems that are inaccessible from the external network due to the use of a firewall.

The most common case is a server application that, to implement a feature, performs HTTPS requests to a third-party server. This request may be needed to: consume an Internet API, download a package or retrieve user information via a social account (e.g., Facebook, Gravatar). An attacker might abuse the feature to perform requests to another third party or profit from the server's privileges regarding the original third-party system (e.g., to exfiltrate data).

In essence, SSRF attacks exploit one of the foundations of robust security, trust, by exploiting existing trust relationships to escalate attacks from applications against other back-end systems or even the server itself.

Read more

Impact

A successful SSRF attack can enable a malicious attacker to escalate and laterally move their way behind the firewall in the back-end web server without restriction, leading to the potential full compromise of confidentiality, integrity, and availability of the application.

The fallout from attacks that have successfully executed SSRF as part of their toolkit will be as extreme as the amount of data at risk. In the case of the infamous 2019 Capital One hack, the numbers speak for themselves: the compromised data included names, addresses, phone numbers, self-reported income, credit scores, and payment histories, among other personal information belonging to approximately 100 million customers in the United States (that is roughly 1/3 of the population) and 6 million customers in Canada.

As with so many issues in security, human error undoubtedly played a part in the above example, as the genesis of the breach entry was a misconfigured firewall.

Scenarios

Usually, client web requests are performed through language functions that support defined classes of protocols, such as HTTP, and make their use very simple for the developer.

According to the way the vulnerable request is implemented on the server side, the attacker might be able to reach another website. An attacker can even change the protocol and, for example, use the file:// protocol, which is accepted by default in many cases, to read any file on the filesystem.

SSRF attacks remain quite powerful due to firewalls and network security; an attacker able to forge an arbitrary request through the server will benefit from the server's physical/logical position and the active firewall rules. A network resource that is invisible and forbidden to the attacker might be available when the request is executed from the server. A common example is a management server hidden to the outside world but allowed from the server, as it might manage its updates or monitor its usage.

Lastly, attackers can monitor the average elapsed time for SSRF directed to open TCP ports and compare it to requests directed to closed or filtered TCP ports. By submitting a fairly small amount of requests, an attacker can map the network and discover open and closed ports that could be the target of further attacks.

Prevention

If a list of permitted URLs is known, developers should implement a hostname or IP address allow list for the application. The URLs should never be validated against a deny list; this approach is prone to get easily circumvented using a number of well-known techniques.

Developers should disable unused URL schemas if HTTP and HTTPS are the only active protocols the application utilizes to make requests.

To reduce the risk of an attacker taking advantage of response data leakage, the developer must ensure that, when sending a request to another server, the raw response is never returned as-is to the client application.

When SSRF happens, the main defense-in-depth approach is to lower the trust in the server. This can usually be implemented through firewall rules at the inbound end (e.g., the other server receiving the request), but it's much harder to implement firewall rules at the outbound end due to the nature of TCP.

Testing

Verify that the application protects against SSRF attacks by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and that it uses allow lists for protocols, domains, paths, and ports.

• OWASP ASVS: 5.2.6
• OWASP Testing Guide: Testing for Server-Side Request Forgery

View this in the SecureFlag Knowledge Base