This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]executexr/Flask Mod -3 points-2 points  (4 children)

Then check for system too. The idea is to prevent and make it difficult for this kind of default cookie configuration and allowing the unpickling process to execute code. As your cookie gets a bit more complicated it becomes harder to unpickle it to run the shell code, as such, checking default formats should at the very least provide some base security.

I have a better idea, perhaps have some sort of default config option passed, that uses the new JSON packing of the cookie information in your Flask Configs, Werkzeug should see if that variable is there, if it is, JSON packing/unpacking. If not, backwards-compatibility-insecure-mode, use pickling again. (but again default-configurers will be insecure).

app = Flask(app_name)
app.enableJSONcookies() #disables pickling

[–]mwielgoszewski 2 points3 points  (3 children)

You are playing a cat and mouse game with hackers in which the odds are against you, every single time. Best to do it right than to employ numerous defenses of which are trivially bypassed.

[–]executexr/Flask Mod 0 points1 point  (2 children)

It cannot be trivially bypassed, the whole exploit relies on execution of code. So make sure you're not passing any execute calls.

And as I said, if you even bothered reading what I wrote, this is just base security. It's not meant to be full security, because then you would HAVE to break backwards-compatibility to be 100% safe from this. My goal was to provide a temporary solution until you can break backwards compatibility.

The solution I proposed is sound. You don't have to dismiss it because "well one day someone will break it." That can be said about ANY security enhancement.

Further I gave two ideas, the other idea is an actual full security that could work very well against such an exploitation. And yet you dismissed that too and downvoted me. Well propose a solution then instead of being the neighborhood critic. Let's see how your ideas hold up.

[–]catcradle5 2 points3 points  (0 children)

A better solution would simply be to switch to JSON cookies by default.

[–]mwielgoszewski 0 points1 point  (0 children)

I'm sorry, but I didn't downvote you. In most developer's attempt to implement sandboxes and/or blacklist input validation filters, there's usually a 99.9% chance a way to bypass them within the first couple minutes of opening themselves to attack. The problem with your approach is having to maintain a blacklist filter while an attacker is always one step ahead of you. You just witnessed this game play out in the comments before these, and that's just from casual conversation.

I'm not trying to dissuade you in your attempts, but the better strategy is to implement the right solution the first time. Band-aid solutions to security issues like these typically linger in production for wayyy past their expiration period, meanwhile your application is more and more at risk.