Re: Hierarchy of form/text/math variables
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 31105
interpreted = N
texte = When I depend on variables to be secure, I run a routine at the top of the page similar to this: [formvariables] [showif [name]^SecureUser,IsValidAccount,IsAdmin] [authenticate Futile Hacker] [/showif] [/formvariables] This essentially checks to see if a variable that is important to security is being sent to the page and invokes the protect tag if it is. Maybe this could be simplified and taken one step further, similar to your suggestion of a [PresetFormVariables] idea. Instead of the formvariables loop method, you could essentially change the hierarchy of named variables using a new context such as: [SecureVars]SecureUser&IsValidAccount&IsAdmin[/SecureVars] or Jesse's suggestion of: [text secure=t&multi=t]SecureUser=t&IsValidAccount=f&IsAdmin=f[/text] Where a secure variable could not be overridden by incoming formvariables but it could be changed with contexts further down the page.Mike>> Please, Please, Please just fix the global tags and leave the hierarchy the >> way it is. > > Naturally I'd like to figure out a way to keep the functionality > you're asking for and also maintain some kind of security. It > concerns me and lots of webmasters that any hacker can essentially > change your internal text variables by simply putting a new field > into the URL. > > It is a basic tenet of security that one doesn't depend only on > ignorance to maintain security. It should be possible to write > secure code even if the hacker knows all your source code. So, for > instance, if you set some text variable like > [text]IsValidAccount=F[/text] to indicate a bad account number, and a > hacker puts &IsValidAccount=T into the URL, that's not a good thing > if the form variable overrides the internal value. > > So let's try to think in a more general and abstract way about how we > can achieve the same affect that you're getting now. Perhaps some > kind of [PresetFormVariables] context, or something like that? > > Grant Hulbert, Director of Engineering ********************************** > Smith Micro, Internet Solutions Div | eCommerce (WebCatalog) > 16855 West Bernardo Drive, #380 | ------------------------- > San Diego, CA 92127 | Software & Site Development > Main Line: (858) 675-1106 | http://www.smithmicro.com > Fax: (858) 675-0372 ********************************** ############################################################# This message is sent to you because you are subscribed to the mailing list
. To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
Associated Messages, from the most recent to the oldest:
When I depend on variables to be secure, I run a routine at the top of the page similar to this: [formvariables] [showif [name]^SecureUser,IsValidAccount,IsAdmin] [authenticate Futile Hacker] [/showif] [/formvariables] This essentially checks to see if a variable that is important to security is being sent to the page and invokes the protect tag if it is. Maybe this could be simplified and taken one step further, similar to your suggestion of a [PresetFormVariables] idea. Instead of the formvariables loop method, you could essentially change the hierarchy of named variables using a new context such as: [SecureVars]SecureUser&IsValidAccount&IsAdmin[/SecureVars] or Jesse's suggestion of: [text secure=t&multi=t]SecureUser=t&IsValidAccount=f&IsAdmin=f[/text] Where a secure variable could not be overridden by incoming formvariables but it could be changed with contexts further down the page.Mike>> Please, Please, Please just fix the global tags and leave the hierarchy the >> way it is. > > Naturally I'd like to figure out a way to keep the functionality > you're asking for and also maintain some kind of security. It > concerns me and lots of webmasters that any hacker can essentially > change your internal text variables by simply putting a new field > into the URL. > > It is a basic tenet of security that one doesn't depend only on > ignorance to maintain security. It should be possible to write > secure code even if the hacker knows all your source code. So, for > instance, if you set some text variable like > [text]IsValidAccount=F[/text] to indicate a bad account number, and a > hacker puts &IsValidAccount=T into the URL, that's not a good thing > if the form variable overrides the internal value. > > So let's try to think in a more general and abstract way about how we > can achieve the same affect that you're getting now. Perhaps some > kind of [PresetFormVariables] context, or something like that? > > Grant Hulbert, Director of Engineering ********************************** > Smith Micro, Internet Solutions Div | eCommerce (WebCatalog) > 16855 West Bernardo Drive, #380 | ------------------------- > San Diego, CA 92127 | Software & Site Development > Main Line: (858) 675-1106 | http://www.smithmicro.com > Fax: (858) 675-0372 ********************************** ############################################################# This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
Mike Davis
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:
Denying access by IP address (2000)
CAll me Crazy (2000)
creator code (1997)
TaxTotal (2003)
[SearchString] usage (1997)
convertchars and case? (1998)
Concerning Emailer under Linux... does it exist? (2000)
too many nested ... problem (1997)
webcat2b12 CGI -- Date comparisons (1997)
[WebDNA] interesting bug webdna 6 (2012)
Server Freeze (1998)
faxing orders (2000)
WebMerch/Emailer Error (1998)
E-Mail (1998)
NT or Mac (1998)
Overwriting databases bug in [closedatabase], garbage filescreated (1998)
caching -check- (2001)
problems with 2 tags (1997)
Here's how to kill a Butler Database. (1997)
Secure server question (1997)