> 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.
Well, this is my point of view: I don't know if i'm wrong. If i understanded it well, this concept could be classified as a design concept, do you agree? design flaws are the most complex aspect of security personally I am doubtful about the explanation above, maybe I don't understand very well anyway it's the game of "I can't find any flaw at this moment, but you can't demonstrate it hasn't" Vulns like SQL injection could be enumerated and tested by a computer in a lot of possibilities, but design flaws couldn't, since lies on human logic History is full of stories about design flaws. The following is a representative case. http://www.seattlepi.com/local/373426_insecure04.html Sorry, I am very paranoid ^^ On 30 jun, 22:06, mdipierro <mdipie...@cs.depaul.edu> wrote: > 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 > > ... > > leer más »
