fix(security): rate limit web_fetch tool to mitigate DDoS via prompt injection

[mattKorwel]

Summary

This PR implements a rate limit for the web_fetch tool to mitigate a potential DDoS vulnerability via prompt injection, as reported in issue 1205.

Details

The fix introduces a rolling time-window rate limiter directly within the WebFetchToolInvocation class. It tracks the timestamps of requests made to each unique hostname. If the number of requests to a specific host exceeds the configured threshold (currently 10 requests per minute) within the time window, subsequent requests are temporarily blocked, and the tool returns a WEB_FETCH_PROCESSING_ERROR.

Additionally, the ToolCallEvent telemetry and CompletedToolCall scheduler types have been updated to include start_time and end_time properties, providing better visibility into tool execution rates and aiding in future monitoring. Some minor type cleanup in the scheduler logic was also performed during the investigation.

Related Issues

Fixes google-gemini/maintainers-gemini-cli#1205

How to Validate

1. Run the newly added integration test: npm run test:e2e -- integration-tests/concurrency-limit.test.ts
2. Run the unit tests for the web_fetch tool: npm test -w @google/gemini-cli-core -- src/tools/web-fetch.test.ts
3. Manually test by instructing the CLI (in YOLO mode) to fetch the same URL numerous times (e.g., > 10) in a single prompt and verify that the later requests fail with a rate limit error.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed)
• Noted breaking changes (if any)
• Validated on required platforms/methods:
  • MacOS
    • npm run
    • npx
    • Docker
    • Podman
    • Seatbelt
  • Windows
    • npm run
    • npx
    • Docker
  • Linux
    • npm run
    • npx
    • Docker

[gemini-code-assist]

Summary of Changes

Hello @mattKorwel, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical security vulnerability by introducing a robust rate-limiting mechanism to the web_fetch tool, safeguarding against potential prompt injection-based DDoS attacks. Concurrently, it enhances the system's observability by integrating detailed timing information into tool execution telemetry, allowing for more precise monitoring and analysis of tool performance.

Highlights

• Security Fix: Web Fetch Rate Limiting: Implemented a rolling time-window rate limiter for the web_fetch tool to prevent potential DDoS attacks via prompt injection, as reported in issue 1205. Requests exceeding 10 per minute per host will now return a WEB_FETCH_PROCESSING_ERROR.
• Telemetry Enhancement: Updated ToolCallEvent telemetry and CompletedToolCall scheduler types to include start_time and end_time properties, providing better visibility into tool execution duration.
• Scheduler Type Cleanup: Performed minor type cleanup within the scheduler logic, specifically adding peek() method to SchedulerStateManager and adjusting return formatting in checkPolicy.
• New Integration Test: Added a dedicated integration test to validate the new rate limiting functionality of the web_fetch tool.

Changelog

• packages/core/src/scheduler/policy.ts
  • Adjusted the formatting of the return object in the checkPolicy function for consistency.
• packages/core/src/scheduler/state-manager.ts
  • Introduced a new peek() method to the SchedulerStateManager class, allowing inspection of the next tool call in the queue without removing it.
• packages/core/src/scheduler/tool-executor.ts
  • Modified the construction of CompletedToolCall objects to include startTime and endTime for all tool call outcomes (successful, errored, cancelled).
• packages/core/src/scheduler/types.ts
  • Extended the ErroredToolCall, SuccessfulToolCall, and CancelledToolCall types with optional startTime and endTime properties.
• packages/core/src/telemetry/types.ts
  • Added start_time and end_time properties to the ToolCallEvent class.
  • Updated the ToolCallEvent constructors and toObject method to correctly handle and serialize the new start_time and end_time properties.
• packages/core/src/tools/web-fetch.test.ts
  • Added a new integration test case to verify that the web_fetch tool correctly triggers a WEB_FETCH_PROCESSING_ERROR when its rate limit is exceeded for a given host.
• packages/core/src/tools/web-fetch.ts
  • Defined constants for rate limiting, including RATE_LIMIT_WINDOW_MS (1 minute) and MAX_REQUESTS_PER_WINDOW (10 requests).
  • Implemented a hostRequestHistory map to track timestamps of requests made to individual hostnames.
  • Created a checkRateLimit function that determines if a request to a URL is allowed based on the rolling time window and returns the remaining wait time if rate-limited.
  • Integrated the checkRateLimit function into the WebFetchToolInvocation.execute method, causing it to return a WEB_FETCH_PROCESSING_ERROR with an appropriate message if the rate limit is hit.

Activity

• The author has added/updated tests to cover the new functionality.
• The author has validated the changes on MacOS using npm run.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[github-actions]

Size Change: +2.09 kB (+0.01%)

Total Size: 25.1 MB

Filename	Size	Change
./bundle/gemini.js	25.1 MB	+2.09 kB (+0.01%)

ℹ️ View Unchanged

Filename	Size
./bundle/sandbox-macos-permissive-open.sb	890 B
./bundle/sandbox-macos-permissive-proxied.sb	1.31 kB
./bundle/sandbox-macos-restrictive-open.sb	3.36 kB
./bundle/sandbox-macos-restrictive-proxied.sb	3.56 kB
./bundle/sandbox-macos-strict-open.sb	4.82 kB
./bundle/sandbox-macos-strict-proxied.sb	5.02 kB

_{compressed-size-action}

[gemini-code-assist]

Code Review

This pull request introduces a rate-limiting mechanism for the web_fetch tool to prevent potential DDoS attacks via prompt injection and extends telemetry to track tool execution times. However, it introduces a critical memory leak due to the unbounded growth of the global hostRequestHistory map. This vulnerability could be exploited by an attacker providing many unique hostnames, leading to a Denial of Service (DoS) through memory exhaustion. To address this, using an LRU cache to bound memory usage is recommended, aligning with existing repository conventions.

[mattKorwel]

validated after the first 10 parallel request, we receive a rate limiting error

[scidomino]

nit: could this be?

afterEach(async () => await rig?.cleanup());