this is how I make my hmac_kay
>>> import uuid
>>> print 'sha512:'+str(uuid.uuid4())
web2py has a function in gluon/admin.py, app_create('name',request)
that clones welcome and replaces hmac_key='<....>' with a random key
generated as above.
>From a web2py shell you can also do
>>> from gluon.admin import app_create
>>> app_create('mynewapp',request)
I would not know how to make this transparent. If you have any idea
please let me know. I agree that this is undocumented.
On 30 Giu, 15:01, Yarko Tymciurak <resultsinsoftw...@gmail.com> wrote:
> On Jun 30, 2:44 pm, Craig Younkins <cyounk...@gmail.com> wrote:
>
>
>
> > If you'd like this moved to the developers list, just approve my application
> > and reply there.
>
> > > When I say that MD5 is the default that applies only to the case that
> > > a hmac_key is not specified. This is 1) for backward compatibility; 2)
> > > because without a key/salt sha512 and md5 are vulnerable to the same
> > > dictionary attacks.
>
> > Hmm.... Well, I'm looking at the CRYPT class and it appears that in order to
> > use HMAC the *caller* needs to pass in the key parameter. Grepping the
> > source tree I've found a few places where the caller does not supply the
> > key:
>
> > applications/admin/models/access.py:55
> > applications/admin/controllers/default.py:78
> > gluon/main.py:480
> > gluon/main.py:495
> > gluon/validators.py:2344
>
> > I am of course unfamiliar with the internals of the project, but it would
> > appear to me that admin passwords are never HMAC'd. Can you confirm?
>
> ... interesting discussion ---- Let me FIRST point out some things
> Craig mentions which should not fall by the wayside:
>
> 1. -- There is no documented way to generate {an appropriate}
> hmac_key:
> ==> This is true; One major way to alleviate this would be to
> have an admin function that could be called manually (take your pick:
> to do the replacement, as gluon/admin.py:app_create() does, which
> would need a search/replace --- or better, just give a popup with a
> newly formed key an admin could readily copy/paste.
>
> ==> This is also inconsistently applied --- for example, if you
> pack "welcome" app, and then (as you might with apps from other
> sites, such as web2py.com, or other users) install it as a newly
> (re)named application, <your key here> persists. At the
> surface, the same thing app_create() is doing could be done in
> app_install(), but this too would be prone to inconsistencies (i.e.
> the user you get an app from to test for them will have already
> installed their own hmac_key, so the kind of replacement that
> app_create() does - which depends on a "magic string" in the template
> app, will fail.
>
> A better solution would be to make this completely transparent --- a
> little thinking about this should come to a solution (hmac_key is
> currently persisted in a source file...)
>
> ... Good discussion, guys - lovely to see this!
>
> - Yarko
>
>
>
> > I suggest that the key be pulled in from the configuration inside CRYPT so
> > that the caller isn't required to pass it in. I would also suggest that the
> > hash method be placed in configuration. Consolidating the configuration of
> > security mechanisms greatly aids in a security review. If it were
> > consolidated, a reviewer would only have to look at the default
> > configuration. In it's current state, a reviewer needs to look at all the
> > callers of CRYPT to determine the security of CRYPT.
>
> > I realize some of my suggestions may prove difficult to support backwards
> > compatibility. In many cases this can be worked around to implement and
> > start using newer, safer security controls while maintaining support for
> > older methods. In some cases it's more difficult than others.
>
> > > If you use "admin" to create a new app, the '<your secret key>' is
> > > automatically replaced with something like
>
> > Thanks for clarifying! This works.
>
> > > > * Do not use cgi.escape for HTML escaping because it does not escape
> > > > single quotes and may lead to XSS - Seehttp://
>
> >www.pythonsecurity.org/wiki/web2py/#cross-site-scripting-xss> > and
> >http://www.pythonsecurity.org/wiki/cgi/
>
> > > I assume you refer to attribute escaping. When using helpers like
>
> > > {{=A(link,_href=url)}} then link is escaped using cgi.escape but url
>
> > > is escaped differently (quotes are escaped). The problem is that the
> > > escape function does not know whether a variable is to be inserted in
> > > html, css, js, attribute, a string in js, etc. etc. and therefore if
> > > the function does know the context it is in it can never always escape
> > > correcly. I do not believe there is a general solution to this
> > > problem. web2py assumes {{=....}} is escaping HTML/XML. If you need to
> > > scape attributes we suggest using helpers. If you need to scape js
> > > code or strings in js code, you may have to do it manually.
>
> > That's not quite what I was getting at. You're right about needing the
> > context in order to escape correctly though. I think the default escaping
> > should include single and double quotes. cgi.escape escapes double quotes
> > but not single quotes.
>
> > I thought that the default escaping was going through cgi.escape by way of
> > the xmlescape method, but given the below, that appears to not be the case.
> > I'm a little confused.
>
> > Here's an example of something I don't think I should be able to do:
>
> > Controller: return dict(data='" onload="alert(1);" bad="')
> > View: <body class="{{=data}}"></body>
> > Output: <body class="" onload="alert(1);" bad=""></body>
>
> > The same attack works with single quoted attributes. While you're right, we
> > can't do full proper escaping without knowing the context, I don't think
> > quotes should be permitted in any web context.
>
> > > I disagree but probably I did not explain this very well. web2py has
> > > two things it calls session. One is the general session managed via
> > > cookie session_id. One is the authentication session stored into the
> > > general session file. When a user logs out the authentication session
> > > information into the general session is deleted. If an attacker where
> > > to intercept the cookie session_id and try to use it to gain access to
> > > the system, it would not work. The session_id is used for the general
> > > session and it does not expire because when the user logs in again, if
> > > the user had a state stored in the session file, you want that state
> > > to be retrieved.
>
> > Hmmm. I'll have to ponder this.
>
> > > As mentioned above the "admin" does this and "web2py -S app" should
> > > too (but there is the bug you pointed out). "admin" automatically sets
> > > the hmac_key="sha512:.....", i.e. defaults to SHA512.
>
> > Thanks, I understand this better now. What's confusing is that the algorithm
> > could be set by the key or digest_alg params, neither of which the caller
> > need provide. It gets a little complicated to determine what code path will
> > execute because of how it depends on these two params. Like I said before,
> > I'd love to see these be statically set in the application configuration so
> > there is only one algorithm and one key that is used throughout the
> > application, with no requirement for the caller.
>
> > Best,
> > Craig Younkins
>
> > On Jun 30, 2:16 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:> On 30 Giu,
> > 12:19, Craig Younkins <cyounk...@gmail.com> wrote:
>
> > > > "You may also want to ask some questions about form validation,
> > > > default validators and directory traversal attacks in file uploads. "
>
> > > > Good idea. I'll add those.
>
> > > > I've reviewed what you wrote on the wiki and some parts of the
> > > > application code, and I have a few preliminary recommendations to
> > > > improve security:
>
> > > > * Drop support for basic auth. It's really insecure -
>
> >http://www.pythonsecurity.org/wiki/basicauthentication/
>
> > > Actually this already disabled by default. You have to enable if you
> > > want to use it. People sometimes use it for web services.
>
> > > > * Drop MD5 as the default hashing algorithm, use SHA512. MD5 is now
>
> > considered 'cryptographically broken'
>
> > > When I say that MD5 is the default that applies only to the case that
> > > a hmac_key is not specified. This is 1) for backward compatibility; 2)
> > > because without a key/salt sha512 and md5 are vulnerable to the same
> > > dictionary attacks. In all the other cases...(read next answer)
>
> > > > * The HMAC secret is by default '<your secret key>', and I don't see
> > > > anywhere in the documentation how to generate a new one or the
> > > > recommendation to do so
>
> > > If you use "admin" to create a new app, the '<your secret key>' is
> > > automatically replaced with something like
>
> > > auth.settings.hmac_key = 'sha512:06a78549-cf6c-4767-a847-435541210976'
>
> > > The 'sha512' forces web2py to use sha512. This is the normal behavior
> > > for all new applications unless the the "admin" interface is bypassed.
> > > In this case the user has to come up with a unique hmac_key on his
> > > own.
>
> > > > * Do not use cgi.escape for HTML escaping because it does not escape
> > > > single quotes and may lead to XSS - Seehttp://
>
> >www.pythonsecurity.org/wiki/web2py/#cross-site-scripting-xss
>
> > > > and http://www.pythonsecurity.org/wiki/cgi/
>
> > > I assume you refer to attribute escaping. When using helpers like
> > > {{=A(link,_href=url)}} then link is escaped using cgi.escape but url
> > > is escaped differently (quotes are escaped). The problem is that the
> > > escape function does not know whether a variable is to be inserted in
> > > html, css, js, attribute, a string in js, etc. etc. and therefore if
> > > the function does know the context it is in it can never always escape
> > > correcly. I do not believe there is a general solution to this
> > > problem. web2py assumes {{=....}} is escaping HTML/XML. If you need to
> > > scape attributes we suggest using helpers. If you need to scape js
> > > code or strings in js code, you may have to do it manually.
>
> > > > * Session IDs should time out when the authentication information
> > > > does, and the user should get a new session ID when they
> > > > reauthenticate. This defense will help ensure that even if a session
> > > > ID is leaked, it will only be useful for a limited amount of time. It
> > > > sounds like users always have the same session ID.
>
> > > I disagree but probably I did not explain this very well. web2py has
> > > two things it calls
>
> ...
>
> leggi tutto
