Printable View
Can anyone think of a way to protect a download link so that people cannot see where the download is coming from? We think that people are using a direct link to download our software. (thus bypassing the registration page) We would like to change the link and add some more protection. We have a IIS 5 box.
I have already looked at some protection through a third party (anti-leech.com) but want to keep my options open if anyone has any ideas.
Thanks in advance.
This is only a suggestion but could you make the link an ASP request that retreives their current login name or password. If they use when not logged into the site it could not retrieve this portion and would either redirect them to a login screen or give them a site not found error.
The other way to implement this is to send the requested url to a login screen that they must log through to get to the download. The drawback of this is that for every download they would have to put in a login or password. It could get tedious for someone who downloads a lot of your files.
I am not enough of a programmer to give you code hints on how to do it, I apologize, but you could consider these and see if they are feasible.
A username and password cannot be a solution at the moment. (According to management)
This question is a little like the one posed in this thread here:
http://www.antionline.com/showthread...484#post585484
in that the answer is similar. It is possible to protect from casual curiosity, but there is no real way to stop the determined. In the case of downloads, there is no type of web scripting or whatever that can disable the ability to use netstat or similar tools to see which IP addys a host is connecting to.
Hmm. What about a script which checks the referring URL and displays a 'Blah blah stolen' image if the referring URL is alien? (Otherwise returning the file)? I dunno.
I think Terr is on the right track. I am in the process of doing something similar. Through scripting you can determine the refering page. If the referring page is the correct one you can use the redirect function to the download url. I am currently working on how to hide this last piece. I will not be able to get back to it until this weekend. As I come up with a solution I will update this thread.
Two potential solutions. I see where Terr is heading, and I was thinking the same thing at first. I do see one problem however. Let's say the download link is available on download.asp. Even if download.asp checks for the referre (ie processform.asp), the link directly to the file is still exposed in the html. You can do it this way, but I wouldn't place a link in the html. 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? A user, in theory, would hit submit on the form and then the next thing they would see is the download file prompt when the form redirects them.
Just an idea. Haven't tested it yet. I think I'll go play with it now. :-)
First of all let me say that I have never done this with asp through IIS so I don't know for sure if it will work. I used to do the following with a perl script through Apache for a software company that I worked for:
1. Person buys the software, and a dynamically generated link is sent to them. That link has an order number in it that specifies it as that specific download. The link is actually a script that is used to push the program out to the user.
2. When the user clicks on the link, the script parses the url, looks up that order number in the database, and serves up the program(s) that they purchased to them.
3. A cron job comes through nightly and deletes the link (script) that was created after 3 days so it is no longer accessible.
Granted, that does not mean that they won't be able to mail that link to all of their friends in the first 72 hours, but it might help curb the abuse a little bit.
OK, confirmed that this works with .exe files, but I also found that if I tried to link a zipped file, that I would just get encoded text on the screen. I'm not sure why, maybe someone else can shed some light on that.
As far as my ASP file, I just included a line that simply says this...
response.redirect "http://localhost/files/ypager.exe"
Upon loading my asp page, I get a download prompt asking me to save ypager.exe from localhost (note that it didn't give the full path JUST the domain). I NEVER SEE THE FILE PATH.
So, assuming you're distributing exe files, this should work. I'll see if I can figure out the zip file thing. Be back soon!
--------------------------------------
Ok, I think I've got it here. Take a look at this site:
http://www.planet-source-code.com/xq...s/ShowCode.htm
It has the code you need to force a download of ANY file type (even common types that the browser usually loads... htm/asp/gif/jpg/txt, etc). This also fixes the problem I had with zip files.
This code could be inserted at the end of the same asp file that processes your form, if desired. As the author suggests, however, it might be advantagous to look at reading the data in chunks rather than bit-by-bit... can take a long time for big files. There is no redirect required in this scenario (although ou could add one if you wanted to)... the file is simply read and output straight to the browser.
Hope this helps! I know I learned from it and will be putting it to use.
<% just a test to see if sample asp will show up %>
for those that don't want to go d/l the zip and look at the asp sample, here it is (I didn't write it, but it works for what is needed here!):
<%
' Constants for Reading Text File
Const ForAppending = 8
Const ForReading = 1
Const ForWriting = 2
Const TristateFalse = 0
Const TristateMixed = -2
Const TristateTrue = -1
Const TristateUseDefault = -2
' File System Objects
Dim FSO
Dim TS
' 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 & """")
' Write out content-type that will FORCE user to SAVE FILE.
' "image/gif" will display in browser
Response.ContentType = "bad/type"
' Initialize File System Object
Set FSO = Server.CreateObject("Scripting.FileSystemObject")
' Open TextStream for Reading
Set TS = FSO.GetFile(strFile).OpenAsTextStream(ForReading,TristateTrue)
' TS.ReadAll DOES NOT WORK. Every Byte must be read and written individually.
' I think you can read them in Chucks, but this was easier. If you know how to
' Read chunks... go ahead, read chunks ;)
Do While Not (TS.AtEndOfStream)
' Output MUST be BinaryWrite
Response.BinaryWrite(TS.Read(1))
Loop
' Cleanup, like all good programmers do.
TS.Close
Set TS = Nothing
Set FSO = Nothing
' You don't need this, but I like it.
Response.End
%>
Thanks for all your help. I will try your solutions.
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
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! :-)
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
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?Quote:
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?
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
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.
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?
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.Quote:
' Write out content-type that will FORCE user to SAVE FILE.
' "image/gif" will display in browser
Response.ContentType = "bad/type"
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'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
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!
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.
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
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.
well you beat me to it, bluebeard96, I'm guessing that you are using an if statement in the page based on the refer from the page before. Thie still leaves one more possible way to directly link to that file. That would be to inculde the refer in the header when making a direct request. There are two thing I would like to say about this
1)Frist they have to guess that you doing by the refer, whcih would not be too hard if they are any good.
2)the http requests to directly link to the file would have to be specialy made!
This I belive would stop 99.9% of people. But I have a sugestion to stop 100% of people
in form.asp you need a variable, lets say 6 chars long lets say the value is "accept". Now you encrypt this varialbe using a random seed, made up of random charectors and of random length say 6-10 long. There is one random seed per session in the server. THis would mean every session has a different seed. Note the random seed must be held in a session varible and never show to the user)
Pass the encypted variable from form.asp to formproc.asp (either in a form, or in the URL).
Now decrypt the varible in formproc.asp, and see if the decryption result == "accept".
What this means is say the first time you ask for the formproc.asp the variblae passed might be "g3$rted876", the second time it might be "^yuf23!dfgf3".
Using this method will prevent 100% of people from directorly asking for the file.
So do you think this method will work?
SittingDuck
And unfortunately I'm moving today... so I won't be able to test until later tonight.
Let me as one thing though. I'f we're going to be throwing a seed in a session variable, why don't we just tell form.asp to set a session variable and use an if/then in formproc to check for existence of the session variable. I don't really see this as less secure than the suggestion you proposed, as the session variable I suggest and the session variable (encryption key) you suggest would have the equal vulnerability.
That's my initial thoughts, at leats. I might be changing my mind after I get into it tonight.