Hacker News Reader

Comment by theintern | Hacker News Reader

There's almost no hack needed here, as the article says, they basically opened up remote code execution to anyone. That's shockingly bad.

View on HN

Makes me wonder what can be done to prevent this from happening without making it a terrible experience from a user point of view. Maybe the solution would be to store a password for the debugger and ask for it on first usage.

It said the guys name in the subdomain that this was available on. I can only imagine how that guy must feel, worst thing that I can imagine happening as a dev.

We've all made stupid mistakes and not paid a price as high as this!

Mistakes happens. But it should not be possible to put production data in publicly accessible systems by mistake. Not without committing a criminal offense, at the very least.

Your customer data is your customers' data. It's not yours to toy with as you please.

>Your customer data is your customers' data. It's not yours to toy with as you please.

That's the European point of view. In the US, customer data is nothing more than an asset.

Command line flag, environment variable or interactive prompt could help. Maybe the interactive shell should be enabled separately from debug itself, since some only use debug for the exceptions. It could also explicitly try to figure out if it's running in production mode by detecting WSGI, disabling setting app.debug in favor of app.run or when listening on 0.0.0.0 and if not block that make you use "public_debug" or whatever.

> explicitly try to figure out if it's running in production mode

Does not help. The cases I saw in the past were people putting Werkzeug's stuff behind ngrok, proxies, nginx in which cases it will all look like local requests.

Not true. For example nginx can use the proxy_pass directive to forward real IP address information and log it

The situation here is that people did not read the docs. Do you think they will start to read the docs for the proxy pass?

Aside of that, you cannot securely detect this because what it actually does is passing in a header which if not reliably set can be forged.

I wouldn't assume people didn't read the docs so much as they made a mistake deploying (part of) a development setup to production. Security isn't an all or nothing thing, it's about having a good chance of doing the right thing. I think having to explicitly enable the interactive part, something that isn't really standard either, would be sensible e.g. app.run(debug=True, debug_shell=True). At least that would make people even more aware and limit the potential of incidents to those who actually use the feature.

It's not exactly uncommon that people leak errors, remote code execution is another level though. It doesn't hurt to be careful with such a feature.

I implemented a pin based system now. It prints a PIN on first usage in 8 hours to the terminal and you need to enter it to unlock the console. This is IP bound.

It's still only a way to prevent greater damage, you should still not run the debugger enabled in prod.

Reply on news.ycombinator.com