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 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.
>
> > Another way to see this is that some application do not use
> > authentication at all and still they need to use a session to track
> > users.
>
> > > Questions:
>
> > > "If not key/salt is provided is provided web2py uses MD5, but is a key/
> > > salt is provided (and the scaffolding application generates one
> > > automatically) it uses HMAC+MD5 or HMAC+SHA512."
>
> > > I ran 'python web2py.py -S testapp' but it did not generate a new
> > > value for auth.settings.hmac_key in db.py. Should it have?
>
> > This is a bug. I just fixed it in trunk. Thank you!
>
> > > It appears to use MD5 by default unless an alternative is specified,
> > > such as SHA512.
>
> > 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.
>
> > This is a very useful discussion.
>
> > Massimo
>
> > > Please feel free to discuss!
>
> > > Craig Younkins
>
> > > On Jun 30, 9:58 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > > Hi Craig,
>
> > > > You may also want to ask some questions about form validation, default
> > > > validators and directory traversal attacks in file uploads.
>
> > > > Massimo
>
> > > > On 29 Giu, 11:08, Craig Younkins <cyounk...@gmail.com> wrote:
>
> > > > > Hello there! My name is Craig Younkins. I'm a summer intern at
> OWASP,
> > > > > the Open Web
>
> ...
>
> read more »
