http://sentry.dmz.phx1.mozilla.com/addons/marketplace/group/13988/ It looks like in session_csrf the key ends up looking something like this: "|dir; carrier=telefonica; multidb_pin_writes=y; sessionid=" and memcache doesn't like it, which means it's not going to get cached.
Andy: do you know anything about this bug? It came up with something you did with the API. These are really weird keys. If we actually need them we should be hashing them?
Priority: -- → P2
Acunetix-Product WVS/8.0 (Acunetix Web Vulnerability Scanner - NORMAL) Acunetix-Scanning-Agreement Third Party Scanning PROHIBITED Acunetix-User-Agreement http://www.acunetix.com/wvs/disc.htm
Summary: MemcachedKeyCharacterError: Control characters not allowed → [traceback] MemcachedKeyCharacterError: Control characters not allowed
Looks like this is a web vulnerability scanner. I don't think there is a security issue here but we should fix the crash. Definitely shouldn't be passing user data into memcache keys.
Looks like the literal key is being sent to memcache via django-session-csrf. https://github.com/mozilla/django-session-csrf/blob/master/session_csrf/__init__.py#L60 Should this be hashed/base64ed?
Well, I don't know that there is a security vulnerability there, but just as a general rule of thumb I would hash or encode it, yeah. Maybe we should file a bug against django-session-csrf to see if they considered that? At a minimum we shouldn't crash here (try/catch).
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.