RE: Controlling access to pdf/doc files

While the streaming route may seen far more 'elegant', in that no file
is created, and is more efficient/scaleable because of the reduced IO,
one should also consider the added expense for limited-bandwidth users.

Bear in mind that Acrobat rarely makes straight GET requests. It most
always requests a range of bytes (RFC 2068 HTTP 1.1, subsection 14.36)
that only pulls back what the current page requires to be viewed. And if
a user scrolls to the next page, or the 50th page, it'll request byte
ranges from the server until it gets what it's looking for.

Using these suggestions to 'just write the headers' and 'stream the file
back', you're ignoring what the client is asking for. Even if the app
environment (.Net, JSP, etc) is smart enough to take your stream and
only hand the client the partial content they're asking for, your
component/page will still get hit every request for partial content. If
you're really concerned with scalability, these subsequent calls can't
be overlooked.
And if the app server doesn't do the 206 work for you, you're ignoring
your client's request, and tying up their connection for something they
didn't ask for. Another example of code that will run great on your
network, and poorly (realistically only for large files) on their
computer. Leading to delightful conversations such as "why do PDF's come
down so slowly on your site, but not others?".

My recommendation is to stick with file-system access using some of the
practices well-debated in previous articles. This streaming problems are
only more amplified if you ever need to secure htm files that reference
gif's, or PDF's that link to other PDF's, which happens to be my
reality.
 
Noah Gray
Application Developer
LightPort

-----Original Message-----
From: lists AT dawes DOT za DOT net [mailto:"lists AT dawes DOT za DOT
net"@securityfocus.com]
Sent: Wednesday, February 25, 2004 3:07 AM
To: Sangita Pakala
Cc: webappsec_at_securityfocus.com
Subject: Re: Controlling access to pdf/doc files

Do not allow direct access to the file itself. Create the file
dynamically, or read it from a location outside the web root, via a
servlet/app that checks the validity of the session.

It is not difficult to supply headers to indicate the
content-disposition, which tells the browser to try to save the file,
and can even provide a useful file name, rather than the name of the
servlet.

Rogan

Sangita Pakala wrote:

> Hi,
>
> Could I have the list's thoughts on an answer we are preparing for the
> next version of the AppSec FAQ at OWASP.
>
> Question - How can I ensure my application allows only authenticated
> users access to files like *.pdf or *.doc?
>
> Issue - Suppose a web site, say a bank site, displays the user's
account
> statement as a .doc file. What if someone tries to access this file by
> typing its full URL into the address bar? How does the application
check
> whether the user trying to access the file is the authenticated user
and
> that the session has not expired?
>
> Solution - One solution is to have a random number for the name of the
> file or the folder containing it. This random number could even be
> related to the session token of the user. This file/folder should then
> be deleted as soon as the user's session has expired.
>
> Are there better methods available to address this issue? Can the web
> server run a server side program to verify the session token before
> serving the final GET request for the file?
>
>
> Thanks,
> Sangita.
>
> OWASP AppSec FAQ
> http://www.owasp.org/documentation/appsecfaq
>
> Paladion Networks
> http://www.paladion.net
>
>
>
>
>
>
>
>

-- 
"Using encryption on the Internet is the equivalent of arranging an
armored car to deliver credit card information from someone living
in a cardboard box to someone living on a park bench."
- Gene Spafford