Common Authorization Vulnerability in Thick Client applications

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...

        }

     }