Possible BIG bug regarding security

[keystrokes]

I have a number of projects set up. With a core or the saem users at my office. At each project site, the project manager from the client end is able to log in and see their projecty and task only - that works well.

The problem is upon updating a task, it has emailed the task assignee. but th elink in the email takes them to a compleely different task with a different project, one they should not have access to. This is such a breech of security, I have turned off emailing altogether.

Is this a known issue?:confused:

[keystrokes]

On further investigation I disvovered the task the email is linking to is number 14 when it should be 144. Note from the email below the link is wrapping around so only the first two digits of the link is valid.

Project: Shiplake Implementation
Task: Installation
Start Date: 27/03/2006 09:00 am
Finish Date: 27/03/2006 05:00 pm
URL:
http://projects.keystrokes247.co.uk//index.php?m=tasks&a=view&task_id=14
4

Description:
To carry out installaion of the softtware ordered.This could be carried
out on-site by ourselves or a third party or by a remote connection. The
choice remanes with Serco and is dependent upon resources.

I will search the forums for this issue a little further, but any URGENT advice would be appreciated, i.e. which file do I need to look at.

Regards

Lloyd

[keystrokes]

Think I have fixed this, line 732 in \modules\tasks\tasks.class.php has the following

$body .= "\n".$AppUI->_('URL').": {$dPconfig['base_url']}/index.php?m=tasks&a=view&task_id=$this->task_id";

by taking out the spaces helps the email from wrapping around and leaves the link intact.


$body .= "\n".$AppUI->_('URL').": {$dPconfig['base_url']}/index.php?m=tasks&a=view&task_id=$this->task_id";

[caseydk]

Even if the link is pointing at the wrong task, they won't be able to view the task unless they have permissions. Therefore this creates a bad experience for Users... *not* a security problem.

[keystrokes]

Even if the link is pointing at the wrong task, they won't be able to view the task unless they have permissions. Therefore this creates a bad experience for Users... *not* a security problem.

I beg to differ, even though the task was for a different client, and should not have been able to access the link, they were able to!!!:(

In fact log in as someone who can only access one project and/or task. click on a task and then edit the URL in the address bar to point to any task number (not associated with this particlar project), the task WILL appear.

If you want I can set you up on my site if you want so you can test it, send me you email address by PM

Regards

Lloyd

[cyberhorse]

Are you sure you haven't given users access to other companies though? permissions in dp are inherited (for good or bad)

[Logicology]

In confirmation of Keystrokes findings:

If I setup a user with permissions only to ProjectA and CompanyA, if I edit the URL to a task for ProjectB it is displayed without error.

I'd say this is a security hole.

[cyberhorse]

what roles have you given that user though?

[keystrokes]

what roles have you given that user though?
Project Worker

[cyberhorse]

Project worker has full permissions on pretty much all modules:
Non-Admin Modules:
* Access
* Add
* Delete
* Edit
* View

This means he'll be able to see pretty much anything (except system administration and user administration). This is not a bug.

Look at real world example as to how to setup permissions properly (there were a couple of posts about this in the last week - also look at the documentation wiki).

[keystrokes]

Project worker has full permissions on pretty much all modules:
Non-Admin Modules:
* Access
* Add
* Delete
* Edit
* View

This means he'll be able to see pretty much anything (except system administration and user administration). This is not a bug.

Look at real world example as to how to setup permissions properly (there were a couple of posts about this in the last week - also look at the documentation wiki).

Sorry I mislead you, I noted this in the earlier days of setting up. I deleted the role of project worker and created one called 'project_staff' which has....

Files Access - allow
*Add
*Edit
*View

Tasks Access - Allow
*View

Task Logs Access - Allow
*Add
*Edit
*View

In addition to this, each user is only allowed to see their own company and own project. i.e.

Shiplake College Access -allow
*View

Shiplake Implementation Access - allow
*Edit
*View


Is there something obviously wrong with these permisions? It is these permissions that is letting ANY user to edit the url to ANY task.

If I have to further deny permission on an invidual task basis, this would take hours to set up each project and each new member of staff as I have currently five projects in the system with about 3 to 4 new/additonal ones every month. Each prjoct will have in the region of 20 tasks. Also each task s the same name with in each project, i.e. book training will be the same in eash project, so when trying to resrtict user to specfic tasks the task list appears as...

Book Training
Book Training
Book Training
Book Training
Book Training
Book Training
Book Training

etc so which is the correct task to allow or deny?

Regards

Lloyd

[keystrokes]

Anyone ???

[cyberhorse]

dotproject's permissions hierarchy is unconventional at times (and one I don't necessarily agree with). I think giving view permissions to a company, allows view access to everything under it. Try to enable only access permission to the company and remove view.

Haven't looked deeper into the new permissions to give you a 100% correct answer, but if the suggestion above doesn't work either, please do log it as a bug on mantis with "critical" priority and we'll have a look at it in more details as soon as we can.

Thanks for helping us resolve this issue.

[caseydk]

Giving someone access to a company gives them access to all projects (and tasks) beneath it by default.

You can then go on to deny access to individual Projects (and Tasks).

I suspect this is your problem.

[keystrokes]

Giving someone access to a company gives them access to all projects (and tasks) beneath it by default.

You can then go on to deny access to individual Projects (and Tasks).

I suspect this is your problem.

Thanks for this, but this is not he problem here, as each company has one project. The problem is that the url can be edited to a different taks number. I have tried with ALL kinds of security settings, but it ALWAYS allows me to view the task to the number of the one I edited in the url. In other words once you are logged in, you can have back door access to ANY task (even though it does not belong to your company or even project), so long as you edit the URL accordingly.

As suggested I will add this to Mantis as a issue.

Thanks again

[cyberhorse]

this shouldn't be a problem. At the top of the view/edit task pages, there is this code:
<php>
$canRead = !getDenyRead( $m, $task_id );
$canEdit = !getDenyEdit( $m, $task_id );
...
if (!$canRead) {
$AppUI->redirect( 'm=public&a=access_denied' );
}
</php>
Which should kick out anyone that doesn't have privileges to the particular item to be seen. That is why we've been trying to suggest reviewing the permissions you've set, as the getDenyRead etc functions have been tested many times before and it is unlikely (however possible) there is a problem with them.

[keystrokes]

If I have to further deny permission on an invidual task basis, this would take hours to set up each project and each new member of staff as I have currently five projects in the system with about 3 to 4 new/additonal ones every month. Each prjoct will have in the region of 20 tasks. Also each task s the same name with in each project, i.e. 'book training' will be the same in each project, so when trying to resrtict user to specfic tasks the task list appears as...

Book Training
Book Training
Book Training
Book Training
Book Training
Book Training
Book Training

etc so which is the correct task to allow or deny?

Regards

Lloyd

So I have to deny permissions to every single task in the system for the users. so I have 7 projects (currently) each with 25 tasks. If my understanding is correct, then I have to deny permission for 6 * 25 (125) tasks for each of the 25 users???? Further more each proejct has the same structure of tasks so as above Book Training appears as a list (as above) when trying to deny a task; which is the correct tass to allow/deny as the list does not give any indication as it is across the projects:(

If this IS the case then I must also reminder to edit every user every time I add another project:confused:

A side issue is that even though the user is restricted to their own project and tasks, they can still see ALL users that are set up in the system on a particular screen - the users task list screen where they can add users to the task, those users belong to other projects.

I will upload a screen shot later and add a link here maybe this needs to be split off and new post started?

[cyberhorse]

no, that is not correct. the getDenyRead and getDenyEdit functions look at permissions hierarchically. If you have given read access to a company, all tasks underneath will have it, but if you don't have read access to a company, neither will the tasks. Please read more documentation on how permissions work in dp before you make further assumptions.

[keystrokes]

no, that is not correct. the getDenyRead and getDenyEdit functions look at permissions hierarchically. If you have given read access to a company, all tasks underneath will have it, but if you don't have read access to a company, neither will the tasks. Please read more documentation on how permissions work in dp before you make further assumptions.

Sorry Cyberhorse, I think you may have mis-understood. I have the system set up the way you have described. The issue is that other users from other projects can get access to tasks they should not. I was reading from your previous posts that I should then deny access to those tasks that that user is not allowwed to see from other projects, which would be impracticle gien the total number of tasks in the system.

I think the only way forward on this is to rasie an issue in Mantis and then let a developer into my set up to show exactly what I mean and to experience the issue for themselves.

Kind regards

Lloyd

[zman818]

Has there been any headway on this? This still appears to be a significant issue; one that I've confirmed (unless someone can point to a change in my permissions configuration that doesn't involve some giant permutation of settings....)

Company Prime has Project A, Tasks 1 2 and 3
Company Sub has Project B, Tasks 4 5 and 6

User 'Client' has client role permissions (nonadmin view/access allow) and the following specific permissions:

All Companies, AAEDV, Deny
Company Sub, AAEDV, Allow

If I log in as 'Client', I see only Company Sub, Project B and Tasks 4,5 and 6. However, if I spoof the URL and modify the task # parameter, I can effectively view Tasks 1, 2 and 3 -- a clear security violation.

Even if I specifically deny 'Client' AAEDV access to Project A, I can still see Project A's tasks by spoofing the URL.

What I *cannot* do is spoof the project ID. If I try to view Project A, I get the permission denied text.

It seems like DP's permissions model doesn't run down the tree deep enough to determine if the task is out of permission scope.

Please let me know if I'm missing the big picture here.. Thanks.

- Mike

[gb5256]

The settings of the permissions is a hard thing as it looks like...

The problem you all discuss is definitely not a securtiy hole but that there are wrong permissions.

First case: Wrong permission in the Permisssion-Settings of the user.
Second case: Wrong permission in the Permission-Settings of the role.
Third case: Wrong settings in both (Worst case...)

No other cases possible.
No security holes as the program checks for each company/project/task... if the logged in user has the appropiate rights. If the program shows a non-allowed site, the settings are wrong.

If the permissions are set up correctly you can not edit the url withot getting a deny-access-page.

gb5256

[zman818]

No other cases possible.


I must beg to differ. There is no such thing as perfect code, and bugs are always possible. I'm not stating that this is 100%, without-a-doubt a bug (though it sure looks like it), but I certainly wouldn't be so bold as to state that it couldn't possibly be one.

Perhaps you can identify exactly where my permissions settings are flawed. I provided exactly what I have set, and these were set based precisely upon the Best Practices models discussed both in these forums and in the wiki.

Again, in a nutshell -- I have explicitely denied ALL access to ALL companies for a given user. I have then allowed ALL access to ONE company for that same user. I can then log in as that user, modify the URL and view tasks for a different company's project. Please tell me how that is expected behavior.

- Mike

[gb5256]

Please give me the follwoing inforamtions:

What versions do you use of:
-DP
-PHP
-MYSQL
-SERVER

gb5256

[zman818]

Please give me the follwoing inforamtions:

What versions do you use of:
-DP
-PHP
-MYSQL
-SERVER


2.03
4.4.2
4.1.18 standard
Apache 1.3.34

Not sure where you're going with this. Do you think that there's a software incompability that would allow permissions to work perfectly when dealing strictly with the provided UI, but allow a spoofed URL through?

Have you actually tried setting up the scenario I spelled out and confirmed that the problem *doesn't* occur for you?

In the interest of meeting the flat-earthers more than half way on this, I'll be setting up a public stock DP installation shortly with the minimal amount of data to replicate the problem. I'll post the site info shortly.

[gb5256]

Let me guess:
All your tasks are set to access PUPLIC, right?
(I dont mean at the permissions or rules pages, I mean at the edit-tasks-view)

Puplic means that everybody can access the task if somebody has the right to view tasks (even if the one has a deny on that project or company).

I set alle the tasks to participant (i modded that it uses this as default).
That ensures, that nobody sees the task until i assign him.

Actually the access-option on the task-edit-page is very usful, because so people with no rights to the admin-modules and user-modules can choose if everybody (puplic), nobody (private) or participant and protected-mode should occur.

Was this the help you needed?
Please try to set a task to a non-puplic status and try to cheat the url to get to this task with your mentioned user.
Please let me know what happens...
gb5256

[keystrokes]

Let me guess:
All your tasks are set to access PUPLIC, right?
(I dont mean at the permissions or rules pages, I mean at the edit-tasks-view)

Puplic means that everybody can access the task if somebody has the right to view tasks (even if the one has a deny on that project or company).

I set alle the tasks to participant (i modded that it uses this as default).
That ensures, that nobody sees the task until i assign him.

Actually the access-option on the task-edit-page is very usful, because so people with no rights to the admin-modules and user-modules can choose if everybody (puplic), nobody (private) or participant and protected-mode should occur.

Was this the help you needed?
Please try to set a task to a non-puplic status and try to cheat the url to get to this task with your mentioned user.
Please let me know what happens...
gb5256

Thank you, thank you, thank you, thank you, thank you, thank you, thank you,


and once again, thank you. You have finally solved this.

Months and months of developers telling me I was stupid and advising me it was user/project/task permissions I had set up wrong and you are the only person who has advised correctly. The way I had the permissions et up WAS correect, I was not being stupid, so ALL developers please take note.

I would strongly suggest that (as you have already done) that this setting should be defaulted to participate.

Can you advise me on the modded code to get this to default this way.

Once again, thank you.

[zman818]

I agree. Thank you VERY much. I haven't had a chance to test this, but as soon as you made mention of the Public task setting, the lights began to click on.

While I'm not sure how intuitive it is to have such a fractured level of security, that's beyond the scope of this. You information is most appreciated (and I'm sure at some point having such a fine degree of security control at the task level will probably come in handy).

keystroke -- I'll post a mod to change the default asap, assuming no one beats me to the punch.

Again, a BIG thank you gb.

- Mike

[pedroa]

I was not being stupid, so ALL developers please take note.


You got to be kidding me... all this fuzz and all the problem you had was a darn task access issue...

Let me say that again:

Thank you, thank you, thank you, thank you, thank you, thank you, thank you gb5256 for helping this poor souls... I must go on vacation I see problems worse than they are already...

(BTW: nice way of noting the developers stupidity, I sure do my part, thank you.
No offense taken, I just like a good joke :) )

Pedro A.

[keystrokes]

(BTW: nice way of noting the developers stupidity, I sure do my part, thank you.
No offense taken, I just like a good joke :) )

Pedro A.

No problem, I was pulling my hair out over this one.

Special thanks to 'Casey' as Keith took time to pm me and advise me, although his advice did not work as he was refering to roles type permissions, but thanks for everyone who did contribute in someway.

[zman818]

You got to be kidding me... all this fuzz and all the problem you had was a darn task access issue...


Actually, I think the bigger issue was the lack of clarification regarding the impact of task-level permissions and how they can supersede what would otherwise be a very clear deny permission set at the user/role level.

But hey -- that's why there are no bad questions. If people keep asking, the answer will eventually reveal itself one way or another (despite the smug self-righteousness that unfortunately seems to permeate some of the posts around here...)

Of course now I can no longer access the tasks (other than the list view) when I'm on as the client.... but I'm sure a little fiddling and I'll resolve that one, lest I receive a verbal thumping from the DP Intelligencia. :)

fyi, someone DID beat me to the punch a few months ago...

http://www.dotproject.net/vbulletin/showthread.php?t=4497&highlight=participant

[gb5256]

I dont now if I can stand so many "thank you"s without starting to cry

...snief

If anybody wants really to say thank you, then donate to DP.
(I'm not a developer so I will not get the money...)
They did (and still do) such a good work with this software.

:-D

GB5256

[pedroa]

If anybody wants really to say thank you, then donate to DP.
(I'm not a developer so I will not get the money...)


As a matter of fact I did back in August 2005
BTW: I am a developer and I am getting none either, so don't worry, if you don't like me you can still donate :)

http://sourceforge.net/project/project_donations.php?group_id=21656

(pedroix)
Pedro A.