WebApp Sec mailing list archives
RE: Controlling access to pdf/doc files
From: "Noah Gray" <ngray () lightport com>
Date: Thu, 26 Feb 2004 11:14:08 -0500
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 () 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
Current thread:
- RE: Controlling access to pdf/doc files, (continued)
- RE: Controlling access to pdf/doc files GRIFFITHS ian (Feb 25)
- RE: Controlling access to pdf/doc files Alistair Meikle (Feb 26)
- Re: Controlling access to pdf/doc files Mark Curphey (Feb 26)
- RE: Controlling access to pdf/doc files Sangita Pakala (Feb 28)
- Re: Controlling access to pdf/doc files David Cameron (Feb 28)
- Re: Controlling access to pdf/doc files (db "better" than filesystem?) David Wall @ Yozons, Inc. (Feb 28)
- Re: Controlling access to pdf/doc files (db "better" than filesystem?) Ido Rosen (Feb 28)
- RE: Controlling access to pdf/doc files Sangita Pakala (Feb 28)
- RE: Controlling access to pdf/doc files GRIFFITHS ian (Feb 25)