Bugs item #1415166, was opened at 2006-01-25 22:37
Message generated for change (Settings changed) made by tdonohue
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=119984&aid=1415166&group_id=19984

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Larry Stone (lcs8)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing Access Control in WorkSpace, WorkFlow objects

Initial Comment:
The WorkspaceItem and WorkflowItem objects do not have
real access controls at the "business logic" level. 
This lets application-layer code manipulate them in
ways that should not be authorized.  

Perhaps it has not been noticed because the Web UI does
a good job of hiding unauthorized actions from the user
so they are never given the chance to request them. 
However, if you manually invoke a servlet to e.g. claim
a workflow item you would not normally be authorized
for, it succeeds.

This problem is greatly exacerbated by the Lightweight
Network Interface, since its workspace and workflow
interfaces make it easy to attempt forbidden
operations.  Even though users only see their own
workspace and workflow objects, they can guess at other
objects by trying database IDs and get access to them,
so it is 
a real security risk.

I'm willing to implement and test true access controls,
but I would like someone who knows more about the
original design intention of the workspace and workflow
mechanisms to propose what the access controls _should_ be.

To demonstrate this problem most easily, use a
command-line WebDAV client like cadaver (see
www.webdav.org) and a DSpace instance with the LNI
installed.  Have one user enter an item into workflow
and get its ID by listing /dspace/dav/workflow; it'll
be a URI like /dspace/dav/workflow/wfi_db_23.  Then
start another cadaver session logged in as a different,
non-Admin user, who has no access to that workflow
item.  Manipulate it by setting the "state" property
to e.g. "claim", "advance", etc, and observe that
it succeeds.  You can push someone else's item all the
way through workflow and get it archived.


----------------------------------------------------------------------

Comment By: Larry Stone (lcs8)
Date: 2006-01-25 22:41

Message:
Logged In: YES 
user_id=1194445

I think bug #1358131 is related to this one and would be
fixed by the same solution.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=119984&aid=1415166&group_id=19984

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to