Re: [WebDNA] preventing hackers from posting their own (altered) version of my form?
This WebDNA talk-list message is from 2009
It keeps the original formatting.
numero = 102028
interpreted = N
texte = Most times though its not a hacker, its a script that is hacking your form. They read the form in and then post the data to your post page, its easier than filling out your forms. One technique that we find works extremely well is using css to hide a standard input field so that users will not input the information. But the scripts cannot read css, or don't yet, especially when its on a separate style sheet. Hence they fill out this field and we know that they should not have filled it out, and so we perform no actions. Addtionally we name this field something juicy like fname or company- name. No input = real user Input = hacker On Feb 19, 2009, at 11:50 AM, 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 > salt > 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... > > Marc > > 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="POST". " >>> But after seeing your post here I tried it and it seems to work >>> fine, >>> even with method=post. (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 >>> what >>> I would have stuffed in there with the [referrer] tag's value?) >>> >>> -G >> >> >> >> 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 >> proxies. >> >> Donovan >> >> > > -- > ------------------------------------------- > Marc Thompson > Software Engineer > Office of Information Technology > University of Utah > 801.585.9264 > marc.thompson@utah.edu > ------------------------------------------- Robert Minor Director of Internet Services ------------------------------------------------------------ Cybermill Communications http://www.cybermill.com http://www.merchantmaker.com Providing Ecommerce and interactive website development and hosting services on Macintosh, Windows NT, *nix, and AS/400. Complete ddos proof hosting solutions and network services.
Associated Messages, from the most recent to the oldest:
Most times though its not a hacker, its a script that is hacking your form. They read the form in and then post the data to your post page, its easier than filling out your forms. One technique that we find works extremely well is using css to hide a standard input field so that users will not input the information. But the scripts cannot read css, or don't yet, especially when its on a separate style sheet. Hence they fill out this field and we know that they should not have filled it out, and so we perform no actions. Addtionally we name this field something juicy like fname or company- name. No input = real user Input = hacker On Feb 19, 2009, at 11:50 AM, 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 > salt > 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... > > Marc > > 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="POST". " >>> But after seeing your post here I tried it and it seems to work >>> fine, >>> even with method=post. (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 >>> what >>> I would have stuffed in there with the
[referrer] tag's value?) >>> >>> -G >> >> >> >> 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 >> proxies. >> >> Donovan >> >> > > -- > ------------------------------------------- > Marc Thompson > Software Engineer > Office of Information Technology > University of Utah > 801.585.9264 > marc.thompson@utah.edu > ------------------------------------------- Robert Minor Director of Internet Services ------------------------------------------------------------ Cybermill Communications http://www.cybermill.com http://www.merchantmaker.com Providing Ecommerce and interactive website development and hosting services on Macintosh, Windows NT, *nix, and AS/400. Complete ddos proof hosting solutions and network services.
Bob Minor
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
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...
Related Readings:
FAX orders (1996)
emailer setup (1997)
all records returned. (1997)
Date Formats (1997)
bug in [SendMail] (1997)
RE: Problem (1997)
Requiring that certain fields be completed (1997)
Need help with emailer- 2 issues (1997)
Sorting by date (1997)
WebCatalog on Solaris, installation problems (2000)
Items XX to XX shown (1997)
WebDNA-Talk Digests (1997)
WebCat2.0 acgi vs plugin (1997)
PCS Frames (1997)
Replace Statement (1997)
Database changes (1998)
E-mailer error codes (1997)
Need help... (1997)
Not really WebCat (1997)
Client-side Image Maps and WebCat (what's a database-drivensite)? (1998)