Open dorneanu opened 7 years ago
Roadmap:
bottle.cookie.serializer
config option that default to pickle
.depr()
if said config value is pickle
with a hint that json
should be used instead.bottle.cookie.serializer
default to json
pickle
serializer.Alternatively we could also introduce a Request.session
variable that persist to json-cookies by default but can be extended to persist to disk via plugins, then phase out the secure-cookie functionality completely.
Pull requests are welcome.
Add a way to declare own serializers on an application.
Do you have some code example how you'd implement that?
Good question. Perhaps we should just hard-code the json/pickle variants for now and decide based on Request.app.config['bottle.cookie.serializer'] == 'json'
which one to use. If there is really a need for pluggable serializers in the future, we can still think about a better mechanism.
Configuration on a per-app basis is always a good idea (you might want to mount a legacy app that uses pickle, next to a new app that uses json) but adding new serializers is something that can be global for all applications (as in: module space functions). Just be careful with adding any 'public' APIs (eg. functions not starting with '_' and appearing in the docs) because then it's hard to change them later.
I changed my mind. New Roadmap:
👍
Hi,
during a pentest of a Bottlepy based application, I've noticed that when using signed cookies,
cookie_decode
is being called:When the hash value of the cookie data is valid,
pickle.loads()
gets involved. An attacker could therefore build a cookie value like this:In this case
build_exploit()
will return a base64 encoded serialized string (hash value + serialized class) which will trigger the execution ofos.system("ls")
when being deserialized (pickle.loads()
).You should definitely avoid using
cPickle
and use some JSON based alternatives for the serialization job.Best regards, Victor