Closed fabianospinelli closed 6 months ago
Thank you for reporting this issue! We currently do not have any sponsor to fund work for this correction. Since it only impacts enterprise users that require self-hosting, we will not prioritise correcting this problem on community funds. You're very welcome to open a pull request to correct this behaviour 🙂
My pull request has been accepted so I can close the issue. Thanks!
During our test on the Contribution-Tool (configured to answer on port 3000) we found that it is possible to use the server to interact with internal URLs. As you can see in the following example it is possible to reach internal resources, in particular when the application is used to reach a closed internal port it returns an ECONNREFUSED. URL used: https://localhost:80 On the other hand when the port is open and a service is available internally depending on the protocol the service is using it returns an error if as in the following image there is a mismatch of the protocol used: URL used: https://localhost:3000 Finally when it reaches it successfully in case the protocol is correct: URL used: http://localhost:3000 In this way, a malicious user can interact with internal resources to discover and develop new attacks against internal components. It is possible to modify the tool in order to block the local URLs (localhost, 127.0.0.1, etc.)?