The What, Why and How of Software Security : Authorization

How To: Configure permissions in Out-of-the-box MOSS 2007 Approval Workflow such that “Approvers” cannot edit or delete the item to be approved

Varun Sharma — Mon, 04 Aug 2008 14:01:27 GMT

1. Consider a Microsoft Office SharePoint Server 2007 site that will be used as a “Document Approval System”. Certain users will be “Editors” and they will be able to upload documents for approval. Another set of users will be “Approvers”. These users can either approve or reject the uploaded documents. The security requirement is that “Editors” should not be able to approve the documents and the “Approvers” should not be able to edit or delete the documents.

2. Create a document library where the documents will be uploaded.

In this document library, create an Out-of-the-box MOSS 2007 Approval Workflow. In the “Select a task list to use with this workflow”, select “New task list”.

3. In the text box for “Approvers”, add the windows group that will contain all the “Approver” users. Also so that an editor cannot change this “Approver” group at the time the workflow is being created, uncheck the “Allow changes to the participant list when this workflow is started” checkbox.

4. As you can see a new task list is created for this workflow.

5. Give Contribute permissions on the site to the windows group that will contain the “Editors”.

This group can now add, edit and delete items from lists.

6. Now login as an “Editor” and upload a document.

Start the workflow on the uploaded document.

As you can see the approvers text box is disabled.

Once the workflow is started, a task is created in the task list specific to this workflow.

7. Let us see what happens if the “Editor” tries to approve the document herself.

We are trying to approve a workflow logged in as an editor.

The “Editor” will get an error message and the following will be added to the workflow history.

8. Now login as the “Administrator” and create a new permission level for the “Approver”. Give this permission level, edit items, view items, open items, view versions and view application pages permissions.

9. Create a new Share Point group for workflow approvers. Give it read permissions on the site.

Give the same group edit permissions on the workflow task list (that was specifically created for the approval workflow) using the “WorkflowApprovalPerm” permission just created.

The Share Point group “Workflow Approvers” now has the following effective permissions on the site. Effectively it has read-only permissions on the entire site, but “edit” permissions on the task list specific to the approval workflow.

10. Add the windows group containing all the approvers to this “Workflow Approvers” Share Point group.

11. Now login as an “Approver”. Go to the document library. See that the approver can neither edit nor delete the uploaded documents.

12. Go to the task created for approval. Try to approve it.

As you can see the “Approver” is able to approve the document.

Summary:-

This “How To” shows that it is possible using the out-of-the-box MOSS 2007 approval workflow to create a document approval system where

1. The “Editors” can only upload documents to be approved but cannot approve the documents themselves.

2. The “Approvers” can only approve or reject the documents but cannot edit or delete them.

Catch the Security Flaw #3

Varun Sharma — Mon, 14 Jul 2008 13:17:49 GMT

Quite a few web applications encrypt query string values. This is generally done as an added measure to prevent unauthorized access. Since the end user cannot chose a value and then encrypt it, changing parameters becomes difficult. But encryption is not a panacea. See if you can spot this bug.

The code behind file looks like this:-

Implementation for the Encrypt and Decrypt methods is not shown. They are using the DES algorithm. There is no flaw in the usage or key management.

The end user can upload files and the screen look like this:-

On clicking Upload, the file gets uploaded and a message is shown. Note the query string values. The HTML source is also shown.

Do you think the code or design is flawed in any way? Can this be exploited?

Common Authorization flaw in Web Applications: Why disabling buttons (or other controls) is not enough?

Varun Sharma — Tue, 22 Jan 2008 23:24:00 GMT

I have seen quite a few web applications that rely on disabling controls for authorization. Consider this code:-

The scenario may be that the page has to be displayed in a read-only manner for certain roles, or after submission of some details but prior to approval (in a workflow). This reason depends on the business requirement. In this dummy app, the page looks like this:-

This authorization can easily be bypassed. Without using any special tool, an attacker can just enter script this way in the address bar and hit enter:-

Now the attacker enters some text and hits the submit button, completely bypassing the authorization control:-

Countermeasure:-

Check the condition in the event handler before taking action.

Common Authorization Vulnerability in Thick Client applications

Varun Sharma — Wed, 31 Oct 2007 14:55:00 GMT

Consider the following architecture for an intranet application. A thick client installed on the user’s machine connects to a web service which in turn connects to the database. The web service authenticates the caller using windows authentication. It connects to the SQL Server using a fixed identity.

The vulnerability occurs if authorization controls are built into the thick client only and not in the web service. The user can easily bypass these authorization controls by directly accessing the web service. This means that any domain user in intranet can call web methods in the web service which may result in loss of integrity and confidentiality of the data.

Example of vulnerable code in the thick client

// Thick client code

// Create instance of web proxy class

Service service = new Service();

service.Credentials = CredentialCache.DefaultCredentials;

// Check if user is admin in the application

if (service.IsAdmin())

{

// If yes, approve the request

service.ApproveRequest(100);

}

else

{

// User is not authorized...

}

A malicious user can bypass the thick client and call the ApproveRequest web method directly, since it doesn’t authorize.

A proper design would ensure that authorization takes place in each of the web methods in the web service based on the windows identity of the user. The thick client only represents the user interface and may implement authorization controls only for aesthetic and/ or performance purposes.

This is an example of how the web service should authorize the caller

// Web service code

[WebMethod]

public void ApproveRequest(int RequestId)

{

// Check if the calling user is in admin role

if (User.IsInRole("Admin"))

{

// If yes, approve the request

new Request(RequestId).ApproveRequest();

}

else

{

// User is not authorized...

}