On 30 Giu, 23:57, GoldenTiger <goldenboy...@gmail.com> wrote: > 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?
One web2py instance can run multiple apps. They all run under the same os credentials as web2py and therefore they can see and edit each other files. We simply provide some API's to allow one app to open a session from another app. There is nothing web2py specific about this. In any other web framework/system if you run two web apps as www-data, they can read each other files. If you need separation you can run two or more web2py instances under different credentials. > 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? We need two distinguish three level: the os level, the web2py admin level, the application level. At the os level of course you can have multiple users. At the web2py admin level there is a single user and we refer to him as "administrator". The administrator can upload apps, create app, edit apps. We have a single administrator because things would get very messy if two people where to edit the same app at the same time (although we have mechanisms to detect this, notify the administrator and revert changes). At the app level, each app can have arbitrary users and the authentication for different apps is separate (different groups, different users, different permissions, etc.) So in the case of a wiki you would have two types of "administrator": the web2py administrator who deployed the wiki (for two coexisting wikis, the same administrator), the wiki administrator who has special permission on the wiki content (this can be different for different coexisting wikis). Auth is the app-level authentication mechanism. the "web2py administrator" is not managed by Auth. Does this make sense? > > 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 > > ... > > leggi tutto
