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

[JhayceFrancis]

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

ℹ️ 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 5 versions ahead of your current version.

• The recommended version was released on 24 days ago.

Issues fixed by the recommended upgrade:

	Issue	Score	Exploit Maturity
	Regular Expression Denial of Service (ReDoS) SNYK-JS-FASTXMLPARSER-7573289	49	No Known Exploit

Release notes

Package name: @nextcloud/upload

• 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

[secureflag-knowledge-base]

Lack of Resources and Rate Limiting

Play Labs on this vulnerability with SecureFlag!

Description

Whilst the internet may often seem as though it were boundless, it is still bound by a finite amount of computing resources and subject to limitations, with only so much bandwidth, CPU processing power, memory allocation, and storage to go around. At the individual level, for example, think of the last time you tried to spin up that third virtual machine while the host browser was feverishly feeding your multiple open tab habit... resource limitations in action! And although this illustration depicts a non-malicious - indeed, self-imposed - consequence of overload for an individual laptop, there are, unfortunately, attacks that leverage resource and rate limitations of web applications and APIs that have not been configured correctly.

Application requests are pretty much what make the internet the internet, with some estimates suggesting that API requests alone make up over 83% of all web traffic. Applications perform day-to-day functions adequately when the request parameters governing the numbers of processes, size of payloads, etc., are set at the appropriate minimums and maximums. However, when the aforementioned resources are incorrectly assigned, applications are not only subject to poor or non-existent performance, but they can also be commandeered by malicious actors to disrupt and deny service.

According to OWASP's API4:2019 Lack of Resources & Rate Limiting post, APIs, for example, are vulnerable if even just one of the below limits is lacking or incorrectly set:

• Execution timeouts: the API gateway will wait a certain number of seconds for the endpoint to return a response... this value can be anywhere from 1 second to many years' worth of seconds, so it is important to define correctly.
• Max allocable memory: the maximum amount of memory allocated to the API.
• Number of file descriptors: the more files opened for your process, the more labor-intensive.
• Number of processes: the more processes, the more labor-intensive.
• Request payload size (e.g., uploads): the larger the upload, the greater the consumption.
• Number of requests per client/resource: this could be 100 requests per 100 seconds per user but also 1000 requests per 100 seconds per user - 10X the load.
• Number of records per page to return in a single request-response: stuffing more records into a single response will naturally degrade performance.

Bottom line: set one of the above too low or too high, and your application is at risk.

Read more

Impact

Whatever the type of application, inadequately configured resource allocation, and rate limits are routinely targeted by attackers. Attacks such as these undermine reliability and availability of entire ecosystems, inevitably resulting in financial and reputational loss.

Scenarios

Suppose an API is tasked with the retrieval of user-profiles and their corresponding details, providing, as most APIs do, access to its resources that take the form of lists of entities. A set limit of returnable items would typically confine a client filtering this list.

www.vulnerableapp.com/api/v1/get_user_list?page=1&size=9000000

An astute observer will have noticed that the request here would return page 1 and the first 9000000 users, which certainly seems like an above-average number of users for just one page! This attack would succeed to overwhelm the API if the size parameter was improperly validated.

Prevention

Attacks targeting application misconfigurations that allow unbridled resources and limits are common - the exploitation is uncomplicated and requires minimal resources to execute. Fortunately, robust defense is reasonably straightforward to implement so long as attention is paid to limits that dictate finite resources, i.e., the abovementioned CPU processing power, memory allocation, number of processes and file descriptors, etc.

Prevention strategies include:

• Limiting the number of times a client can call an application within a given timeframe.
• Setting limit numbers and reset times and communicating them with the client.
• Ensuring query strings and request body parameters are properly validated by the server.
• Place a limit on the data size of incoming parameters and payloads.
• For any application, adhere to best practices laid out in the configuration guidelines. For example, APIs moored in the overwhelmingly popular Docker need only review and adequately implement appropriate configurations for memory resources, CPU, restart policies, and container ulimits (limits for file descriptors and processes).

Testing

Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever-increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar.

• OWASP ASVS: 2.2.1
• OWASP Testing Guide: Testing for Weak Lock Out Mechanism

References

Akamai - State of Internet Security

OWASP - API-Security

CloudVector - OWASP API Security

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