I'm still thinking about it. I was raised a small question regarding the cooperation of applications (page 126 of book). The applications can share tables, sessions, files, import modules from other applications, call other's applications actions with exec_environment ...
Is there a way to prevent my application to share this information? If an application poorly designed is vulnerable ¿can others applications protect against this? I have not very clear whether a web2py installation is designed to be programmed by a single development team, or if possible more than one webmaster at the same time. Let's say we have a system with multiple applications such as wikis T3- like, where each wiki has its own administrator. Is web2py not intended for that? On 1 jul, 02:15, GoldenTiger <goldenboy...@gmail.com> wrote: > > 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 > > ... > > leer más »
