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
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