Camping 2.0 - What's left?

[Bluebie, Jenna]

*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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list