From: David Cameron (daviduberconcept.com)
Date: Sat Feb 28 2004 - 07:35:15 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Why is storing the data in the BLOB a good solution? From what I can see
the only advantage of this is that it takes it off the file system. How
is this any different from moving the files to a location in the file
system that is not accessible from online? A little obscure, not
necessarily any more secure.

In SQL Server (can't comment on other platforms) BLOBS perform poorly
and a real PITA to extract and work with, so why store files in the db?
It may be easier with other platforms, but I'd be surprised if that is
the case. In a nutshell the reason they perform badly in SQL Server is
that in SQL Server is that all data in SQL Server is split over ~8k
pages. When you add a BLOB it needs to be split into 8k chunks. When you
retrieve it needs to be reassembled. Hence the performance problems. If
other database follow the same design for storing data you are going to
run into the same problems.

regards
David Cameron

Sangita Pakala wrote:
> Hi All,
>
> Thanks a lot for all those ideas that we received on and off the list.
>
> The best way to handle this issue seems to be by storing the file in the
> database as a BLOB. Use data streams to display it on the browser after
> checking that the user is an authenticated user and the session is
> valid.
>
> The other solutions involved placing the file outside the web root and
> using file system permissions or authorization modules or generating the
> files on the fly.
>
> Thanks,
> Sangita.
>
> OWASP AppSec FAQ
> http://www.owasp.org/documentation/appsecfaq
>
> Paladion Networks
> http://www.paladion.net
>
> -----Original Message-----
> From: Mark Curphey [mailto:markcurphey.com]
> Sent: Wednesday, February 25, 2004 2:50 AM
> To: Sangita Pakala; webappsecsecurityfocus.com
> Subject: Re: Controlling access to pdf/doc files
>
> Why does it need to be a file ?
>
> I would approach this by storing the data in an object and streaming it
> to the browser after having made an authorization check. Check the
> session context, call the method and read the data from the users
> object. Then stream it to the browser. No need to cache it in a file.
> Bad for performance and security.
>
> As always designing better solutions is cheaper than fixing bad ones ;-)
>
> ---- Sangita Pakala <sangita.pakalapaladion.net> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]