Am Freitag, 4. Juli 2014 11:05:49 UTC+2 schrieb cornelius:
>
>  
> Am 04.07.2014 10:21, schrieb Torsten Irländer:
>  
>  As I did not wanted to keep track on synchronizer tokens on the server 
>> side, the original web application read the session cookie from the browser 
>> and added the this token as parameter for the further requests. Thus the 
>> server only needs to compare the cookie and the parameter.
>>  
>
> Ok, and how did you add this token as parameter the further requests? Did 
> you enhance the url generation in Pyramid?
>  
> Hi Torsten,
>
> this might all be rather unorthodox: This was handled by javascript stuff, 
> that reads the cookie. My web application had a bunch of javascript!
> Of course this would not work in a web application, that does not use 
> javascript.
> Then you might need to track the synchronizer token on the server side... 
> (see 
> https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#General_Recommendation:_Synchronizer_Token_Pattern
> )
>
> Hm, my solution is really an old, expanded web app, that needs some code 
> cleaning ;-)
>
 
Hi Cornelius, 

Thanks for the reply. JS might be an option for me as my application 
requires JS to work properly anyway. However I would like to implement this 
at the time of the URL generation on the server side. Maybe I will try my 
first idea using some kind of wrapper around pyramids url generation 
methods... if i finally decide to implement CSRF protection on GET request 
:)
 

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Reply via email to