[
https://issues.apache.org/jira/browse/KNOX-3039?focusedWorklogId=922351&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922351
]
ASF GitHub Bot logged work on KNOX-3039:
----------------------------------------
Author: ASF GitHub Bot
Created on: 06/Jun/24 14:02
Start Date: 06/Jun/24 14:02
Worklog Time Spent: 10m
Work Description: kardolus commented on PR #914:
URL: https://github.com/apache/knox/pull/914#issuecomment-2152623061
@moresandeep @pzampino Now that we made the pattern configurable, I am
wondering if it should be an array. I mean, now that you can create patterns
for [IP
addresses](https://github.com/kardolus/knox/blob/e11912a281eb33f497329eaf397a4419216ed751/gateway-server/src/test/java/org/apache/knox/gateway/GatewayServletTest.java#L44),
[email
addresses](https://github.com/kardolus/knox/blob/e11912a281eb33f497329eaf397a4419216ed751/gateway-server/src/test/java/org/apache/knox/gateway/GatewayServletTest.java#L45),
and [credit
cards](https://github.com/kardolus/knox/blob/e11912a281eb33f497329eaf397a4419216ed751/gateway-server/src/test/java/org/apache/knox/gateway/GatewayServletTest.java#L46),
the question arises: why not just hide all three? But on the other hand, this
does feel a bit over-engineered in my opinion. Also, we could do this in a
later iteration. Do y'all have an opinion on this?
Issue Time Tracking
-------------------
Worklog Id: (was: 922351)
Time Spent: 3.5h (was: 3h 20m)
> IP Address Exposure in HTTP 500 Error Message
> ---------------------------------------------
>
> Key: KNOX-3039
> URL: https://issues.apache.org/jira/browse/KNOX-3039
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Reporter: Guillermo Kardolus
> Priority: Major
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> A potential security vulnerability has been identified in Apache Knox where
> internal IP addresses are exposed in HTTP 500 error messages. This issue can
> occur when a user modifies the URL for one of the proxy services, leading to
> an error page that includes the IP address of the internal service.
> *Steps to Reproduce:*
> # Navigate to a proxy service URL, for example:
> {{<[https://example.com:8443/gateway/proxy/service?scheme=https&host=example.com&port=8051]>}}
> # Modify the {{port}} parameter to an invalid port, such as:
> {{<[https://example.com:8443/gateway/proxy/service?scheme=https&host=example.com&port=9999]>}}
> # Observe the resulting HTTP 500 error message which includes the internal
> IP address.
> *Observed Behavior:* The error message reveals the internal IP address in the
> stack trace, which can be used by an attacker for port scanning and other
> malicious activities.
> *Example:*
> {code:java}
> HTTP ERROR 500 java.io.IOException: java.io.IOException: Service connectivity
> error.
> MESSAGE: java.io.IOException: java.io.IOException: Service connectivity error.
> ...
> CAUSED BY: java.io.IOException: Connect to example.com:9996
> [example.com/10.140.190.10] failed: Connection refused (Connection refused)
> ... {code}
> *Expected Behavior:* Error messages should not expose internal IP addresses.
> Instead, they should be sanitized to prevent the disclosure of sensitive
> information.
> *Proposed Solution:*
> # *Sanitization Mechanism:* Implement a mechanism to sanitize error messages
> before they are sent to the client. This can include replacing IP addresses
> with placeholders such as {{{}[hidden]{}}}.
> # *Configuration Options:* Provide configuration options for users to enable
> or disable this sanitization based on their security needs. By default, users
> should opt-in to this new sanitization functionality, with an option to
> opt-out if necessary.
> # *Knox-specific Error Page:* Alternatively, consider implementing a
> Knox-specific error page that displays an error message without revealing any
> sensitive information.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)