Forum OpenACS Q&A: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!)

22: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!) (response to 1)

Posted by Barry Books on 05/29/04 03:49 PM

Isn't this the problem signed variables are supposed to solve and if not why not?

Sudo would be a very cool feature. How about a package (sudo) that keeps a table of urls to protect. Hook into the request processor so that if you go to one without an valid sudo session you are redirected just like the current session system. You could control the time with a package parameter. You could also specify that a url requires login even with a valid sudo session. The urls could have wild cards and package-keys.

package-key         url           single_P
     *                 */admin/*         f            would protect all admin pages
     *                 */permission    t           would require login to every access
acs-subsite      /admin*          f            would protect the subsite admin pages

sorry about the formating

This would allow sites to customize security policies without changing code just like sudo.

24: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!) (response to 22)

Posted by Jeff Davis on 05/29/04 04:15 PM

Unfortunately signed variables are relatively easily forged. Here is a short summary of the problem I wrote before:

...there is nothing in place to insure that the signed variable sent back is the signed variable sent to the browser.

In ad_form for example the key is signed but the signature says:

<input type="hidden" 
   name="__key_signature" 
   value="851 0 2D43063DA4AFDC46574E81151ED48C64939CF3AC" />

the 851 is the token_id and 0 is the expire time (does not expire) and the hash is:

ns_sha1 "$value$token_id$expire_time$secret_token"

Now, all you need to do to forge this is to get some other form to sign an integer (any form which lets you enter an integer which is subsequently served back signed would work) since there is nothing there tied to the session or a shared secret or anything like that.

Some ways to fix this would include having a shared secret (a random string in a session cookie for example) or a server side secret which is session specific (pick a token_id for the session but don't send it in the request).

One other thing I realized in looking at this is that as far as I can tell, we don't ever expire tokens which is probably a mistake. We should probably have a token lifetime parameter and sweep expired tokens.