Re: [WebDNA] preventing hackers from posting their own
This WebDNA talk-list message is from
2009
It keeps the original formatting.
numero = 102027
interpreted = N
texte = Do you mean: -Dan On Thu, 19 Feb 2009 10:50:07 -0700 Marc Thompson wrote: > I agree with Donovan. A hidden field is as misconception, it's not > really hidden, just not visible in a browser. Any hacker worth his sal= t > attempting to "hack" a form post will look at the "hidden" fields first > and they are quite easy to spoof. Using an encrypted value with a seed > will most certainly stop them in their tracks. > I've used that method for years without incident... >=20 > Marc >=20 > Donovan Brooke wrote: >> Govinda wrote: >>> Thanks Gary, >>> >>> well I had just assumed that [REFERRER] would not get set to the >>> actual referring URL when reaching the template with that tag in it >>> because of this line from the docs: >>> "...Note: this will not work if the previous page was a FORM >>> METHOD=3D"POST". " >>> But after seeing your post here I tried it and it seems to work fine, >>> even with method=3Dpost. (why do the docs say that?) >>> Assuming [referrer] is reliable in this situation, then I can just >>> check against the evaluated tag's value itself.. (and not against an >>> incoming hidden input). If I used a hidden input the way you suggest >>> then what stops a user from creating a version of the form with a >>> hidden input whose value is set to whatever he wants. (including wha= t >>> I would have stuffed in there with the [referrer] tag's value?) >>> >>> -G >>=20 >>=20 >>=20 >> I would suggest to encrypt a hidden value with a seed... then decrypt = on >> the receiving end to do a match to a static or admin controlled >> variable. Referrer is not reliable in all situations because of proxie= s. >>=20 >> Donovan >>=20 >>=20 >=20 > --=20 > ------------------------------------------- > Marc Thompson > Software Engineer > Office of Information Technology > University of Utah > 801.585.9264 > marc.thompson@utah.edu > -------------------------------------------
Associated Messages, from the most recent to the oldest:
Do you mean: [url][url][encr= ypt=20 seed=3DyourSeed][topSecret][/encrypt][/url][/url]"> -Dan On Thu, 19 Feb 2009 10:50:07 -0700 Marc Thompson wrote: > I agree with Donovan. A hidden field is as misconception, it's not > really hidden, just not visible in a browser. Any hacker worth his sal= t > attempting to "hack" a form post will look at the "hidden" fields first > and they are quite easy to spoof. Using an encrypted value with a seed > will most certainly stop them in their tracks. > I've used that method for years without incident... >=20 > Marc >=20 > Donovan Brooke wrote: >> Govinda wrote: >>> Thanks Gary, >>> >>> well I had just assumed that [referrer] would not get set to the >>> actual referring URL when reaching the template with that tag in it >>> because of this line from the docs: >>> "...Note: this will not work if the previous page was a FORM >>> METHOD=3D"POST". " >>> But after seeing your post here I tried it and it seems to work fine, >>> even with method=3Dpost. (why do the docs say that?) >>> Assuming [referrer] is reliable in this situation, then I can just >>> check against the evaluated tag's value itself.. (and not against an >>> incoming hidden input). If I used a hidden input the way you suggest >>> then what stops a user from creating a version of the form with a >>> hidden input whose value is set to whatever he wants. (including wha= t >>> I would have stuffed in there with the [referrer] tag's value?) >>> >>> -G >>=20 >>=20 >>=20 >> I would suggest to encrypt a hidden value with a seed... then decrypt = on >> the receiving end to do a match to a static or admin controlled >> variable. Referrer is not reliable in all situations because of proxie= s. >>=20 >> Donovan >>=20 >>=20 >=20 > --=20 > ------------------------------------------- > Marc Thompson > Software Engineer > Office of Information Technology > University of Utah > 801.585.9264 > marc.thompson@utah.edu > -------------------------------------------
"Dan Strong"
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...