Item8798: Ongoing security review

An interesting paper discussing the merits of various authentication and user management strategies was published earlier this year.

http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf

The paper discusses some new directions in security that are not necessarily applicable; however it does so only after first describing the common weaknesses of various session management techniques, a number of which Foswiki uses. This section of the paper needs to be reviewed, and Foswiki audited for the weaknesses described therein. If we don't do it, you can be sure the bastard scum thieves will.

I have been through the paper myself, but as the implementor of several of the security mechanisms in Foswiki I'm not the right person to report on this audit - I know too much about how it works, and am probably blind to several holes as a result.

I really think this should be done before 1.1 is released, hence marking this as Urgent.

-- CrawfordCurrie - 30 Mar 2010

That is great read, will go over it properly at some point.

It has bothered me for a long time that our cookie url path is always '/', potentially exposing cookie values in a shared host environment (where the domain is shared) to other users of the hosting service (and perhaps other scenarios I haven't thought of).

Also HttpsRedirectPlugin should be reviewed to see if the secure flag is set when using https protocol Edit: it's not

And I think we don't set HttpOnly when accessing the wiki from http:// Edit: we don't Edit2: I meant to check that the Secure flag is set when accessing the wiki from https:// - it isn't

Also, SSLForNonViewScriptsOnly is clearly bad advice that I hope nobody has used. The motivation for writing that guide was to improve performance on IE6 browsers; that becomes less of an issue as time goes on, and expires_headers seems to solve most problems with SSL on other browsers. - Edit: appears to have been rewritten - C.

We should act on FoswikiOrgShouldUseSSL

Finally, I would be interested to discover to what extent their http digest auth advice can be implemented in Foswiki.

-- PaulHarvey - 30 Mar 2010

It has always bugged me since we first added TemplateLogin that the password is sent in URL params in plain text, same as basic auth. Given that we have an (HttpOnly) session cookie sitting there, it would be easy enough to add a fragment of JS that uses that as an encryption key, similar to digest auth. The JS would clear the plaintext PW param and add an encrypted_pw param in place of it. That way the server would know to unencrypt the pw using the session id as the key.

• Re-reading docs regarding the HttpOnly flag - isn't the whole point that it's protected from client scripts? - PH

Outstanding points:

1. Parameter validation has been poor; we have dealt with this by enabling taint checks in unit tests, and being much more aggressive about taint checking in the store. This prevents tainted data leaking onto the command line, where it can do damage.
2. The cookie URL path is /
   • C.: This could be defaulted to {ScriptUrlPath} I suppose. Any other views? Not sure what happens when URL rewriting is used. What additional protection would this give us?
   • See also ExpertOptionForCookieDomainRealm and Tasks/Item8560 for the configurable Cookie realm. -- GeorgeClark - 01 Jun 2010
3. PH asserts that HttpOnly used only when using https
   • AFAICT it's always used on the session cookie - see Foswiki::LoginManager.pm:808 - C.
   • I miswrote; my concern was with the lack of a secure flag on sessions over HTTPS. HttpsRedirectPlugin needs to work with Foswiki core to ensure that auth'd session cookies are never leaked over HTTP. This means a new session after auth, with the secure flag set on the session cookie - PH
4. We should act on FoswikiOrgShouldUseSSL
5. Can we implement their http digest auth advice?
6. Would TemplateLogin password encryption be useful?

-- CrawfordCurrie - 01 Jun 2010

I added a note regarding cookie flags. It wasn't so much HttpOnly; rather, that the secure flag is not set when Foswiki is accessed over HTTPS. And so if/when a user clicks a http:// link, they leak their cookie values in plaintext traffic.

We have a challenge here, which is that HttpsRedirectPlugin can't recycle the old cookies that were being used over http:// when promoting a to an auth'd, https:// session.

-- PaulHarvey - 05 Jun 2010

My assessment is that there's nothing here meriting a continued "Urgent" status for this report, so I'm regrading it as "Normal".

-- CrawfordCurrie - 27 Jun 2010

My assessment is that this is the kind of bug report that is in the same family as

• Ongoing looking nice review
• Ongoing user friendliness review
• Ongoing code stability review
• Ongoing I do not bother to raise task items and just abuse this one review

I think this should have been a development web topic. We cannot in practical track anything on such a generic task and it is bad for configuration management to have generic bug items. Better to raise a bug item each time a security issue is identified that needs action.

I am changing this to No action. Raise bug items for each issue that you want to work on - or start a review topic in development.

This task will end up being open forever because there is always another thing that can be improved and we end up with many different fixes that we cannot track individually a year after.

-- KennethLavrsen - 27 Jun 2010

Well, the original reason it was a Task was to try and make it an action on everyone who should have read the paper. But you are right, it's not SMART, and could have been handled as a dev topic.

-- CrawfordCurrie - 28 Jun 2010

Commenting is disabled while not logged in