I''ve just sent a pull-request to _why with my changes[1] and here is some things that I think needs to be done before a (possible) release: * The cookie session is named Camping::Session and is placed in camping/session.rb. Maybe this should be called Camping::CookieSession or??? * The ActiveRecord session is named Camping::ARSession and is placed in camping/ar/session.rb. Maybe it should be called Camping::AR::Session or??? * The documentation of cookie sessions is just utterly wrong. Can someone clean it up? * The documentation in camping-unabridged.rb and README are almost duplicates. camping-unabridged.rb should only contain about the differences between camping.rb and camping-unabrdiged.rb, while README should be all about Camping (IMO). We must also add that apps should be run using Rack, and The Camping Server is only for development. * The flipbook-template produces some weird output once in a while. See [2]. Anyone knows RDoc-templates? We should also include all the methods in a list, since they''re spread between Base, Helpers and Controllers. And Controllers won''t be documented since it has a "X =" in front of it (doc-ability vs size?). * Some investigating of how to use Camping with DataMapper, Sequel and Og, and if they require any glue. Should the other ORMs also have tables prefixed with the app name? * What about a little guide of how to make your app Camping 2.0 "compatible"? * Cleaning up the wiki to be 2.0 only? * <insert your wish> I''m not saying I won''t do any of these things, I just want to push this code so other can contribute too. (I suck at docs + decisions). Oh, and I''ve included `rake ruby_diff` which will use Ruby2Ruby to translate camping.rb & camping-unabridged.rb to "proper" Ruby and show a diff. Really useful when synchronizing the two files. camping.rb is now at 3171 bytes (77% of 4kB)! (I realize that we don''t need to target all of these issues for 2.0, we must have something left for 2.1 :-) [1] http://github.com/judofyr/camping [2] http://camping.rubyforge.org/classes/Camping/H.html vs http://camping.rubyforge.org/classes/WEBrick.html --- Magnus "We''re missing _why in #camping" Holm
On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:> I''ve just sent a pull-request to _why with my changes[1] and here is some > things that I think needs to be done before a (possible) release:It''s been merged, great work, Magnus. I''m not quite to the point of addressing all of your questions, I''m just trying some of my old apps on this latest stuff. So, what''s the reason for getting rid of @env? Well, I see that Rack::Request is a wrapper for all those vars. I think I''m still going to allow @env, though, for compatibility with old apps. _why
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? _why
No, that isn''t a problem. The cookie contains a marshaled string of the @store variable, but it also has after it a '':'' and then an SHA256 hash of the marshaled string combined with a secret value the user needs to set in their controller with something like: @@state_secret = "secret thingy here" Unfortunately, it is totally insecure if that isn''t set, and I guess we should raise an error in that case, or maybe just make a random value, though that would cause problems in servers using multiple running copies of ruby, and in CGI, cluster server systems, and so on. Ideally I wanted to make the fallback string be the source code for the main app file, which I figured would be unique enough and secret enough in most situations, but couldn''t figure out how from the context of a module. Rails gets around this issue by having a ''generator'' which includes a random code at the time of app creation hard coded in, and ships with cookie sessions as the default session store for convenience. The rails implementation is a bit more complex in that it can span the session data over multiple cookies if it won''t fit in just one. I personally think if app developers are trying to stuff more than 4k of stuff in a session they should get errors anyway to teach them that it''s not appropriate, regardless of the storage system. Anyway, if the attacker doesn''t know the value of @state_secret, and the hashing algorithm in use isn''t broken, changing any character in the cookie will cause it to be ignored and a new session created. They could brute force it, but SHA256 has a pretty decent hash length and that would take some serious time. It''s much the same concept as ''signing'' used in various other systems. In this case instead of an expensive encryption certificate as the secret, we have a made up string. ? Jenna On 25/05/2008, at 1:43 PM, _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? > > _why > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list
I forgot to mention though, the signing just stops users from changing the session data without the server knowing, it doesn''t stop them from reading it. Any data in the session when using the cookie sessions store only needs to be base64 decoded and unmarshaled with ruby to find out what''s inside. As far as i''m concerned, any app that''s keeping secrets from me about me is not the kind of app I want to be using anyway. On 25/05/2008, at 1:43 PM, _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? > > _why > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list
"As far as i''m concerned, any app that''s keeping secrets from me about me is not the kind of app I want to be using anyway." I feel like I just read this exact line somewhere else in the last few days... -- Eric On Sun, May 25, 2008 at 2:02 AM, Bluebie, Jenna <blueberry at creativepony.com> wrote:> I forgot to mention though, the signing just stops users from changing the > session data without the server knowing, it doesn''t stop them from reading > it. Any data in the session when using the cookie sessions store only needs > to be base64 decoded and unmarshaled with ruby to find out what''s inside. As > far as i''m concerned, any app that''s keeping secrets from me about me is not > the kind of app I want to be using anyway. > > > On 25/05/2008, at 1:43 PM, _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? >> >> _why >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >
You''re absolutely right. Not anymore, though. I fixed in my cs-branch. Now it will save the data in three cookies: camping_blob, camping_hash and camping_time. The secure_blob_hasher includes the remote IP and the user agent, and it has also a timeout on 15 minutes (which can be overridden with @@state_timeout). http://github.com/judofyr/camping/commits/cs On Sun, May 25, 2008 at 5:43 AM, _why <why at whytheluckystiff.net> 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? > > _why > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >-- Magnus Holm
That''s no good, a significant amount of ISP''s do not route requests from one user to one web host via the same routes on each request, and when they use proxy servers, as AOL does, that means every request comes from a different IP address, even though it''s the same user. Worse still, the IP addresses of the proxy server''s are located all around the world, so even geolocation fails. Ditch the remote IP check or it wont work at all for a lot of users. I also feel 15 minutes is dodgy. I like session cookies, not timed cookies. The user closes the browser and the cookie dies, nice and simple. If you want to use a timeout, how about something that wont have any real downsides like a day or two? The user agent is probably safe, but some plugins add text to the user agent, so if the user upgrades flash for instance, the session is instantly voided and unusable as flash''s version number will change. The only one of these which limits usefulness of cookie stealing to attackers is the IP check which is totally unusable in the real world internet. Timeouts are just annoying and I don''t think extremely high security apps which would suit 15 minute timeouts are really the target audience of Camping. ? Jenna On 25/05/2008, at 10:45 PM, Magnus Holm wrote:> You''re absolutely right. Not anymore, though. I fixed in my cs-branch. > Now it will save the data in three cookies: camping_blob, camping_hash > and camping_time. The secure_blob_hasher includes the remote IP and > the user agent, and it has also a timeout on 15 minutes (which can > be overridden > with @@state_timeout). > > http://github.com/judofyr/camping/commits/cs > > On Sun, May 25, 2008 at 5:43 AM, _why <why at whytheluckystiff.net> > 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? >> >> _why >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> > > > > -- > Magnus Holm > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list
So there isn''t really any way to be safe against XSS and at the same time support all users? Then ignore my "patch", and we should just make it clear that the data is in clear-text within the cookie and you must be very careful with validating the input. On Sun, May 25, 2008 at 3:04 PM, Bluebie, Jenna <blueberry at creativepony.com> wrote:> That''s no good, a significant amount of ISP''s do not route requests from one > user to one web host via the same routes on each request, and when they use > proxy servers, as AOL does, that means every request comes from a different > IP address, even though it''s the same user. Worse still, the IP addresses of > the proxy server''s are located all around the world, so even geolocation > fails. > > Ditch the remote IP check or it wont work at all for a lot of users. I also > feel 15 minutes is dodgy. I like session cookies, not timed cookies. The > user closes the browser and the cookie dies, nice and simple. If you want to > use a timeout, how about something that wont have any real downsides like a > day or two? > > The user agent is probably safe, but some plugins add text to the user > agent, so if the user upgrades flash for instance, the session is instantly > voided and unusable as flash''s version number will change. > > The only one of these which limits usefulness of cookie stealing to > attackers is the IP check which is totally unusable in the real world > internet. Timeouts are just annoying and I don''t think extremely high > security apps which would suit 15 minute timeouts are really the target > audience of Camping. > > > ? > Jenna > > On 25/05/2008, at 10:45 PM, Magnus Holm wrote: > >> You''re absolutely right. Not anymore, though. I fixed in my cs-branch. >> Now it will save the data in three cookies: camping_blob, camping_hash >> and camping_time. The secure_blob_hasher includes the remote IP and >> the user agent, and it has also a timeout on 15 minutes (which can be >> overridden >> with @@state_timeout). >> >> http://github.com/judofyr/camping/commits/cs >> >> On Sun, May 25, 2008 at 5:43 AM, _why <why at whytheluckystiff.net> 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? >>> >>> _why >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >> >> >> >> -- >> Magnus Holm >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >-- Magnus Holm
On 25 mei 2008, at 00:25, Magnus Holm wrote:> * <insert your wish>* Are deeply nested query arguments and tricky bits like checkbox arrays/param arrays handled properly (and in a Camping-compatible manner, AFAIK in Camping the first parameter wins as opposed to Rails) by Rack? What happens with file uploads? * I loved Camping::H too much, don''t see a big deal in wrappint the request/env hashes into it (also to avoid substantial code scavenging)
On Sun, May 25, 2008 at 4:25 PM, Julian Tarkhanov <julian.tarkhanov at gmail.com> wrote:> > On 25 mei 2008, at 00:25, Magnus Holm wrote: > >> * <insert your wish> > > * Are deeply nested query arguments and tricky bits like checkbox > arrays/param arrays handled properly (and in a Camping-compatible manner, > AFAIK in Camping > the first parameter wins as opposed to Rails) by Rack?Rack doesn''t do anything special with queries ending in [] and [key], so we''re cleaning it up in Base#initialize. It works with arrays and hashes, but not perfectly when they''re nested. Could you write some examples of how they should be handled? Here''s a helper to see what Camping does today: http://pastie.caboo.se/private/53towf4gox3di0k6c8zhw I think we could use almost the same code if we just move it out to a helper and do some recursive magic.>What happens with file uploads?No idea! Maybe Christian Neukirchen can answer what Rack::Request does with it? There isn''t any file-upload specific code in Camping now.> * I loved Camping::H too much, don''t see a big deal in wrappint the > request/env hashes into it (also to avoid substantial code scavenging)It would be easier to remove Camping::H for good, but I like #method_missing for getting out the values... Unless we want to get it under the 3kB-mark, I don''t think it''s worth to remove it. We''re far away from 4kB!> _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >-- Magnus Holm
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.
On Sun, May 25, 2008 at 02:45:15PM +0200, Magnus Holm wrote:> You''re absolutely right. Not anymore, though. I fixed in my cs-branch. > Now it will save the data in three cookies: camping_blob, camping_hash > and camping_time. The secure_blob_hasher includes the remote IP and > the user agent, and it has also a timeout on 15 minutes (which can be overridden > with @@state_timeout).Okay, this is merged. You are swift! But I think I agree with Jenna, I didn''t get the cookie session that well before and now I like it and now I care. So I might revert these changes back to the more relaxed technique. _why
*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
Agreed all the previous stuff...> 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 goodI don''t think raising a error is _required_, filling the log with a meaningful message / advice should be enough.> 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 andInteresting idea.> 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 aI think it would be more a annoyance than a real trouble for the users. The Web in intrinsecally broken.> way to do this well with the current release of camping.For you idea of using the source cod (I think it could be more than enough) I think anotehr variations could be: - Using a directory listing of the app. - The value of a environment variable ( - The timestamp (or something derived) of the folder containing the app. - The path where the app is intalled - etc -- An?bal> > ? > 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 > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >
On 26/05/2008, at 10:18 AM, An?bal Rojas wrote:> Agreed all the previous stuff... > >> 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 > > I don''t think raising a error is _required_, filling the log with a > meaningful message / advice should be enough. > >> 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 > > Interesting idea. > >> 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 > > I think it would be more a annoyance than a real trouble for the > users. > The Web in intrinsecally broken. > >> way to do this well with the current release of camping. > > For you idea of using the source cod (I think it could be more than > enough) I think anotehr variations could be: > > - Using a directory listing of the app. > - The value of a environment variable ( > - The timestamp (or something derived) of the folder containing the > app. > - The path where the app is intalled > - etcI don''t like any of these, it has to be something a remote attacker cannot find out the value to. Remote attacker could potentially get a directory listing, guess the value of an environment variable, find out the timestamp from a webserver''s directory listing, and guess the path the app is installed to. The secret HAS to be a secret, it can''t be something anyone else has any chance of guessing or finding out remotely.> > > -- > An?bal > > >> >> ? >> 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 >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list
Yes, but the idea is using this as default, and warning about it. Any webdeveloper lazy enough to ignore 1st The instructions, 2nd the warnings is beyond any help. A framework can''t replace intelligence On Mon, May 26, 2008 at 7:53 PM, Bluebie, Jenna <blueberry at creativepony.com> wrote:> > On 26/05/2008, at 10:18 AM, An?bal Rojas wrote: > >> Agreed all the previous stuff... >> >>> 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 >> >> I don''t think raising a error is _required_, filling the log with a >> meaningful message / advice should be enough. >> >>> 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 >> >> Interesting idea. >> >>> 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 >> >> I think it would be more a annoyance than a real trouble for the users. >> The Web in intrinsecally broken. >> >>> way to do this well with the current release of camping. >> >> For you idea of using the source cod (I think it could be more than >> enough) I think anotehr variations could be: >> >> - Using a directory listing of the app. >> - The value of a environment variable ( >> - The timestamp (or something derived) of the folder containing the app. >> - The path where the app is intalled >> - etc > > I don''t like any of these, it has to be something a remote attacker cannot > find out the value to. Remote attacker could potentially get a directory > listing, guess the value of an environment variable, find out the timestamp > from a webserver''s directory listing, and guess the path the app is > installed to. The secret HAS to be a secret, it can''t be something anyone > else has any chance of guessing or finding out remotely. > >> >> >> -- >> An?bal >> >> >>> >>> ? >>> 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 >>> >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >-- An?bal
On Mon, May 26, 2008 at 08:56:38PM +1930, An?bal Rojas wrote:> Yes, but the idea is using this as default, and warning about it.Then your idea of using `pwd` is pretty good, since it''s not immediately obvious. Or the timestamp of $0 might be good. If the timestamp (or the path) changes, then the sessions merely expire. I guess that''s good enough with the warnings there, too. _why
Yeah, I suppose that''s reasonable.. the timestamp even on The Camping Server and stuff would still be unique to the system.. it''s a short secret, but it''s better than nothing. Warnings and defaulting to that sounds like a good idea to me! I beg to differ on those who don''t follow instructions and don''t listen to warnings being beyond help. There should be a good default. :) I frequently don''t follow instructions! On 26/05/2008, at 2:45 PM, _why wrote:> On Mon, May 26, 2008 at 08:56:38PM +1930, An?bal Rojas wrote: >> Yes, but the idea is using this as default, and warning about it. > > Then your idea of using `pwd` is pretty good, since it''s not > immediately obvious. Or the timestamp of $0 might be good. If the > timestamp (or the path) changes, then the sessions merely expire. > I guess that''s good enough with the warnings there, too. > > _why > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list
Me neither ;-) And talking about instructions, the Wiki will need a Extreme Make Over to catch up with the code. -- An?bal On Tue, May 27, 2008 at 1:11 AM, Bluebie, Jenna <blueberry at creativepony.com> wrote:> Yeah, I suppose that''s reasonable.. the timestamp even on The Camping Server > and stuff would still be unique to the system.. it''s a short secret, but > it''s better than nothing. Warnings and defaulting to that sounds like a good > idea to me! > > I beg to differ on those who don''t follow instructions and don''t listen to > warnings being beyond help. There should be a good default. :) > > I frequently don''t follow instructions! > > > On 26/05/2008, at 2:45 PM, _why wrote: > >> On Mon, May 26, 2008 at 08:56:38PM +1930, An?bal Rojas wrote: >>> >>> Yes, but the idea is using this as default, and warning about it. >> >> Then your idea of using `pwd` is pretty good, since it''s not >> immediately obvious. Or the timestamp of $0 might be good. If the >> timestamp (or the path) changes, then the sessions merely expire. >> I guess that''s good enough with the warnings there, too. >> >> _why >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >