*quickly looks up HMAC* Sure, I guess we are doing that!
@magnus: App writers should not be encouraged to carefully validate
the session data, the SHA256 hashing does that job. They should trust
the data totally if they have set a good @@state_secret. Nobody can at
any point alter the data in the hash, they can only look at it.
Perhaps it's worth mentioning that if one is not using a technology
like TLS (https) that it would be inappropriate to use CookieSessions
to store passwords due to the unencrypted nature of the data, though
in this situation, the user has probably logged in with a http request
that involved actually sending their password in real clear text,
where this data is a bit more obscure, base 64 encoded ruby
marshaling, but never the less easy enough to decode by anyone who
knows their stuff, especially if they know that the app is built using
camping and ruby. I'd really like to encourage the use of OpenID so
your user's never need to send you their password or other secrets,
and thus nothing secret goes in clear text if you can't afford an SSL
certificate. Most user's of OpenID have Identity Providers who use SSL
when they ask for a password or similar secrets.
They can surely be sure nobody has tampered with it. Leave the
validation to the things users can supply, not things in our HMAC-
SHA256 verified session data.
As far as XSS goes, I've put on the wiki one simple solution:
http://code.whytheluckystiff.net/camping/wiki/XssBeGoneWithSessions
But it's something we can't automate from inside camping without being
annoying. It could potentially be automated if we included javascript
in the output of every page that did some magic on all the links and
forms, or if we took over every :href attribute used anywhere in
markaby and included logic to add the query string part with the sign
value, but if we do build this in to the core of camping, then users
would also be forced to use sessions in their app, and it would be
added to url's which don't need it.
The problem with XSS is simply that an attacker can make a request to
your app from the user with their cookies all in place simply by doing
something like: <img src="http://app.com/user_account/
delete_everything" />. Switching to POST doesn't help much as the
attacker could place a form inside an iFrame and use javascript to
post it to the address when the target user visits the page. The
attacker cannot actually see what's in the cookie due to browser
security policy, so it's safe for us to store a secret number in the
session even in cookies, and require that secret number to make a
request.
Simply, the attacker doesn't know the secret code, and the user gets a
new one every time they login. If we applied it to all url's, the user
would only have to paste a link to the app somewhere for the attacker
to know the code and be able to attack them, which is why it's best
used only on destructive actions which quickly redirect back to URL's
which contain no signing code in their address.
The reason nobody can ever spoof a session is that they can never
generate the needed hash because they don't have the @@state_secret
piece of text needed to do so, hopefully! This presents a challenge
for open source. We really need to raise an error if anyone tries to
use CookieSessions without setting the @state_secret to something
other than nil or "". Maybe one good solution is to add logic to
CookieSessions so that if it is run without a @@state_secret supplied,
it creates a file containing the state_secret, filling it with totally
random characters. This too is a terrible security risk though, as the
camping app may be being run in a webserver like apache or lighttpd,
and that state_secret file generated may be readable by the web
server. If an attacker can simply download a file telling them the
state secret, it's game over. The only sensible default I could think
of was the source code to the application itself, still problematic
for open source, but would allow people to build apps without
specifying an @state_secret and have a unique value used anyway. As
they change the source code during development, they would be
repeatedly signed out. I couldn't figure out a way to do this well
with the current release of camping.
—
Jenna
On 26/05/2008, at 7:45 AM, Aria Stewart wrote:
On Sat, 2008-05-24 at 22:43 -0500, _why wrote:
On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:
* The cookie session is named Camping::Session and is placed in
camping/session.rb. Maybe this should be called
Camping::CookieSession or???
You know, these cookie sessions seem like they could be a problem.
A lot of sessions would contain just the hash and the user name.
So, spoof the user name and you're in, you know?
Agreed, without an HMAC signature.
_______________________________________________
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
_______________________________________________
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
