Vulnerability View Access Information

[ROSANA]

Hi,

I am watching the security's dotProject and i have a problem with the next vulnerability.
I have many open projects. I create a user that can only see all information about 1 project.
Everything works perfect, the user can see only what I set for him.
When the user log on, he write in the direction bar (in internet explorer) the the next sentence:
http://server/dotproject/index.php?m=public&a=selector&dialog=1&callback=setPermItem&table=files

and he can see the list of all files from all project!!! he can see the list, but he can not open them.
if you change files for users, he can see all users of the system.

But more terrible now, all user have this problem. Anyone of them that log in in dotProject can see the list with that sentence in the browser.

How can I fix this problem?????

Thank you very much.
Rosana.

[pedroa]

The selectors are publicly available (you are pointing your browser to the public module, remember that).
Fixing this "problem" is as easy as conceptually determining what should be the permissions attitude for the public selectors, shouldn't they be public?
What I mean is (take the following example):
Someone has the right to create projects, but he also does not have the right to see contacts, so what do you think, should he not be able to add contacts to the project? or assign users to that matter? or departments? think about it and let me/us know...

Pedro A.

[ROSANA]

pedro A., thanks for your fast answer.

I really dont know how to solve the "problem".

I define a role project "Project client". This role has a Task permission set to Access and nothing else.

Later, in the user permissions I define:
* His company: View allow
* Companies: view deny
* His project: View allow
* Projects: View deny
* Tasks: View allow

I log in with that user and later, i write in the browser
http://servidor/index.php?%20m=public&a=selector&dialog=1&callback=setPermItem&table=files
and I can see all files from all project.

I understood that in roles, i only set the the templates the users group will have. Later in user permissions i will stablish exactly where they can work or not. Tell me please if this is right.

For the other side, all user in dotproject, using the sentence described above, can see all file's projects (and users). What am I doing wrong???

Excuseme by my english, my native language is spanish.

Thanks again.
Rosana.

im sorry, i fogot to tell you that if i set permissions for "his task" (is only one) and deny for the others, they appear a mistake in the log on. The same happens with setting permissions for files.

[pedroa]

Like I told before, public selectors will let you see names, but won't let you do anything you shouldn't be able to do (rather than viewing).

What I was trying to say also is should you cripple the users possibility to add data from those selectors to actions you are permited?

You must first understand what these selectors are and then rethink if it is a problem or not.

There is no difficulty in having permissions affect the selectors, but then again you should think if your permissions will not remove the possibility of the users actually work.

Pedro A.

[Wendebaum]

but it's a valid point that in these selectors there is data shown which is not filtered by security, so sensitive information COULD be listed.

Maybe this should at least be pointed out clearly in the docs.

Jochen

[ROSANA]

I really have a problem here, because i need that the client enter in dotproject to see some information. But i have different clients for each project, and i dont want that they see the names of the files. Thru their names, they will know the other projects the company have. But, for the other side, is possible to see all user names, think about that!!

I prove to do the same in the demo page , but this information didnt appear. What kind of setting should I make???

Thanks.
Rosana.

[pedroa]

I did misunderstand this whole thing, sorry.
I guess I am working too much...

I really didn't see the whole link, and so I didn't see what file were we talking about.

The modules/public/selector.php does have some permissions checked upon access, FYI:
companies, departments and projects are protected.
(BTW: verify if it is so)

files, forums, tasks, users, contacts and SGD (?!?) are not protected.

Anonymous attacks can be easilly killed by testing $AppUI->user_id, if not present or 0 do a return (this means there is not active dP session). That would also kill this attack here (if the user was not logged).

But I guess further permissions checking should be applied to the refered unprotected tables, to stop attacks from logged users.

Sorry for not understanding this correctly in the first place...

Please post this in Mantis for me to have a look, thanks.

Pedro A.