protecting users from hostile authors
We're in the process of building a cluster (just installed 8 machines) for serving a bunch (tens of thousands) of users. Many/most of these people will also be authors. A single (X.500- based) authentication system will be used for most everything. I'm trying to get a handle on what policy I want to use in order to keep authors from doing Bad Things to authenticated users who visit their pages. Looking around on Zope.org, I realized that this might already be addressed. Is there anything that prevents me (as a Zope community member with authoring privileges on zope.org) from luring users who have already authenticated with Zope.org to come look at my pages, and then running arbitrary commands with their privileges? Anyone else grappling with this situation? I'm trying to decide how to set policy so that users are reasonably safe, but authors still have the freedom to create Cool Stuff. There will most certainly be multiple classes of authors - those who can act with the authenticated user's privileges and those who can not. I'm not quite sure how to implement that yet, though. I'm also concerned about links to Bad Things, like "delete your home directory" disguised as "Get porn here!". Any thoughts? Has this already been hashed out somewhere that I should have found? Thank you. --kyler
Well, one way is to have reviewers reviewing material - labor intensive but a solution. CMF has this built in (cmf.zope.org)
From: "Kyler B. Laird" <laird@ecn.purdue.edu> Date: Fri, 24 Aug 2001 12:39:12 -0500 To: zope@zope.org Subject: [Zope] protecting users from hostile authors
We're in the process of building a cluster (just installed 8 machines) for serving a bunch (tens of thousands) of users. Many/most of these people will also be authors. A single (X.500- based) authentication system will be used for most everything.
I'm trying to get a handle on what policy I want to use in order to keep authors from doing Bad Things to authenticated users who visit their pages.
Looking around on Zope.org, I realized that this might already be addressed. Is there anything that prevents me (as a Zope community member with authoring privileges on zope.org) from luring users who have already authenticated with Zope.org to come look at my pages, and then running arbitrary commands with their privileges?
Anyone else grappling with this situation? I'm trying to decide how to set policy so that users are reasonably safe, but authors still have the freedom to create Cool Stuff. There will most certainly be multiple classes of authors - those who can act with the authenticated user's privileges and those who can not. I'm not quite sure how to implement that yet, though.
I'm also concerned about links to Bad Things, like "delete your home directory" disguised as "Get porn here!".
Any thoughts? Has this already been hashed out somewhere that I should have found?
Thank you.
--kyler
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Kyler B. Laird writes:
Looking around on Zope.org, I realized that this might already be addressed. Is there anything that prevents me (as a Zope community member with authoring privileges on zope.org) from luring users who have already authenticated with Zope.org to come look at my pages, and then running arbitrary commands with their privileges? Starting with Zope 2.2, the effective permissions are the intersection of that of the current user and that of the executable's owner. That implies, the authors cannot do thinks by highjacking visitors.
Dieter
On Sun, 26 Aug 2001 00:15:16 +0200 (CEST) you wrote:
Kyler B. Laird writes:
Looking around on Zope.org, I realized that this might already be addressed. Is there anything that prevents me (as a Zope community member with authoring privileges on zope.org) from luring users who have already authenticated with Zope.org to come look at my pages, and then running arbitrary commands with their privileges? Starting with Zope 2.2, the effective permissions are the intersection of that of the current user and that of the executable's owner. That implies, the authors cannot do thinks by highjacking visitors.
O.k., I appreciate that (lots!). However, I do not see what is stopping me from doing something nasty like... 1. Lure you to my page. 2. Check to see that you are authenticated. (My page wouldn't require it.) 3. If you are, grab your user name. 4. Create a URL for a Bad Thing (something with "manage_" in it pointed at your folder). 5. Generate a 1x1 (or whatever) <img> tag with that URL as the src value. I haven't tried this, but even if it does not work now, I wonder what policy prevents it (and insures it will not work in future versions). When I think of how to prevent this, use of the "Referer" header jumps out, but I don't send it from some of my browsers. Other possibilities include use of cookies, but I don't even like the current dependency on them. For pages generated on the server (the easiest way to do it, but not the only one), a check of outgoing HTML to attempt to catch such things is possible, but I can think of lots of avenues around such a check. Any clever thoughts? Thank you. --kyler
On Sun, 2001-08-26 at 06:32, Kyler B. Laird wrote:
On Sun, 26 Aug 2001 00:15:16 +0200 (CEST) you wrote:
Kyler B. Laird writes:
Looking around on Zope.org, I realized that this might already be addressed. Is there anything that prevents me (as a Zope community member with authoring privileges on zope.org) from luring users who have already authenticated with Zope.org to come look at my pages, and then running arbitrary commands with their privileges? Starting with Zope 2.2, the effective permissions are the intersection of that of the current user and that of the executable's owner. That implies, the authors cannot do thinks by highjacking visitors.
O.k., I appreciate that (lots!). However, I do not see what is stopping me from doing something nasty like...
1. Lure you to my page.
2. Check to see that you are authenticated. (My page wouldn't require it.)
3. If you are, grab your user name.
4. Create a URL for a Bad Thing (something with "manage_" in it pointed at your folder).
5. Generate a 1x1 (or whatever) <img> tag with that URL as the src value.
I haven't tried this, but even if it does not work now, I wonder what policy prevents it (and insures it will not work in future versions).
The policy that prevents it is the one that was told to you. *YOUR* content can only do what *you* have permission to do, period. The user browsing your stuff is 'executed' as *you*, not the user. Therefore, you could not do manage_<anything> that you did not already posess the capability to do. Period. If you already have that power, it is irrelevant.
Any clever thoughts?
The pre-existing Zope security machinery. Do a search on the Archives, and you will see all the raw details. Cheers, Bill
Kyler B. Laird writes:
O.k., I appreciate that (lots!). However, I do not see what is stopping me from doing something nasty like...
1. Lure you to my page.
2. Check to see that you are authenticated. (My page wouldn't require it.)
3. If you are, grab your user name.
4. Create a URL for a Bad Thing (something with "manage_" in it pointed at your folder).
5. Generate a 1x1 (or whatever) <img> tag with that URL as the src value.
I haven't tried this, but even if it does not work now, I wonder what policy prevents it (and insures it will not work in future versions). I fear, there is nothing that prevents it....
You need so little for this attack: only the name of the current user (and some external knowledge what a normal user may do to his own content and what his own content is). With Netscape 4.x, you would at least see a broken image, which may lead to the identification of the bad guy and allow to deal with him by non-technical, e.g. legal, means. It seems to me, that IE simply ignores broken images, though. Fortunately, Zope has "undo" support. Thus, at least in principle, there is a chance to undo the bad effect, provided the damage is recognized early enough...
When I think of how to prevent this, use of the "Referer" header jumps out, but I don't send it from some of my browsers. Not so easy. Because, I often may want to call "manage_XXX" from somewhere different from "manage_XXXForm"....
Other possibilities include use of cookies, but I don't even like the current dependency on them. Would it help?
You would attack only when the necessary cookie is there.
Any clever thoughts? Attack this problem by non-technical means.
They are your authors, aren't they? Dieter
On Sun, 26 Aug 2001 19:10:59 +0200 (CEST) you wrote:
When I think of how to prevent this, use of the "Referer" header jumps out, but I don't send it from some of my browsers. Not so easy. Because, I often may want to call "manage_XXX" from somewhere different from "manage_XXXForm"....
I suspect that you probably *usually* call it from the same folder or something "nearby" (not from a subfolder of the folder's parent...). At the very least, you call it from a "page" that you own (or a page generated by an object you own, etc.).
Other possibilities include use of cookies, but I don't even like the current dependency on them. Would it help?
A cookie could be generated when visiting a management page. That cookie would be required for management actions on that page.
You would attack only when the necessary cookie is there.
You could play with expiration times to get it to help a little bit, but I don't see it as a "solution" and it's *way* too messy for me to be interested in pursuing.
Any clever thoughts? Attack this problem by non-technical means.
Yup. I'm all for leaving policy enforcement to people. I just want to be sure that I'm taking "reasonable" steps to prevent chaos.
They are your authors, aren't they?
Have you worked with students recently? Thank you. --kyler
O.k., I've been mulling over the topic of protecting users from lots of potentially hostile authors. I've got some ideas that could go a little way toward solving the problem. When writing a method that is going to do something *really* privileged (like "drop class"), there should be a second "Are you sure you want to...?" step. In order to enforce the desired use of this step, there must be a way to determine that the method is being called directly from the Zope Publisher(???) - not through an intermediate method. I have worked with such problems extensively under Apache, and the most secure solution I developed was not pretty. I'm hoping for better in Zope. Is there a good un-fakeable way in Zope to determine the caller of a method? I am not willing to trust the things I would initially consider for doing this (without some assurances from more knowledgeable people). (Another piece that is required for the "extra step" solution I mention is the generation of some cryptographic key to the second step. I think I understand how to do that.) Some other things to consider...if you have a "Referer" header, you could use it to insure that the user got to your method through the "proper" path. Using the "Accept" header *should* give a clue if the request is coming as a result of a tag like "img". These are not dependable solutions, though. Some browsers do not send the Referer, and MS browsers have a long history of sending bogus Accept values. Also, frames could be used instead of images for "invisible" calls. --kyler
One other possibility is to restrict the authors' permissions to their original logon domain. You can do this by hand in the ZMI, so presumably you could do it programatically. Then the spoofer would be coming in from the wrong domain, and would not be allowed permissions. This would keep the author from logging in when he was travelling, but it would otherwise seem pretty useful (unless the spoofer were in the same domain, but you could restrict it down to the individual IP address). Cheeers, Tom P [Dieter Maurer]
Kyler B. Laird writes:
O.k., I appreciate that (lots!). However, I do not see what is stopping me from doing something nasty like...
1. Lure you to my page.
2. Check to see that you are authenticated. (My page wouldn't require it.)
3. If you are, grab your user name.
4. Create a URL for a Bad Thing (something with "manage_" in it pointed at your folder).
5. Generate a 1x1 (or whatever) <img> tag with that URL as the src value.
I haven't tried this, but even if it does not work now, I wonder what policy prevents it (and insures it will not work in future versions). I fear, there is nothing that prevents it....
You need so little for this attack: only the name of the current user (and some external knowledge what a normal user may do to his own content and what his own content is).
With Netscape 4.x, you would at least see a broken image, which may lead to the identification of the bad guy and allow to deal with him by non-technical, e.g. legal, means. It seems to me, that IE simply ignores broken images, though.
Fortunately, Zope has "undo" support. Thus, at least in principle, there is a chance to undo the bad effect, provided the damage is recognized early enough...
When I think of how to prevent this, use of the "Referer" header jumps out, but I don't send it from some of my browsers. Not so easy. Because, I often may want to call "manage_XXX" from somewhere different from "manage_XXXForm"....
Other possibilities include use of cookies, but I don't even like the current dependency on them. Would it help?
You would attack only when the necessary cookie is there.
Any clever thoughts? Attack this problem by non-technical means.
They are your authors, aren't they?
Kyler B. Laird wrote:
O.k., I appreciate that (lots!). However, I do not see what is stopping me from doing something nasty like...
1. Lure you to my page.
2. Check to see that you are authenticated. (My page wouldn't require it.)
3. If you are, grab your user name.
4. Create a URL for a Bad Thing (something with "manage_" in it pointed at your folder).
5. Generate a 1x1 (or whatever) <img> tag with that URL as the src value.
You need two users: 1: You as system manager, that is, the user you use to edit the site through the web. 2: You as user. That is, a user with no more rights than a normal user. Then, you ensure that you never look at a user's page, except whne you're logged in as the latter of the two users. It's pretty much the same discipline as not running execuatables other users have left lying around on a shared unix system. As has been pointed out by others, Zope protects you from this quite well already. You only need go the extra length of having two users yourself if you want to avoid the specific case you mention above. -- Steve Alexander Software Engineer Cat-Box limited
Steve Alexander wrote:
As has been pointed out by others, Zope protects you from this quite well already. You only need go the extra length of having two users yourself if you want to avoid the specific case you mention above.
Of course, if your users want to avoid the specific case you mention, they'd better be careful what they click on! :) You can encourage users always to log out immediately after logging in and doing stuff. That's a similar level of protection I get when I use something like Amazon.com. If I leave myself logged in, then I guess it's possible someone can construct a URL that will maliciously buy me books or whatever. -- Steve Alexander Software Engineer Cat-Box limited
participants (6)
-
Bill Anderson -
Dieter Maurer -
Kyler B. Laird -
marc lindahl -
Steve Alexander -
Thomas B. Passin