Hacker News Reader

Comment by taeric | Hacker News Reader

I'm curious on what makes the security worse. The rest, I can see. Though, I have to confess I have been more critical of the whole headless browser binary push than I'd care to acknowledge. I just feel like this is solving a problem that didn't actually exist anymore. Selenium has worked solidly for quite a while. And, you almost certainly should test in multiple browsers/scenarios.

View on HN

The main security issues I know of so far are:

  - Neither Selenium nor Webdriver (at least the Python client, but I assume others too) support HTTPS at all.
  - By default it opens browsers configured to accept any SSL certificate. I can see why that's useful for local testing, but it's a terrible choice to default to.
  - It logs way too much. Logs every keypress sent to it, including passwords.

At least the latter two are fixable, but not trivially so, and better defaults with easy client-side options to opt into insecure mode would have been much better. The former is not fixable without patching both the client and server and in 2017 it's pretty poor to not even have an option for.

Odd, I'm pretty sure both of the first two are wrong. We used to have to make sure we had legit certs for selenium to work with https. That or configure the Firefox profile to have already accepted the self signed one.

And, really, the first two points are clearly contradictory. I'm guessing I just misunderstand what you mean?

Do you mean the communication between the driver? I'm curious why ssl would be important there? Should just be done locally and a standard ssh tunnel can help with any remote encryption you might want.

The first two are not contradictory, the first refers to communication between the client and server and the second to the browser's communication with a remote server. Maybe that wasn't clear from how I wrote it.

On further investigation, I think I was wrong on the second though; it might be that it's built into Chromedriver, not Selenium, which would explain why you didn't have the same issue with Firefox.

SSL between the client & Selenium server would be of benefit to keep any bad actor on the network from man-in-the-middle attacks on it. I'm not familiar with how I'd set up an ssh tunnel for that, I'm happy to believe it can be done, but it'd be a lot easier if it just supported HTTPS to begin with.

Apologies, I should have relaxed more of my verbiage. I was writing on my phone, and only about halfway through my post did it "click" what you meant.

HTTPS would be an odd choice, if only because I don't want to do any cert management for my selenium test runner. An encrypted channel makes some sense, but I'm not sure what the best mechanism for the shared secret would be. Ssh kind of gets you there, but is not as straight forward, as you ntoed.

Instead, I'd urge to keep the communication at localhost (or tunneled over SSH, at worst). Preferably with a locked down security model on the network so that you will see any traffic going off.

We both must be misunderstanding, because those first two points are blatantly false as far as I can tell. Selenium can handle(?) invalid SSL certs but the defaults certainly don't freely accept them.

As for the third point.. That's why we have DMZ's..

Reply on news.ycombinator.com