Re: Hierarchy of form/text/math variables (renamed thread)

This WebDNA talk-list message is from

2000


It keeps the original formatting.
numero = 31119
interpreted = N
texte = I have to agree with you, Grant. Security has been lax in WebCat (and all other scripting software that I am aware of). I think the default behavior should be to distrust all data that comes from outside the program itself (this includes the database itself actually).Perl employs a concept of taint which refers to data that can potentially be hacked. In essence any data that comes from outside the program's sole control is considered tainted, and every value that is derived from that data is also considered tainted (consider it the computer version of an STD). The programmer can explicitely force Perl to remove the taint from a value. In practice, it can be difficult to make a program completely taint free, but it is worth the effort for a general purpose scripting language like Perl, which can also be considered weak on security.It would be useful for WebCat to allow the programmer to take his/her chances or optionally to validate the data in some way. I think the easiest way to do this would be a context which would turn off the taint checking for specified fields for the remainder of the page. Those WebCat programmers who make extensive use of [include] would need to make very few changes; those who hard-coded everything would get a good object lesson on the reason why [include] is so powerful. 8~(My 2 centsJohn Peacock ____________________Reply Separator____________________ Subject: Hierarchy of form/text/math variables (renamed thread) Author: Date: 4/30/2000 8:31 PMOops, meant to rename that thread. Don't reply to the other one.>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: Hierarchy of form/text/math variables (renamed thread) (jpeacock@univpress.com 2000)
I have to agree with you, Grant. Security has been lax in WebCat (and all other scripting software that I am aware of). I think the default behavior should be to distrust all data that comes from outside the program itself (this includes the database itself actually).Perl employs a concept of taint which refers to data that can potentially be hacked. In essence any data that comes from outside the program's sole control is considered tainted, and every value that is derived from that data is also considered tainted (consider it the computer version of an STD). The programmer can explicitely force Perl to remove the taint from a value. In practice, it can be difficult to make a program completely taint free, but it is worth the effort for a general purpose scripting language like Perl, which can also be considered weak on security.It would be useful for WebCat to allow the programmer to take his/her chances or optionally to validate the data in some way. I think the easiest way to do this would be a context which would turn off the taint checking for specified fields for the remainder of the page. Those WebCat programmers who make extensive use of [include] would need to make very few changes; those who hard-coded everything would get a good object lesson on the reason why [include] is so powerful. 8~(My 2 centsJohn Peacock ____________________Reply Separator____________________ Subject: Hierarchy of form/text/math variables (renamed thread) Author: Date: 4/30/2000 8:31 PMOops, meant to rename that thread. Don't reply to the other one.>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 jpeacock@univpress.com

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:

textarea data entry and display (2000) Tags in the header (2000) [WebDNA] WebDNA 8.6 announced - New features (2018) Need WebDNA that crashes server for testing (2000) Emailer (WebCat2) (1997) WebCatalog for guestbook ? (1997) [shownext max=?] armed (1997) Sandbox DB permissions (2005) dbQuickView 2.0 (2005) Country & Ship-to address & other fields ? (1997) [SMSI] WebDNA is too good to go away! (2006) Re(2): SSL, WebSTAR, WebCatalog (1998) service stop and restart (1997) Search for value or blank? (2004) JavaScript (1998) New Command prefs ... (1997) Date Calulation (1997) I'm tired of all this! (2000) More on the email templates (1997) WebCat for Unix?? (1997)