On 08/27/2013 09:41 PM, Dirk Müller 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.

And there's the X-CSRFToken HTTP header.

given that the latter is largely inconvenient, CSRF cookies is the de-facto standard used by most web frameworks.

Well, not really. It is true that people often forget to add the CSRF token to their forms when they write them by hand. That's why form generation frameworks for major web frameworks are so handy. But form values are mostly annoying with AJAX POST requests for which everybody has his personal hack [1]. BTw. it's actually the default method in both Rails and the Django communities. And surprise, surprise, even Horizon does that: % grep -r csrf_token . --exclude-dir=.venv --exclude-dir=.tox ./horizon/templates/horizon/common/_workflow.html:

Followup for archival purposes, I have been able to get Lynx working by forcing acceptance of untrusted cookies in the Lynx configuration. so it's available as a troubleshooting tool. This may be a new requirement using certain web browsers... especially text browsers when accessing Grizzly moving forward(was not a problem in Folsom). Uncertain at this time if the authentication error that's returned is a separate openstack configuration error unique to this instance or another consequence of CSRF but I'm leaning heavily to the former is (not related to CSRF). Tony On Thu, Sep 5, 2013 at 10:25 AM, Tony Su wrote:

Hello,

I wasn't actually planning on extending this discussion but I think for the benefit of those who don't spend all their time thinking about stuff like this, for their benefit I think I can speculate a bit on the likely origins of this CSRF cookie and why it's what it is and why I <still> think it was a poor decision to implement in the first place.

Others can certainly disagree... And I wouldn't expect that anyone who has committed to using the CSRF cookie will change to something else because it should work when the browser supports it...

It starts with what CSRF is, the security issue it represents and then ends with what cookies are used for.

I'm relying on the Wikipedia description (en.wikipedia.org/wiki/Cross-site_request_forgery)

Whereas the more commonly discussed XSS issue exploits mis-using trusting the website, CSRF attempts to exploit mis-use trusting the client machine (fooling the website when the client is someone else).

The example in the Wikipedia article is very basic, nowadays no one should be passing security credentials in the URL (which can be copied and run from another machine) but it illustrates the idea. I myself was working for a meta-search company for pharm products 10 years ago and found that if we didn't scrub the URLs (or tell the companies to use another method) anyone other than the original, authenticated User could click on a search result and instantly be logged in with someone else' credentials.

So, it <is> a valid real world issue although typically today "Best Practices" and "Proper App Design" renders the issue practically gone but it does require understanding how authentication works and recommended ways to implement. Web Frameworks usually store and pass credentials properly so the problem should never be an issue when using one although the CSRF cookie by far is not the only way to do this.

I've mentioned one way to avoid this problem (just don't pass credentials in an easily accessible form).

But, just for argument's sake let's raise the bar a bit... You want to positively identify the User, not just protect the connection and for this there are numerous alternatives, eg 2-way SSL, and various solutions storing tokens in a Server database and on the Client with every choice having its own pros and cons.

Without making this a longer message describing the options (anyone should be able to research), I just want to look at the choice Django (and maybe Ruby) has made... Using the CSRF cookie.

Cookies are attractive in that it's a widely accepted technology that <when used properly> because they are publicly visible - Does not(or should not) contain sensitive Personal Information - Provides a simple means for a website (even farm) to recognize a client even across different sessions - Supports sessions across occassionally connected sessions - Can contain parameters (avoiding Personal Information)

So, a lot of people are in love with cookies. But, Recommended Practice says you shouldn't use it for Security purposes. What to do? Instead of implementing a recognized proper alternative, someone decided to create a Special Cookie with special features that addresses the shortcomings and issues using a Common Cookie - To make the Cookie Personal, it has to be tied into what the Original User is using, so the web browser was chosen as the most agnostic, easily modifiable and fast evolving part of the Client-side solution.

A perfect example of forcing a round peg into a square hole.

BTW - regarding text browser alternatives in this case, if javascript is the issue then I think "links" also does not support but believe "elinks" and possibly w3m might work.

IMO and thx all., Tony

On Fri, Aug 23, 2013 at 12:41 PM, Tony Su wrote:

...

I've never personally been a fan of Django despite its popularity among Python coders...

Seems I can't run Lunx against the web dashboard now (Grizzly) because it's possible that Lynx doesn't support CSRF cookies properly. I have Lynx accepting all cookies but there still seems to be a problem and the Dashboard is rejecting Lynx requests accordingly.

With a little research, it appears that this has been a major problem with Django since approx 2009 when this first appeared and of course in someone's great wisdom made it impossible to 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).

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.

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