Repository navigation
Conversation
4fd999a to
97cb572
Compare
| if (normalizedIp != null && !isPrivateIp(normalizedIp) && !config.contains(normalizedIp)) { | ||
| return normalizedIp; |
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
004d59e to
3ac374b
Compare
3ac374b to
bbd54fa
Compare
| if (List.of("true", "1", "yes", "y", "on").contains(value.toLowerCase(Locale.ROOT))) { | ||
| return new BooleanConfig(true); |
There was a problem hiding this comment.
🟡 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.
| 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.
No description provided.