---------- Forwarded message ---------- From: Tony Su <tonysu@su-networking.com> Date: Wed, Sep 4, 2013 at 11:11 AM Subject: Re: [opensuse-cloud] Aaagh! - OpenStack Grizzly Django CSRF $&#!! To: Dirk Müller <dirk@dmllr.de> Cc: openSUSE Cloud ML <opensuse-cloud@opensuse.org> Thx Dirk for the response and offer. In this case though, I'm pessimistic how much can be accomplished with minimal effort... From what I can gather, the CSRF implementation is using cookies which requires some kind of special browser support. My personal feeling is that this is an "extended" use of cookies which IMO is a mis-use of cookie use in general but I can see would be attractive. Maybe this special functionality is built into "modern" browsers universally, but in at least Lynx it isn't so maybe I'll need to look at some other text mode web browsers. If what you say is true that it's the de facto standard CSRF implementation used by most web frameworks, I wouldn't be surprised but would be disappointed in the general use of cookies. But, this is my first experience where Lynx has failed, maybe its requirement is not so universal yet. Tony On Tue, Aug 27, 2013 at 12:41 PM, Dirk Müller <dirk@dmllr.de> wrote:

Hi Tony,

...

disable/uninstall/neuter this "feature." Also, I cannot find any other web framework which uses this approach to fighting XSS attacks (and AFAIK the XSS problem has been mostly addressed by practically everyone in some way).

Please note that XSS and CSRF are two completely different things. I assume from your description that you're indeed talking about CSRF. There are indeed two ways to implement CSRF protection in django, using cookies or using hidden form values using POST. given that the latter is largely inconvenient, CSRF cookies is the de-facto standard used by most web frameworks.

I assume there is something wrong with the specific way the cookies are set though or of some specific incompatibility.

...

I'm not seeing this problem using other web browsers, although I'm in the process of determining if the <same> problem I ran into in Folsom using the Quickstart script still exists in Grizzly (initial appearance is the same although too early to be sure) about not setting up the keyring properly for SSL certificates. If I do determine it's the same problem, then it's almost certainly a problem with the SUSE/openSUSE build since I never saw the problem in Devstack 6 months ago and didn't see the problem on a RH which was configured with their Quickstart last night.

That might very well be the case. if you could share the details of this problem we could be looking at what our setup scripts are doing wrongly.

Thanks, Dirk

-- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org