Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

RE: Securing file access

Subject: RE: Securing file access
Date: Thu, 30 Sep 2004 18:15:16 -0400
woah!

Sending a path in a hidden field to remove a file in server doesn't sound good 
to me.  be carefull with this approach!


-----Original Message-----
From: Beckner, Chad A [mailto:cbeckner@iupui.edu]
Sent: Miércoles, 29 de Septiembre de 2004 09:09 p.m.
To: Shields, Larry; webappsec@securityfocus.com
Subject: RE: Securing file access


You could also copy the file to a temporary read-only directory, and run
an administrative script to clean out the temp directory every night,
hour, or even after the user has received the file (i.e. on the next
page hit using a hidden variable, such as "remove_file",
value="adobe.pdf").

- Chad

-----Original Message-----
From: Shields, Larry [mailto:Larry.Shields@FMR.COM] 
Sent: Wednesday, September 29, 2004 1:16 PM
To: webappsec@securityfocus.com
Subject: RE: Securing file access

 
        Be aware that the acrobat reader if using the IE browser plug-in
viewer has been known to have problems when using this method to send
PDF files.  We have seen common problems where users ended up with blank
documents or received errors about the PDF file not being correct.  From
what I've seen, the two solutions if you can't have this possible
failure are to either a) make customers all change their acrobat reader
configuration to start in "helper" mode (meaning kick off acrobat
external to the browser plug-in) or b) store things on the file system
and redirect the user to the PDF file.  Option b does have issues to
make sure it is done securely of course, such as clean-up of old files,
making sure that file names cannot be guessed or predicted by other
users, and that there is no potential for file naming collisions between
users.

-Larry

 
-----Original Message-----
From: Ian [mailto:webappsec2@fishnet.co.uk] 
Sent: Tuesday, September 28, 2004 5:05 AM
To: John M. L.; webappsec@securityfocus.com
Subject: Re: Securing file access

On 27 Sep 2004 at 11:57, John M. L. wrote:

I have a project that involves a members only area on web page on IIS.
The members' only area is secured by a database (MS Access) so users 
are authenticated by their name and some MD5 hash etc.  I need to 
allow files (mostly PDFs) for download to authenticated users only.  
In my opinion this means that the files can not be stored in any www 
accessible folder (regardless of any renaming convention etc, I 
absolutely cannot have someone guess a file name to download).  In 
order to access the files, the database would link a file to a unique 
id, so a page that validates the user would then give access to the 
file stored outside of the www on the server.  Now, this is where the 
real question lies.  How is this possible since the files are not in a
www accessible path, since a mere link to a file won't due.
Any thoughts would be welcome.  If I'm going about this completely 
wrong that would be nice to no too :)  Forgive me if the answer is 
simple, I'm a Linux fan and haven't used IIS etc for years.
One more note: IIS, MS Access and VBScript are not my technologies of 
choice, but merely what I was given to work with.  I also have very 
limited control over administering IIS.

John
www.recaffeinated.com

Hi John,

You are going about this the right way.

Store the PDFs outside the www root, but still give the user
ISR_<computer name> permission to read the files ( or whatever user your
site is running under).  Once the web user has authenticated, your
script can read the PDF into memory then stream the file to the user.  A
simple example is below:

<%

set fs=server.createobject("Scripting.filesystem")

set PDFin=fs.opentextfile(pathtoPDF,1,false)
PDF=PDFin.readall
PDFin.close
set PDFin=nothing

Response.contenttype="application/pdf"

resonse.binarywrite StrToBin(PDF)

response.end

function StrToBin(str)
        for x=1 to Len(str)
                StrToBin=StrToBin & ChrB(Asc(Mid(str,x,1)))
        next
end function

%>

You may not need to use the StrToBin function - I can't remember off the
top of my 
head ;)

Regards

Ian
-- 




<Prev in Thread] Current Thread [Next in Thread>