Yes I know this about T3, 3 levels, ok. What i wonder is if two different wiki admins (or users) of two different wiki apps could share data in some way (sessions,files,db...). Since wiki admin/users can write python code editing pages, could users access shared data?
Another independient T3 cuestion: We have T3/models/db.py, where is_admin=(t2.logged_in and (not settings.administrator_emails or t2.person_email in settings.administrator_emails)) According that condition, if on production server, admin disable settings.administrator_emails, then if a new user registers, we have is_admin=True for new user, haven't? On 1 jul, 07:57, mdipierro <mdipie...@cs.depaul.edu> wrote: > 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 > > ... > > leer más »
