December 8th, 2002, 05:40 PM
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?
I\'m a SittingDuck, but the question is \"Is your web app a Sitting Duck?\"
December 8th, 2002, 07:14 PM
There's one way to find out
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.