I could be wrong, and would love to be corrected, but storing the CSRF token in a session cookie doesn't seem problematic to me since the cookie should only be readable by your origin.
It would only become a concern of you started allowing cross origin requests with credentials.
As I read the documentation for SignedCookieSessionFactory, the data stored in the session is not encrypted. So storing a CSRF token in the session Cookie is not a good option. Pyramid_beaker seem to have been deprecated with release 1.5, so which options are the best for a site with very few actions requiring CSRF and other session data. My first thought is to pickle the session data, and storing them in a blob in the user database, but if there is something simpler and/or more elegangt available, I'd like to hear the alternatives.
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.
Right, it's just not maintained. If someone wants to maintain it,
they're free to pick it up. I wrote the original bindings but I
can't/won't maintain it anymore. The Beaker code itself has no current
maintainer, and I personally won't maintain bindings to something that
has no current maintainer. If someone else wants to do that, they can;
they'll also then become defacto Beaker maintainer, AFAICT.
This is what I use when I need server-side sessions. As far as I can
tell, the only folks for whom the Redis-only-backendedness might be a
problem are folks that run servers on Windows.
"sudo apt-get install redis-server" is pretty easy. Then you have a service on localhost listening to the default port, there's pretty much zero configuration required.
On Apr 24, 2014 7:39 AM, "Anders Wegge" <awe...@gmail.com> wrote:
>
> In the classic meaning of CSRF, you are right. But if javascript from a malicious site can get access to all cookies in the browser, it would be trivially simple to construct a XmlHttpRequest, that contain the correct CSRF token. While most browsers are sandboxing data, I do not want to rely on that.
At that point the browser is totally broken. I would think hard about whether this is really in your threat model.
As the class docstring indicates, the only contstraints on keys and
values are that they must be pickleable. If some sessioning
implementation does not provide this feature, it doesn't meet the
ISession interface (which doesn't mean it's not useful, it just means
it's not really in compliance). This would be a bug in an
implementation that aims to provide compliance. Were you running into
something that could not be pickled, or?
The reason there isn't a "session_id" API is because not all sessions
have an ID. For example, the cookie session stuff in the core doesn't
have (nor need) an ID, because there's no storage to need to look the ID
up in to retrieve the session data. Meanwhile, it's pretty simple to
put a random value into the session to act as an application-specific
ID. That's the rationale anyway.
Yeah, I dunno. We use buildout quite often to deliver a locally-running
system to nontechnical users and graphic designers. But we're also
committed to making sure that we build most everything from source when
it matters (e.g. sometimes redis, postgres, etc), so over time it
becomes less and less likely that the build won't work. I realize this
is a committment that not everyone is willing to make.
I don't remember what we were using, but some of the backend drivers we had at one point weren't using `Pickle`
client-side sessions don't have an id, but server-side sessions require it. because pyramid doesn't have an official interface to support this, all server side session libraries need to implement this themselves -- somehow -- to support it. I stress "somehow". There's no way to ensure or expect consistency in this across libraries. If you look at how different session providers in the ecosystem have dealt with this, there is little uniformity in approach. I've seen `session_id`, `_session_id`, `sessionID` and a few other variations -- both as attributes and internal dict values. If ISession had an official `session_id` attribute, then people developing server side libraries would adapt to that; there would be uniformity and portability. Those using client-side sessions would never use or expect a session_id , and not be inconvenienced.
By the way, thank you for keeping up with this discussion, I know
debating about things with folks who don't share your point of view can
get pretty boring and frustrating.
The presumption that there is a session.id variable won't solve this
particular problem, as Bert and Mike have already said. But as a
separate problem, it could be "solved" if we mandated that a session id
be made available in a common way in the cookie that represents the
session token across all implementations. This is a big ask, though, if
only because it means that folks who don't actually want to expose the
raw session id could not create an interface-compliant implementation.
In my experience, it also generally makes systems less flexible when you
begin to tell potential implementers how they must do things rather than
only telling them what they must do.
.....
Would the addition of session.id help here or does your stack have the
same problem where the session id must be discoverable outside Pyramid?
The issue is in not having a direct association between a "session object" and the "cookie value" which created it.A client-side session would always correspond to the incoming cookie value.A server-side session could be associated with a cookie value that appears in either the request or response cookies -- or neither in the case of multiple invalidations.There's simply nothing that ties the originating cookie value to a given session object.
Sure. It's always a tradeoff, though. If we over-specify the session
interface, it makes session implementers' lives harder, and may reduce
flexibility for consumers.
On May 5, 2014 6:00 PM, "Chris McDonough" <chr...@plope.com> wrote:
>
>
> This conversation seems to be going in circles a bit.
>
> Rather than debating the idea in the abstract, I'm trying to figure out how you, in particular, would actually concretely make use of "session.id" (or session.key or whatever).
>
> This question needs to be considered independently from:
>
> - being able to parse the key out of a cookie value "by hand". This
> is unrelated to having an API on the session object itself.
> Being able to do this is another topic which we need to
> consider independently.
>
> - being able to use the key as a lookup value into a sessioning
> implementation. There is currently no ISession API to pass the key
> to obtain information about the session, and adding such an
> API is yet another topic.
>
> Can anyone give me a concrete usage that's not solved by using a UUID key stored in the session data itself that does not involve the 2 constraints above?
I've been trying and the issue is that any such scenario is just about configuration.
For instance, if I were going to build some analytics module that shipped data off to be indexed I might include a session id. If I were to publish this as a package today I might use a setting to configure the key of this value in the session data. I would probably use a setdefault call with a uuid in a NewRequest subscriber.
But as soon as we have more than one such need, I'd be configuring each one and each one must implement this configuration code.
So the issue comes to when there is >1 included pyramid plugin that wants to uniquely identify the session without adding more items that strictly necessary.
My resistance to jumping in completely on the side of adding API has been that I don't like making anyone deal with a maybe-None return value and I don't like causing extra items to be stored in the session (cookie storage, in particular, should be kept small).
But this seems quite parallel to csrf token.
I would ask, if you were to redesign it today, would your ideal ISession interface have csrf methods or would you want all the code that uses it to check for _csrf_ key in the session and create a random one if it doesn't exist?
I imagine things like the check_csrf_token predicate would have an additional keyword for key were it not for an ISession API which makes it opaque.
At this point, though, I don't think I'm liable to add it retroactively, because it would mean that existing ISession implementations would fall out of compliance.
Note that there is no requirement currently that get_csrf_token store the token as "_csrft_" in the session itself (or that the *_flash methods store "_f_*" tokens). That's what the cookie-based implementation does, but it's totally up to the ISession implementer as to what they actually do, by design.
One compromise would be to add this function to pyramid.session:
def get_session_uuid(session):
""" Return the uuid associated with this session """
return session.setdefault('_uuid_', uuid4())
I'd consider doing that if it actually solved a concrete problem that someone has already run into.
which is why I keep badgering him to weigh in on this issue only.
All of the above use cases presume that you have visibility into the
session implementation's backend to load data. If you do, that's fine,
but there are no APIs in Pyramid that provide this functionality, so
you're already in implementation-dependent mode when trying to satisfy
any of them.
Having the ability to uniformly access a session's id
across ISession implementations buys you very little in these cases,
because you're already relying on implementation details that
necessarily go behind the back of ISession. You couldn't just swap out
one sessioning implementation for another, and expect these kinds of
tests or features to continue working, even if ISession did have an ID
API, right?
Server-side sessions are usually quite expensive. Personally I use them
very sparingly. Unleash "ab" against a page that accesses session data
and see. Definitely if all I needed was some tracking identifier, I'd
use a plain old cookie, if only to reduce CPU cycles on the server side.
In any case, without an actual in-the-wild use description of a required
feature that does not presume visibility into the session data backing
store or being able to parse the session id value out of a cookie, I'm
becoming more convinced that not requiring that an ISession implementer
expose the session id uniformly is actually correct. That doesn't mean
that session implementations can't expose it; pyramid_redis_session
sessions already expose the session id (as session.session_id, FWIW), so
you could rely on this implementation detail as easily as you're already
relying on the detail (at least if you use pyramid_redis_sessions) that
session data gets stored in redis. Relying on this would be no worse
than writing integration tests that check redis to see if the data
actually winds up there.
I'd be surprised. That'd presume the two implementations stored data in
the exact same way, which might well be the case, but can't be assumed.
If it didn't break, it'd only be by happy accident.
The other topic, at this point, is making it possible to uniformly parse
the session id out of the session cookie?
I'm still not sure how that would actually help you as much as you think
it would, given that if you change the session implementation, you will
already necessarily need to change code, or at least there's no
guarantee that things will "just work" when you swap in a random session
implementation given your description of the cases you want to support.
In the meantime, I'm pretty loath to make "interface suggestions": APIs
are really where the rubber meets the road. It's either in the
interface or it's not, and I'm leaning towards not.
That doesn't mean that you are out of luck, though. Have you thought of
this? It would require that you change code when you change session
implementations, but you already have to do that anyway.
On 05/08/2014 04:42 PM, Jonathan Vanasco wrote:
I understand this to mean (from your earlier emails, you don't expressly
say it above) that you want to be sure that there is a existing session
that has the id "123" if you parse "123" out of the cookie. Since we
can't stop browsers from sending cookie data, and since sessions have a
timeout (and as a result even a valid session id might not resolve to a
non-new session), I don't see how it would be possible to make that
promise due to the way the web works. The only implementation that
would have a shot at it would be purely cookie-value-based sessions,
because the value is stored in the cookie itself.
In any case, wrt black box magic, I'm sure you understand that the point
of an interface is to create a black box, such that one box can be
swapped for another by otherwise unconcerned consumers without the
consumer needing to open either box. Once you start dithering in the
interface definition about what's expected of implementations, it's
understandable that those implementations aren't going to be able to
satisfy the intent of the interface.
If the argument, instead, was "I want to be able to load session data using an arbitrary session id via a well-defined interface so I don't have to go look at any implementation details", I'd understand. But nobody has asked for that so far. Is it because it seems like a bridge too far, or what?