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. |

| Subject: | RE: Securing file access |
|---|---|
| Date: | Mon, 4 Oct 2004 14:45:21 +1000 |
Hi Chad,
Of course the problem isn't that it refers to the real file but that it
could be used (if it isn't validated properly) to delete any file on the server.
<input type="hidden" name="remove_file"
value="..\..\..\autoexec.bat" />
So the solution is to validate it for any path manipulation. Of course,
it's far easier just to read in the file and write the bytes out like other
posters have suggeted.
-- Michael
-----Original Message-----
From: Beckner, Chad A [mailto:cbeckner@iupui.edu]
Sent: Friday, 1 October 2004 8:44 AM
To: Calderon, Juan Carlos (GE Commercial Finance, NonGE); Shields, Larry;
webappsec@securityfocus.com
Subject: RE: Securing file access
Remember, this would be only the temporary file that was sent to the user, NOT
a link to the actual file. Per the example I used, here is a variable that
could be used:
<input type="hidden" name="remove_file" value="adobe.pdf">
Your processing script(s) would point to the file in the temporary file
location, such as:
wwwroot\_common\_temp_file_cache\adobe.pdf
It would never "touch" the "real" file.
Chad
-----Original Message-----
From: Calderon, Juan Carlos (GE Commercial Finance, NonGE)
[mailto:juan.calderon@ge.com]
Sent: Thursday, September 30, 2004 5:15 PM
To: Beckner, Chad A; Shields, Larry; webappsec@securityfocus.com
Subject: RE: Securing file access
Importance: High
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
--
This email message and accompanying data may contain information that is
confidential and/or subject to legal privilege. If you are not the intended
recipient, you are notified that any use, dissemination, distribution or
copying of this message or data is prohibited. If you have received this email
message in error, please notify us immediately and erase all copies of this
message and attachments.
This email is for your convenience only, you should not rely on any information
contained herein for contractual or legal purposes. You should only rely on
information and/or instructions in writing and on company letterhead signed by
authorised persons.
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | alternate (new?) web app exploitation angle--too much coffee version, Evans, Arian |
|---|---|
| Next by Date: | RE: Hacking/security in main-stream media, Skander Ben Mansour |
| Previous by Thread: | RE: Securing file access, Adam Tuliper |
| Next by Thread: | Re: Hacking/security in main-stream media, Edward Miller |
| Indexes: | [Date] [Thread] [Top] [All Lists] |