| Subject: | Minor design security problem with module workflow |
Recommended workflow with this module is:
====
my $request_token = $consumer->get_request_token(
callback_url => q{http://yourservice/callback},
);
$your_app->session->set( request_token => $request_token );
====
$request_token is the object of class OAuth::Lite::Token.
It is the problem to serialize that kind of objects to sessions, because it cannot be really secure in Perl.
Here is why:
Example of module that can serialize OAuth::Lite::Token is Storable. There is security problem with storable: https://metacpan.org/pod/Storable#SECURITY-WARNING
===
Finally, the deserialized object's destructors will be invoked when the objects get destroyed in the deserializing process. Maliciously crafted Storable documents may put such objects in the value of a hash key that is overridden by another key/value pair in the same hash, thus causing immediate destructor execution
===
Other modules for serialization are: Sereal, JSON::XS, CBOR::XS - the only reason they don't have security problem with destructors (like Storable does) is that they require module user to have methods FREEZE and THAW for classes, that are allowed to be serialized/deserialized. This is like "white list" of classes which can be deserialized, those classes should be with safe destructors.
And for your module user cannot (let's don't account hacks) inject methods FREEZE and THAW, thus cannot use "safe" deserialization libraries.
I suggest that there should be different workflow where only token(s) saved in sessions (one perl scalar, not object) to avoid this problem.
p.s.
Of course session data is not available for site users to inject data, but security problem still exists, because attacker can hack one server, then inject data to session store and this way hack to other servers.