Protecting Download Links - Page 2
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 22

Thread: Protecting Download Links

  1. #11
    Senior Member
    Join Date
    Oct 2002
    Posts
    181
    The solution above would fool 99% of people but if they realy wonted to it can be done.

    One would do a download buy the normal means and read the HTTP headers to find where the server has sent you for the download.

    Because of the the way a webserver works the only real way to prevent people from downloading the file directy would be to place them in area which has to be logged into. As you have said this not an option.

    Another option is to encrypt the download, then force the user to ask for password. Place your tracker on that page.

    My final idea to this, would be to monitor the web server logs, to see how meny people request that page, you can get alot of information from the logs.

    hope this helps

    SittingDuck
    I\'m a SittingDuck, but the question is \"Is your web app a Sitting Duck?\"

  2. #12
    Senior Member
    Join Date
    Nov 2002
    Posts
    174
    SittingDuck...

    To give a an example of what I was doing, I simply had 2 ASP files called form.asp and dl.asp (which contained the code above). dl.asp simply checked for existence of form data and, when verified, started a direct stream to the file. The page loaded in IE when I got my download prompt was dl.asp, and the download prompt itself just gave me a file name. With the code above I could even change 'strFileSave' (the file name default for downloading) to be different from the actual source file's name).

    Given this scenario, wouldn't the http headers just contain the strFileSave name, and not the actual file name? In addition, even if the file name was kept the same, wouldn't the header just show the name and not the path?

    I would think that the workaround you allude to has been covered, but I've been wrong before (more times than I wish to admit). I could easily be missing something, but I'd like to know how the 1% would get around it. I'm no expert, so any light you can shed would be great! :-)
    Mike Reilly
    bluebeard96@yahoo.com

  3. #13
    Senior Member
    Join Date
    Oct 2002
    Posts
    181
    bluebeard96

    If you think about, how does the browser know where to download the file from?

    If the browser knows, then so can you.

    The address of the file must be inculded in the HTTP request so the server knows which file you are asking for.

    Example

    GET /download/file.exe HTTP/1.0

    It is this part of the HTTP request that will give away where the file is.

    You also said
    I'd rather throw a redirect in the processform.asp DIRECTLY to the file. Someone correct me if I'm wrong, but wouldn't that keep the actual path from being sent to the user?
    Sorry to say but you are wrong, a redirect will return a 301, 302 or307 page which in the http header will have the location of the new page, to get. Again how does the browser know where the new file is?

    Try looking at the problem from a different angle. IE is not the only thing that can get a webpage from a web server. Any program that can get a TCP/IP connection to the server, and send the correct information (ie http request, in the correct format) will get a webpage back. 99% of people don't relise that the only reason why you don't see all this extra information is that it is by hidden IE and other browsers. This does not mean that is has not been sent.

    As far as I can see no one has suggest using the web server logs to record the statisits(sp?) for the download, the point CXGJarrod makes is that people are bypassing their traker.

    I hope that clears things up a bit

    SittingDuck
    I\'m a SittingDuck, but the question is \"Is your web app a Sitting Duck?\"

  4. #14
    Senior Member
    Join Date
    Nov 2002
    Posts
    174
    My latter post strayed from the redirect. The code I found creates a stream of the file through the asp page, so the browser never needs to know the file location. If IE hides the header info, how can I see it (better yet, I'll search the archives and find out before I get negged for asking!)?

    I could definitely understand how a redirect would give this info to he browser (even most wouldn't be able to find the headers). With an asp file streaming the file and outputting the file into a new file (with an arbitrary name that the programmer can define), would the header contain any useful information? The comments by the original coder state this:

    ' Server File (this is the REAL name of the file)
    Dim strFile: strFile = Server.MapPath("saveme.gif")

    ' File to Save As (this is the name you want to tell the browser)
    Dim strFileSave: strFileSave = "saved.gif"

    ' Tell Browser what the file name is, so it doesn't try to save as "default.asp"
    Call Response.AddHeader("Content-Disposition","attachment; filename=""" & strFileSave & """")


    To me, the browser is only being sent information on the dynamically created new file... a file that was created with server side asp that the user is unaware of.

    Again, I could be wrong, but I think that dynamically recreating the file would not indicate to the user where the source was. The file the user is actually downloading is simply a stream of an asp variable... a variable that doesn't exist after the page is closed.
    Mike Reilly
    bluebeard96@yahoo.com

  5. #15
    Senior Member
    Join Date
    Oct 2002
    Posts
    181
    Ok lets start with the HTTP header, IE hides them, there is no option in IE to view them.

    so we use little program, which I posted here

    http://www.antionline.com/showthrea...threadid=237181

    in here is a program attached called achilles, which is an HTTP proxy, set your web browser to point to the proxy, and the proxy will capture all the HTTP information for you to view and modify. Then click send to pass the request on to the web server. Now wait for the responce to come back, and click send to pass it on to the browser.

    Have a play with it.


    Next,

    I have a question for you, now does your browser know what to do with each type of file? how does it know to display a gif file, or download an exe. You dont see it tring to display an exe file do you?

    what does this part of your code do?

    ' Write out content-type that will FORCE user to SAVE FILE.
    ' "image/gif" will display in browser
    Response.ContentType = "bad/type"
    To put your code in simple terms. It forces IE (note IE) to download said file instead of what it would normally do, by setting the content type for that file to "bad/type". The line Call Response.AddHeader("Content-Disposition","attachment; filename=""" & strFileSave & """") is used to write information to the dialog box which will appear when IE trys to download anything.

    Thus the browser still has to know the location of the file to download it, if it knows where to look so can you. Achilles should show this

    SittingDuck
    I\'m a SittingDuck, but the question is \"Is your web app a Sitting Duck?\"

  6. #16
    Senior Member
    Join Date
    Nov 2002
    Posts
    174
    I'll give Achilles a shot and see what it does. I'm definitely interested to find out. From what the comments say, the author (not me) says that setting the content type to "bad/type" (something unreckognizable by ie) will force the user to download.

    A gif file (or any file that I have told IE to "open automatically") will NOT display in the browser when using this code. I tried my original redirect idea on a zip file and I had encoded text displayed in the browser... that's why I started looking for examples of how to force a download regardless of file type (rather than having the browser try to load the file with it's associated handler). It really spawned off a whole seperate issue than what the original post was about :-)

    I'm heading home and will try out Achilles and let everyone know what I find! Thanks sittingduck!

    I'm guessing that the http source is actually the asp file
    Mike Reilly
    bluebeard96@yahoo.com

  7. #17
    Senior Member
    Join Date
    Nov 2002
    Posts
    174

    The results are in!!

    OK, here what happens on a simple response.redirect "/files/ypager.exe" (straight to the file). As you can see, the path is fully exposed, exactly at sittingduck warned! Thanks to sittingduck for pointing out that vulnerability.


    ~~This is the request for the page~~
    ---------------------------------------------------------------
    GET /dl.asp HTTP/1.0
    Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
    Accept-Language: en-us
    Cookie: ASPSESSIONIDQGQQQHIC=JFAFOFHDLPFKNLMJNBKGAMJD
    User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
    Host: localhost
    Proxy-Connection: Keep-Alive
    ---------------------------------------------------------------

    ~~This is the redirect that exposes the source~~
    ---------------------------------------------------------------
    HTTP/1.1 302 Object moved
    Server: Microsoft-IIS/5.0
    Date: Thu, 05 Dec 2002 06:19:06 GMT
    Location: http://localhost/files/ypager.exe
    Connection: Keep-Alive
    Content-Length: 154
    Content-Type: text/html
    Cache-control: private

    <head><title>Object moved</title></head>

    <body><h1>Object Moved</h1>This object may be found here.</body>
    ---------------------------------------------------------------

    ~~This is the download request~~
    ---------------------------------------------------------------
    GET /files/ypager.exe HTTP/1.0
    Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
    Accept-Language: en-us
    Cookie: ASPSESSIONIDQGQQQHIC=JFAFOFHDLPFKNLMJNBKGAMJD
    User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
    Host: localhost
    Proxy-Connection: Keep-Alive
    ---------------------------------------------------------------




    But, here is the info using the code posted previously. The code that streams the file via asp FSO appears to effectively mask the source of the file. Take a look for yourself:

    ~~This is the page request~~
    ---------------------------------------------------------------
    GET /formproc.asp HTTP/1.0
    Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
    Accept-Language: en-us
    Cookie: ASPSESSIONIDQGQQQHIC=JFAFOFHDLPFKNLMJNBKGAMJD
    User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
    Host: localhost
    Proxy-Connection: Keep-Alive
    ---------------------------------------------------------------

    ~~Immediately after this goes through the proxy, I get my~~
    ~~prompt to open from current location or save to disk.~~
    ---------------------------------------------------------------
    GET /formproc.asp HTTP/1.0
    Accept: */*
    Proxy-Connection: Keep-Alive
    User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
    Host: localhost
    Cookie: ASPSESSIONIDQGQQQHIC=JFAFOFHDLPFKNLMJNBKGAMJD
    ---------------------------------------------------------------

    ~~Save file to disk~~

    ~~Close Log~~


    Well, as you can see, there is no data passed through the proxy when I am dowloading the file. We appear to have a working solution!

    FYI, anyone interested in downloading Achilles (the tool I used upon sittingduck's advice) can get it here:
    http://www.packetstormsecurity.com/f...-0-27.zip.html

    Good luck all!
    Mike Reilly
    bluebeard96@yahoo.com

  8. #18
    Senior Member
    Join Date
    Nov 2002
    Posts
    174

    Here's a test site to verify that the source is masked

    http://www12.brinkster.com/bluebeard96/formproc.asp

    This page will prompt a download of a text file... the file name to save will be savedfile.txt, but the original file is named something else (open the txt file after downloading to find out what!)



    Thanks all... this has been an educational and fun one to play with.
    Mike Reilly
    bluebeard96@yahoo.com

  9. #19
    Senior Member
    Join Date
    Oct 2002
    Posts
    181
    Cheers for that I have found somthing interesting on this

    when I made the request for the file this was the responce for the server

    incoming data: 'HTTP/1.0 200 OK'
    incoming data: 'Date: Fri, 06 Dec 2002 10:29:45 GMT'
    incoming data: 'Content-Length: 80'
    incoming data: 'Content-Type: bad/type'
    incoming data: 'Cache-Control: private'
    incoming data: 'Connection: keep-alive'
    incoming data: 'Server: Microsoft-IIS/5.0'
    incoming data: 'Set-Cookie: BrinksterServer=2'
    incoming data: 'Content-Disposition: attachment; filename="savedfile.txt"'
    incoming data: 'Set-Cookie: ASPSESSIONIDQARCDCCC=IAEPDOCABGAGEHHOHGJHDDLC; path=/'
    incoming data: ''
    incoming data: 'Hi, you've downloaded a file from the server called "sourcefile.txt"'
    incoming data: ''

    (Achilles seems to have not shown this, as I guess it will not show HTTP responces for cirtain types of file eg bad/type, you learn something new everyday!)

    as you can see that what was returned was the text file.

    You can't see where the actual file is but in this case you don't need to, as now formproc.asp is the textfile. This means you can still link directly to formproc.asp.

    In other words in the server eye theTextFile = formproc.asp.

    So we are now back to squire one again.

    Sorry to trash the party

    SittingDuck
    I\'m a SittingDuck, but the question is \"Is your web app a Sitting Duck?\"

  10. #20
    Senior Member
    Join Date
    Nov 2002
    Posts
    174
    well the formproc is this example didn't really do any form processing. I should have taken the time to do it correctly and make a form.asp that submitted to formproc.asp. I was piggypacking the other ideas of checking the http referrer, although I didn't explicitly state that.

    The ideas given earlier about the referrer WILL beep the download from being started. The code I was giving was to help mask the source of the download once started. A fully made formproc (I'll make one in a couple of hours) will verify form data and verify the http referrer. That will prohibit a user from linking directly to formproc.asp.

    My fault... I did it 80% and didn't add that in.

    Granted, what the want to do for form validation, etc, is up the whoever creates it.

    http://www12.brinkster.com/bluebeard96/form.asp

    If you go to http://www12.brinkster.com/bluebeard96/ and try to click on the link to formproc.asp, notice that it will NOT work. The page only loads through the form.
    Mike Reilly
    bluebeard96@yahoo.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •