alternative to HTTP_REFERER

[1DMF]

Hello peeps,

Is there another way PERL can authenticate the request to a script from a submitted form, was made by an authorised URL without using HTTP_REFERER environment variable.

Or any ideas on an alternative way of doing the same thing.

I did ask this in the IT Browsers forum, but seemed to start a war over FireFox - opps!.



1DMF

 

[duncdude]

.htaccess files ?

then check the $ENV{REMOTE_USER} ... will require a login though

As you are probably already aware - the HTTP_REFERER can be forged - so really doesn't count for much at all


Kind Regards
Duncan

 

[Xaqte]

I did ask this in the IT Browsers forum, but seemed to start a war over FireFox - opps!.

.

Yeah, you certainly did!

I hate to post a link to another forum... but this contains alot of information similar to your request:

http://perlmonks.com/index.pl?node_id=223071

Personally, I like the proxy idea. Just my 2 cents! I hope you find what your looking for.

X

 

[1DMF]

so I can submit a form with a form field that fools the HTTP_REFERER anyhow.

And how would i use .htaccess without a loging the form being submitted is in a public area.

hmmm I guess the comment I once saw over making your website safe (Delete it!) is the only answer. A bit like how do you protect your computer from the internet (unplug it!)

lol - there must be a way, isn't there?

 

[1DMF]

Hey Xaqte,

I checked the link but don't understand what this proxy thing is, also if it requires anyone to have programing knowledge or specific configuration to a server then this won't suit most as probably like me the server is a webhost not inhouse.

I want people to be able to write a simple form with no programing other than HTML and when the form is submitted to my program it authenticates the refering form.

it's such a simple task, why does it seem an imposible thing to do, basic html / internet security i'd have thought.

I don't think what i want to do will work and using IP is not an option, what happens when the webhost upgrades and moves your site to a different server on a different IP address , they aint gonna tell you, your domain will run fine but the program will stop working.

also what environment variable do you use to get the REFERER_IP rather than $ENV{'REMOTE_ADDR'};

what a nighmare this is.

 

[PaulTEG]

you must be a firefox user, they're so tetchy.

I'm no historian, but for some reason, I think it started to slide just about here



cigless ...

 

[Xaqte]

Yeah, I agree a proxy is much too work for what you want. I didn't realize this until I brought up your sample page from the other thread.

Just a thought,
After the user fills out the form and inserts their email address & clicks submit, why not designate a id for the form needed. Insert this id and the relevant data that they choose in a databse. Send the user a link to your site with the id as the key. When the script catches the id by a cgi paramater, it will look up the id in the database along with the information that user chose. At this point you could have one common template and send all the data over to the template.

I hope I understand your situation correctly. If I've overthought or underthought anything, please point out this.

 

[Rieekan]

Again, not foolproof, but you could try capturing the user's IP address when the user visits the entry form, save it (database, text file, etc. Just depends on how many users you expect), then when the user submits, verify it against the list you have currently. If it exists, send the mail and delete that IP. If it doesn't exists, reject the information and send the user to a "I'm sorry" page.

- Rieekan

 

[KevinADC]

basic html / internet security i'd have thought.

there is no such thing as basic html or internet security. You have to think of both of them as totally insecure and use the common methods of trying to prevent abuse of your CGI forms.

Your easiest and probably best option is to require usernames and passwords and hope they don't get compromised. All other security measures are just an annoyance to the user and are generally all vulnerable anyway. It's sorta like shop-lifting. Stores take drastic measures to prevent it, and the shop-lifters just find new ways to take stuff. The only possible way to prevent shop-lifting is to frisk people when the enter and when they leave, and that will never happen, thank goodness.

Even passwords and names are very vulnerable because of the way browsers store the information. Many people know you can sit down at a terminal another person just used to access the internet and check the history and go to any sites that have names/passwords and see if auto-login was used. If it was, you're in. Convenience first, security second.

 

[mlibeson]

some are using a random gif image that contains text while displaying in a browser that you would need to write down and then enter when you were on the form submit page in order to verify you came from an internal web site page. The image has misc garbage that over lays some of the text so that the characters are easy for a human to read, but make it difficult for a progam to decipher. Then as previously mentioned, I would incorporate an email verification system where the submit is not accepted until it is approved. The way a user would approve the submit would be to send an email containing a url with a unique identifier for the specific submit. The user would then need to use the link from the received email in order to get to the approval page on your site. Which would allow them to click a button to submit their approval. It sort of simulates a login without you needing to manage the accounts. The only way the could get to the appropriate page was to know the exact URL for approval. Make sure your unique id is long enough and complicated enough that it will not be easy to hack.

I hope this helps a little more.


Michael Libeson

 

[1DMF]

I don't think I have explained what i'm trying to do properly, let me try again and you will see (i hope), also I think maybe everyone else should visit the link to get a feel for the project.

http://www.stepnstomp.co.uk/aiab/example1.htm

--------------------------------------------------
The concept is this ... how many people would love to have a form that when filled out is emailed to you looking EXACTLY as the form filled out, all the images, the fields, checkboxes, selectlists, text areas everything is the same in the email received... come on everybody (well most i'll be conservative).

how many would love to have this facility without knowing a single command of any programing language whatsoever other than some simple HTML form tags.

how would you like to design a form, no programing, no java, just a simple form, put it on your website, log in to my program, paste your form code into the textbox provided, give it a form ID and hit save.

Then when your form is submitted to my CGI it reads the corresponding template, gets the data submitted, populates all the relevant fields , tick boxes, select lists etc.. with all the data, makes them readonly and then emails you the form.

You get the results of the form looking like the form used to submit the data. (I also added extra features so you can control if you want a select lists selection to be displayed as a CSV field or checkboxes).

The point is the person making the form must not have to have javascript, not know how to configure proxies, unable write CGI, know nothing about fancy graphic generating validation programs, know nothing about CGI, ASP, PHP - JUST HTML!

But still gets the power of Rich Text Format emails looking like the submitted form with all the user selected data.

Now that's a kick ass idea, my system works apart from how do I authenticate the form with the domain it is sitting on without using HTTP_REFERER?

Now do you see my problem.

P.S.
PaulTEG, I was trying to forget about that little altercation, and hoped the kind fellows here in the PERL forum would forgive my minor mishap, however I stand by my comment, FireFox users, well everyone i've come across, are tetchy, infact one of them in that post even agreed. Why do they get so defensive it only a sodding browser after all?