JonStratton
commented
4 years ago @diemol , Yes, I am fine with you using this code for demo in your community documentation (but please give me a heads up before you do). However, I would prefer if in giving credit, you avoid indicating that these method you listed as possible mitigating factors (network isolation, not uploading sensitive info to the node, etc) are not things I, the person calling attention to this, would consider fully mitigating these issues. A more realistic scenario wouldn't necessarily target a selenium node as an end goal for an attacker, but more likely it would be used as a possible pivot point by an internal attacker. Like to gain access to application dev / preprod network segments for example.
As this is a "by design" issue, it might be a good idea to turn the following features off by default in the configuration of a node. These could be turned on with additional configuration, and no doubt you could call out the additional risks when documenting these features.
- The ability send files from the node to the browser in the remote webdriver.
- The ability to turn off prompting of the saving of files on a node.
As for #1, to be honest, I'm not even sure why this is allowed on the node. I could understand a tester process uploading a file as part of a test scenario (which is what I was trying to do when I ran into this issue). But this feature in the web driver seems a bit absurd; pulling from the node itself. The test file would have to be copied to the server before the remote tester could work...
I understand design change are complex when you have a large user base. And of course its up your team how you want to move forward with this. I should note that I am moving forward as considering this as a vulnerability. I do plan submitting these examples, as well as a possible metasploit module, to exploit-db.com at some point in the future. If you want me to hold off on this until you've made the above defaulting changes (or some other changes); I am cool with that. Just give me a date.
diemol
Hi, thank you for creating the referenced issue and for bringing our attention to it.
We checked the example code you provided and executed it to understand better the use case and vulnerability you refer to. After sharing the results between the project committers, we see that the behavior you see is by design.
Uploading and downloading files is an inherent step in testing and therefore testing environments need to be flexible enough to allow it. It is clear that a Selenium Server (or a WebDriver server) should be placed in an isolated environment, where no access to production or sensitive environments is possible. We also point in the Selenium Grid documentation that it is a very bad idea and not secure to expose a Selenium Server to the internet.
Since security is always a very important topic for us, but we do not want to block the different use cases the community has for the Selenium Server, we think it would be a good idea to add your findings and code examples to the official Selenium Grid documentation, and with that, raise more awareness about the importance of securing the environment where the Selenium Server is running. Would you like to contribute to the documentation? Or would it be ok for you if we take your findings and code examples, give you credit, and put them in the documentation for the community?