Securing Documents in Web Applications

By Paladion

November 15, 2005

More and more sensitive information is being published online everyday. This data could be in the form of simple HTML pages or Adobe's PDF or Microsoft Word formats. Here we discuss how we can ensure that data sent in either of the forms remains protected and available only to the authenticated user

More and more sensitive information is being published online everyday. This data could be in the form of simple HTML pages or Adobe's PDF or Microsoft Word formats. Access to this data is provided to users after they have been duly authenticated and authorized. However, under certain implementations it is possible for an adversary to realize the following threats:

  1. Gain access to data without logging into the website
  2. Gain access to other user’s data after logging in as a valid user

For example, the account statement of a bank customer should be available to him only and no other customer should be able to view it. Also, access to the account statement should be possible only after the customer has logged into the bank’s website. In some cases, we have seen that it is possible to violate these rules.

Current Scenario

A widely adopted approach is to put all the protected documents (Word, PDF, etc.) in a folder which is accessible over the web, without publishing a link to the document openly.

Once a user has logged into the application and requested a file which he is authorized to access, he is redirected towards this folder.

When the application redirects the user, a new request is sent from the browser to the web server, requesting the document. The request contains the URL to reach the document directly. The threats to this approach are:

  1. An authenticated user may be able to access the documents of other users. The user can guess the document names of other users and upon requesting, the same will be displayed to him.
    Let's assume, user A has access to document a.pdf and user B has access to document b.pdf. If user A requests for the document b.pdf by typing its exact location in the browser, the same will be displayed to him. By analyzing the redirection request that got him a.pdf, it is trivial to figure out the request to get b.pdf
  2. Any user might be able to directly access the URL of the documents even without logging in.
  3. A web spider tool will be able to access the documents as the document is stored in a web accessible folder.

The Solution

Store the documents in the database as a BLOB; do not store it in a publicly accessible folder. When a user requests for a document, the request is processed by the application. The application first checks if the session is valid and then verifies that the user who is requesting is authorized to access the document.

The application then retrieves the document from the database, constructs the HTTP response and sends it to the browser. The appropriate CONTENT-TYPE header is set so that the client browser can display the document by invoking the correct plugin.

For example, send the header Content-type: application/pdf when sending a PDF document to the user.

  1. If a user is not authenticated, the application will not serve the content.
  2. Authenticated users will not be able to view documents of other users. Their requests will be checked for authorization before the application serves the content.
  3. Documents will be served much faster as there is no extra step for redirecting the user to the document.

This security issue was discussed in the Web App Mailing list in February 2004.

Tags: Technical