Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am coding a REST web application that runs on Google App Engine, it authenticates API requests to privileged data using sessions by cookies provided by webapp2_extras.auth and webapp2_extras.security.

The entire site and all points use HTTPS.

Webapp2 runs in a "request context" which I believe means each request that comes through has its own thread, but I am wondering something that is probably quite code specific and even if I dug into the code to understand, I'm not sure I would be capable of putting all my fears to rest, hence I am asking here.

The situation is : I rig the http PATCH request to "batch" requests to PUT,GET and DELETE methods to save on client-server roundtrips. If say the client has a lot of objects to save to the server, it can make a PATCH with the jsonified list of "sub" requests to

/user/dame_edna/objects

And the patch will iterate that list and then make in-app requests to the different points, for example one request might be :

method:delete point:/decorative_fans/small_dog_design

And the patch method will construct a webapp2.Request object which points to

/user/dame_edna/objects/decorative_fans/small_dog_design

It will fill in various fields (but, crucially for this question, not the cookie or auth fields), and then it will instantiate the request handler, in this case,

user.objects.decorative_fans.crud.responder

and execute that request in the application, without a client-server round trip

Here is where I get lost and what I find interesting :

The cookie field of the new request is blank, but the request somehow knows about the auth token and session of the originating request. Notice that the original PATCH request came to /user/dame_edna, and to even make that PATCH request here we needed to have a session that was authenticated for user "dame_edna", but my concern is -- how do the subrequests that I make in the application know that they are verified as "dame_edna" ?

But they do. I dumped the auth token for the DELETE request, and it came up as the same auth token that authenticated, say, dame_edna to the original PATCH request, even though I did not copy or set it in any way

It seems weird to me that webapp2 would copy across these authentication fundamentals, or that they would simply become accessible to the newly created Request object, since creating Requests in-app like I did is, according to the docs, mostly used for unit testing.

I want to clear up any doubts about this before I move forward with the application, since it's a pretty key area I don't want to mess it up, and I can't ignore it without knowing exactly what's going on.

Help is appreciated for an explanation of how the sub, in-app request knows about the original, HTTP requests authent state, and whether using sub-requests in this way is going to be as "bulletproof" as the original signed sessions provided by webapp2_extras

share|improve this question
    
I don't understand the question. If, as you say, this additional request is in the application, then what's to stop it accessing global registers of the main (or same?) thread that were filled with the initial request that did include session data in the request headers? I'm not sure what's being asked here. Is it why is any new request object created within the same web application's instance linked with the session data of the original request?. If so, then the answer is probably that you're creating a subsequent request object as the child object of the initial request ( = inheritance). –  TildalWave Apr 21 '13 at 20:58
    
It's not a childclass of the initial request. It goes back to the webapp2 module and webapp2.Request.blank(path=...) is called. I don't understand how the information comes across, and because it's not clear, I'm worried it might break, or not be secure. –  Cris Stringfellow Apr 21 '13 at 21:39
    
The declaration of the Request class starts at the line 114 of webapp2.py‌​. I'm not too familiar with webapp2, or Python for the matter, but the way I read it class method blank creates a new instance of the superclass and fills it's environ with the POST request data (lines 273-285) or empty, if it wasn't created on POST request (data = kwargs.pop('POST', None)...). If that's true, it does seem to be a reason for concern you can leak original request data in a new request. You could create a new class handler tho –  TildalWave Apr 21 '13 at 22:39
    
Okay, thanks I'll have a closer look at the code and may make some changes to my question. –  Cris Stringfellow Apr 22 '13 at 3:25
2  
Could I bother you for a status update on this issue you're presenting? It's been awhile since your last comment and the question still doesn't have a proper answer. If Webapp2 is really written to default to transparent proxying requests, then this is clearly a case for concern, and an answer about it might help someone else, too. Thanks! –  TildalWave Jun 7 '13 at 22:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.