> Unfortunately, it is a security risk. flash is currently implemented > as a cookie, and a malicious client could send a carefully crafted > pickle that can execute arbitrary python code. (This is the very same > reason why SerialCookie and SmartCookie in the Cookie module of the > standard library are deprecated.)
According to the Python 2.4 Library documentation: (http://www.python.org/doc/2.4/lib/node66.html) """Note that functions (built-in and user-defined) are pickled by ``fully qualified'' name reference, not by value. This means that only the function name is pickled, along with the name of module the function is defined in. Neither the function's code, nor any of its function attributes are pickled. Thus the defining module must be importable in the unpickling environment, and the module must contain the named object, otherwise an exception will be raised.""" Similar limitations hold true for classes. Executable code, say uncompiled Python or Python bytecode, is not pickled or unpickled as such. Thus, we determined the risk to be exceedingly small. The risk is further reduced by the lack of exec() statements in the tg_flash handling code. Also, I've added a small checksum to the cookie to help prevent spoofing, for whatever reason someone may. > Never mind, I made a patch that avoids cookies, and thus the security > risk. My patch lets you use arbitrary objects with flash. I need my flash messages to survive sometimes multiple requests. Though I do occasionally return the result of another exposed function, this is rare. - Matthew
