Visitar URL original
Add proxy CIDR and hop trust with right-to-left IP selection by hansott · Pull Request #405 · AikidoSec/firewall-java · GitHub
Skip to content

Add proxy CIDR and hop trust with right-to-left IP selection - #405

Open
hansott wants to merge 1 commit into
mainfrom
proxy-cidr-hop-trust
Open

hansott wants to merge 1 commit into
mainfrom
proxy-cidr-hop-trust

Conversation

@hansott

@hansott hansott commented Nov 14, 2026

Copy link
Copy Markdown
Member

No description provided.

@hansott
hansott force-pushed the proxy-cidr-hop-trust branch from 4fd999a to 97cb572 Compare November 14, 2026 12:46
Comment on lines 39 to 40
if (normalizedIp != null && !isPrivateIp(normalizedIp) && !config.contains(normalizedIp)) {
return normalizedIp;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Medium - Fixed-hop mode accepts spoofed IPs beyond the trusted hop boundary

With AIKIDO_TRUST_PROXY set to a hop count, a request whose real client address is private can supply a public address in an older, leftmost X-Forwarded-For entry and have it selected. The parser starts at the configured hop boundary but then continues left while skipping private entries, so the spoofed value becomes the remote address used by IP allowlists, blocklists, and rate limiting.

Show fix

In fixed-hop mode, inspect only the configured hop position (or otherwise stop once the scan reaches the trusted-hop boundary); do not continue into client-controlled entries when that position is private or invalid. If the boundary cannot produce a usable address, fall back to the socket peer rather than accepting an older X-Forwarded-For value.

More info - Reply on this comment to give feedback or ignore the issue.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Partially fixed in commit 004d59e.

This issue remains because ProxyForwardedParser.extractIpFromHeader at agent_api/src/main/java/dev/aikido/agent_api/helpers/net/ProxyForwardedParser.java:37-40 starts at length - count for CountConfig but decrements through index 0 whenever the boundary entry is private or invalid, allowing an older public X-Forwarded-For value to be selected instead of falling back to rawIp.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Partially fixed in commit 3ac374b.

This issue remains because ProxyForwardedParser.extractIpFromHeader at agent_api/src/main/java/dev/aikido/agent_api/helpers/net/ProxyForwardedParser.java:40 continues scanning left after the configured count boundary and skips private/invalid entries, so a public older X-Forwarded-For value can still be returned; the PR's right-to-left hop selection is a partial fix attempt.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Partially fixed in commit bbd54fa.

This issue remains because ProxyForwardedParser.extractIpFromHeader at agent_api/src/main/java/dev/aikido/agent_api/helpers/net/ProxyForwardedParser.java:40-43 still iterates left from the hop boundary and skips private or invalid entries, allowing an older public X-Forwarded-For value instead of falling back to rawIp.

@hansott
hansott force-pushed the proxy-cidr-hop-trust branch 2 times, most recently from 004d59e to 3ac374b Compare November 14, 2026 12:51
@hansott
hansott force-pushed the proxy-cidr-hop-trust branch from 3ac374b to bbd54fa Compare November 14, 2026 13:00
Comment on lines +72 to +73
if (List.of("true", "1", "yes", "y", "on").contains(value.toLowerCase(Locale.ROOT))) {
return new BooleanConfig(true);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Medium - Truthy proxy settings unexpectedly enable spoofable forwarded IPs

When AIKIDO_TRUST_PROXY is set to on, yes, or y, this change now treats the value as enabling forwarded-header trust even though the existing BooleanEnv contract treated every nonempty value other than true/1 as false. On a directly exposed deployment using one of those values, a client can send an X-Forwarded-For address and have it used for rate limiting and IP allow/block decisions, allowing rotation of spoofed addresses to evade those controls.

Suggested change
if (List.of("true", "1", "yes", "y", "on").contains(value.toLowerCase(Locale.ROOT))) {
return new BooleanConfig(true);
if (List.of("true", "1").contains(value.toLowerCase(Locale.ROOT))) {
return new BooleanConfig(true);

More info - Reply on this comment to give feedback or ignore the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants