11 ms·
There's almost no hack needed here, as the article says, they basically opened up remote code execution to anyone. That's shockingly bad.
by theintern 11y ago
There's almost no hack needed here, as the article says, they basically opened up remote code execution to anyone. That's shockingly bad.
- the_mitsuhiko 11y agoMakes 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.
- andy_ppp 11y agoIt 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!
- xorcist 11y agoMistakes 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.
- mahouse 11y ago>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.
- gozo 11y agoCommand 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.
- the_mitsuhiko 11y ago> 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.
- jzd 11y agoNot true. For example nginx can use the proxy_pass directive to forward real IP address information and log it
- the_mitsuhiko 11y agoThe 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.
- gozo 11y agoI 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.
- the_mitsuhiko 11y agoI 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.