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:

    
  1. Re[2]: Hierarchy of form/text/math variables (Joseph D'Andrea 2000)
  2. Re[2]: Hierarchy of form/text/math variables (jpeacock@univpress.com 2000)
  3. Re: Hierarchy of form/text/math variables (renamed thread) (jpeacock@univpress.com 2000)
  4. Re: Hierarchy of form/text/math variables (Joseph D'Andrea 2000)
  5. Re: Hierarchy of form/text/math variables (John Butler 2000)
  6. Re: Hierarchy of form/text/math variables (Kenneth Grome 2000)
  7. Re: Hierarchy of form/text/math variables (Mike Davis 2000)
  8. Re: Hierarchy of form/text/math variables (Chuck Rice 2000)
  9. Re: Hierarchy of form/text/math variables (renamed thread) (Brian B. Burton 2000)
  10. Re: Hierarchy of form/text/math variables (renamed thread) (Kenneth Grome 2000)
  11. Re: Hierarchy of form/text/math variables (Jesse Proudman 2000)
  12. Re: Hierarchy of form/text/math variables (renamed thread) (Howard Wolosky 2000)
  13. Re: Hierarchy of form/text/math variables (Mike Davis 2000)
  14. Re: Hierarchy of form/text/math variables (renamed thread) (Jesse Proudman 2000)
  15. Hierarchy of form/text/math variables (renamed thread) (Grant Hulbert 2000)
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:

WebCat2b15MacPlugin - showing [math] (1997) [url] (1997) Signal Raised Error (Part II) (1997) fixed date problem (1997) how many users (2000) question: back button prevention (1997) [WebDNA] SWITCH/CASE or SHOWIF (2008) [ShowNext] (1997) system crashes, event log (1997) Re1000001: Setting up shop (1997) [TaxableTotal] - not working with AOL and IE (1997) [WebDNA] [OT] Best Rank/SEO/Analytics sites (2015) Signal Raised Error (1997) Generating unique SKU from [cart] - Still Stumped... (1997) $Quit, $CloseDatabase corrections (1997) Help name our technology! I found it (1997) default image if image in code not available (2003) [ModDate] & [ModTime] ? (1997) WebCat2b14MacPlugIn - [include] doesn't hide the search string (1997) CA tax rates update (1998)