Re: math variable security [VERY LONG]

This WebDNA talk-list message is from

2000

It keeps the original formatting. numero = 33496
interpreted = N
texte = Bob - I have been out of the office for the past few days and am trying tokeep up with my e-mail from home. I wanted to respond to your messagesnot because I am picking on you (although it may seem that way atfirst), but because this is exactly the reason I argued that thesecure=f was unnecessary and in fact a bad addition to WebDNA.I don't know if the code you posted is production or you just whipped itout to demonstrate your point, but I see several failures of logic andgeneral design problems that I hope I can correct. This will be a longmessage because I want to try and lay out some basic thoughts firstbefore tackling your code. Some of it may seem incredibly basic to mostof the readers on this list, but I encourage everyone to follow my logicthough, so you know where I am coming from later.HTML is, by its very nature, stateless; in other words, a user can hitany page on your site in any order, and can leave your site at anypoint. Most of the time, we can program our sites so that the useroften follows some set of paths through it, but there is no way to forcea specific path (short of cascading [protect] pages). True, you can userealms to limit the scope of where the user can go, but that isbasically beside the point here.HTML is also designed to operate under a client/server model; the userenters some data on one page and the server processes it prior toserving up the next page (which can even be the exact same template). Form-variables are designed to carry state information between pages. They can be present inside a

tag or present as part of the URLitself ( ...page.tpl?command=explode). They are in essence client-sidevariables; the user can change them at will (and do things to them youhadn't considered). Form variables are by their very nature insecure.WebDNA [text] and [math] variables, on the other hand, are server-side,intended to be used within the logical page, typically to simplifyprocessing. Any manipulation of the value of said variables occurssolely on the server; hence they are by nature secure. To use the newcontext metaphor, [text] and [math] variables have a page context (and Iwill now refer to them jointly as page variables); they spring into lifeat the point they are first used on the page and exist until the bottomof that template. They are not available on the next page, unless youpass them as form variables (in programming lingo, they are local notglobal variables).Prior to version 4.0, it was possible to share a variable name between aform variable and a page variable; the user-defined form variable wouldbe used as the initial value for the now defined page variable. If theuser did not pass any value for that form variable, the initial value isthe string [varname] where varname is the name of the variable. Ken(and others) have used this behavior to quickly initialize all of theirpage variables at the top, so any tests on the page can be versus nullrather than having to test definedness. I view this as sloppyprogramming because it ignores the changes that a [malicious] user canmake to form variables. Just imagine the damage a user could do byreplacing a form variable with [shell]format c: /quick[/shell]; note:this will work do anything because WebDNA does not do an implicit[interpret]; but, if you ever thought about passing WebDNA code frompage to page via form variables, this should persuade you not to.Now, with all that text behind us, I am now going to analyze Bob's codeand make some concrete suggestions for changes. See inline commentsbelow...Bob Minor wrote:> > [text secure=f&multi=t]fname=&lname=[/text]> [math secure=f]error=0[/math]This is an unneccessary assignment as we shall see below, since thevariable [error] is never used on the first page as a math variable. The fact that it is used as a math variable on the second page isimmaterial to the discussion. In fact, all variables are passed betweentemplates as form variables, even under the 3.x model. Each template isdefined separately from the other; it is not like a language like BASICwhere two modules can share a common global variable.> > [showif [error]>1]As near as I can tell, this test is wrong; if the user misses a singlefield, the redirect will happen [error]>0, but neither showif [error]>1will fire.> [showif[fname]=]oops this one is blank[/showif][/showif]
> [showif [error]>1][showif> [lname]=]oops this one is blank[/showif][/showif]
> >

Note that on this first page, the variable [error] is only used intests; no calculations are performed and the value is not changed(except for the initialize, which I said is not needed). [error] is infact a form variable, used to carry the error state from the second pageto the first.> > then on my submitted page I do:> [formvariables]> [showif [value]=][math show=f]error=error+1[/math][/showif]Here, Bob has just defined a math variable, but in such a way that thevariable is never initialized. The previous page did not pass any formvariable called error, so the first formvariable with a null value setsit to error=undef+1, which WebCat cleverly reduces to 1. This is what Ihave repeatedly stated is lazy programming. All page variable should beinitialized to sensible values (usually 0 for math and null for text),and all form variables should be tested to see that they contain a valuethat is reasonable.> [/formvariables]Here, if the user did not supply a value for lname and fname, error=2;if the user missed either but not both, error=1.> [showif [error]>0]This will show if either or both fields are missing.> [redirect> thispage.tpl?error=[error][formvariables]&[name]=[value][/formvariables]]Here, Bob is using form variables to pass back the error state, as wellas any existing values, to the initial page. But as I stated above, ifthe user only misses one value, the Oops... warning will not show atall.> [showif]Note that this should be [/showif]> [fname] [lname] you done good digging through that form.> The problem here is that Bob is trying to use the [error] variable toflag which field is missing, but is really only flagging that there is_some_ field missing. To redesign this page, I am going to use WebDNA3.x logic, nothing fancy. I am going to walk though how I would designthis page, rather than just laying it out in a finished form.I am going to make the following assumptions about how the tempaltesflows: 1) the first page is stand-alone, i.e. it is not initially called asanything except thispage.tpl (i.e. no URL variables or POST formvariables).2) the program should note which field is missing and prompt that fieldalone, as well as retaining any previously entered values.3) Bob actually intended the user to key some values into input fields. As it stands now, these pages do nothing visably, since the user isnever given a chance to key anything, so both fields will forever beblank, unless they were being passed from some other template. I'mgoing to ignore that because that would just require a third page fordata entry.Now, for the first pass at thispage.tpl:



The clever people on this list will notice that this is, in fact, pureHTML. I believe this is the appropriate place to start, since it willdrive the initial interaction with the user. It is also what the pageshould resolve to, once the WebDNA is entered (i.e. everything else willhave hideif/showif's).The second page (nextpage.tpl) will receive 2 defined form variables,either or both which can be null.[text show=f]missing=[/text][!]always init vars[/!][formvariables] [showif [value]=] [text show=f]missing=missing'[name][/text] [/showif][/formvariables][showif [missing]!][redirectthispage.tpl?missing=[missing][formvariables]&[name]=[value][/formvariables]][/showif][fname] [lname] you done good digging through that form.This is pretty much the same as Bob's page, but I changed the name ofthe error variable and what I am doing with it. What I did will meanthat if lname is not entered, then missing='lname; if fname is notentered, missing='fname; and if both are not enteredmissing='fname'lname. The delimiter character can be anything you wantit to be that is not an alphabetic charatcer.Now, the first can be entered upon the redirect, and, in this case, willbe passed exactly three form variables: missing, fname, and lname. Notethat due to the clever coding that Bob did with the redirect, this codecan actually be used to check any number of variables. I would actuallyuse it as an include file and change the thispage.tpl into a parameterfor the include file, i.e.  [include file=checkup.inc&template=thispage.tpl]In any event, let's return to the first page and finish it with theappropriate tests:

[showif [missing]~fname]oops this one is blank[/showif][showif [missing]~lname]oops this one is blank[/showif]

Note that this form will now operate as I believe Bob intended, yet itdoes not need secure=f, nor any complicated hoops to deal with the fieldtesting. In fact, since I separated the form initialization code fromthe blank field warning, you could also call this template asfirstpage.tpl?fname=my&lname=name and still function as it should.If I had a lot more time, I would state categorically that any set ofpages that rely on secure=f can be easily rewritten to not requireit,and that I could do it on demand. I know that I have never needed touse the variable overloading feature, and I have yet to see any codethat convinced me it is useful. I know that there are some schools ofthought that suggest that all form variables (client side) be named witha preceeding underscore (_fname), so that it is painfully obvious thatit is not the same thing as a similarly named text (server side)variable (fname).Hope this helps someone...John Peacock-------------------------------------------------------------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 Web Archive of this list is at: http://search.smithmicro.com/ Associated Messages, from the most recent to the oldest:

Re: math variable security [VERY LONG] (John Peacock 2000)

Bob - I have been out of the office for the past few days and am trying tokeep up with my e-mail from home. I wanted to respond to your messagesnot because I am picking on you (although it may seem that way atfirst), but because this is exactly the reason I argued that thesecure=f was unnecessary and in fact a bad addition to WebDNA.I don't know if the code you posted is production or you just whipped itout to demonstrate your point, but I see several failures of logic andgeneral design problems that I hope I can correct. This will be a longmessage because I want to try and lay out some basic thoughts firstbefore tackling your code. Some of it may seem incredibly basic to mostof the readers on this list, but I encourage everyone to follow my logicthough, so you know where I am coming from later.HTML is, by its very nature, stateless; in other words, a user can hitany page on your site in any order, and can leave your site at anypoint. Most of the time, we can program our sites so that the useroften follows some set of paths through it, but there is no way to forcea specific path (short of cascading [protect] pages). True, you can userealms to limit the scope of where the user can go, but that isbasically beside the point here.HTML is also designed to operate under a client/server model; the userenters some data on one page and the server processes it prior toserving up the next page (which can even be the exact same template). Form-variables are designed to carry state information between pages. They can be present inside a

tag or present as part of the URLitself ( ...page.tpl?command=explode). They are in essence client-sidevariables; the user can change them at will (and do things to them youhadn't considered). Form variables are by their very nature insecure.WebDNA [text] and [math] variables, on the other hand, are server-side,intended to be used within the logical page, typically to simplifyprocessing. Any manipulation of the value of said variables occurssolely on the server; hence they are by nature secure. To use the newcontext metaphor, [text] and [math] variables have a page context (and Iwill now refer to them jointly as page variables); they spring into lifeat the point they are first used on the page and exist until the bottomof that template. They are not available on the next page, unless youpass them as form variables (in programming lingo, they are local notglobal variables).Prior to version 4.0, it was possible to share a variable name between aform variable and a page variable; the user-defined form variable wouldbe used as the initial value for the now defined page variable. If theuser did not pass any value for that form variable, the initial value isthe string [varname] where varname is the name of the variable. Ken(and others) have used this behavior to quickly initialize all of theirpage variables at the top, so any tests on the page can be versus nullrather than having to test definedness. I view this as sloppyprogramming because it ignores the changes that a [malicious] user canmake to form variables. Just imagine the damage a user could do byreplacing a form variable with [shell]format c: /quick[/shell]; note:this will work do anything because WebDNA does not do an implicit[interpret]; but, if you ever thought about passing WebDNA code frompage to page via form variables, this should persuade you not to.Now, with all that text behind us, I am now going to analyze Bob's codeand make some concrete suggestions for changes. See inline commentsbelow...Bob Minor wrote:> > [text secure=f&multi=t]fname=&lname=[/text]> [math secure=f]error=0[/math]This is an unneccessary assignment as we shall see below, since thevariable [error] is never used on the first page as a math variable. The fact that it is used as a math variable on the second page isimmaterial to the discussion. In fact, all variables are passed betweentemplates as form variables, even under the 3.x model. Each template isdefined separately from the other; it is not like a language like BASICwhere two modules can share a common global variable.> > [showif [error]>1]As near as I can tell, this test is wrong; if the user misses a singlefield, the redirect will happen [error]>0, but neither showif [error]>1will fire.> [showif[fname]=]oops this one is blank[/showif][/showif]
> [showif [error]>1][showif> [lname]=]oops this one is blank[/showif][/showif]
> >

Note that on this first page, the variable [error] is only used intests; no calculations are performed and the value is not changed(except for the initialize, which I said is not needed). [error] is infact a form variable, used to carry the error state from the second pageto the first.> > then on my submitted page I do:> [formvariables]> [showif [value]=][math show=f]error=error+1[/math][/showif]Here, Bob has just defined a math variable, but in such a way that thevariable is never initialized. The previous page did not pass any formvariable called error, so the first formvariable with a null value setsit to error=undef+1, which WebCat cleverly reduces to 1. This is what Ihave repeatedly stated is lazy programming. All page variable should beinitialized to sensible values (usually 0 for math and null for text),and all form variables should be tested to see that they contain a valuethat is reasonable.> [/formvariables]Here, if the user did not supply a value for lname and fname, error=2;if the user missed either but not both, error=1.> [showif [error]>0]This will show if either or both fields are missing.> [redirect> thispage.tpl?error=[error][formvariables]&[name]=[value][/formvariables]]Here, Bob is using form variables to pass back the error state, as wellas any existing values, to the initial page. But as I stated above, ifthe user only misses one value, the Oops... warning will not show atall.> [showif]Note that this should be [/showif]> [fname] [lname] you done good digging through that form.> The problem here is that Bob is trying to use the [error] variable toflag which field is missing, but is really only flagging that there is_some_ field missing. To redesign this page, I am going to use WebDNA3.x logic, nothing fancy. I am going to walk though how I would designthis page, rather than just laying it out in a finished form.I am going to make the following assumptions about how the tempaltesflows: 1) the first page is stand-alone, i.e. it is not initially called asanything except thispage.tpl (i.e. no URL variables or POST formvariables).2) the program should note which field is missing and prompt that fieldalone, as well as retaining any previously entered values.3) Bob actually intended the user to key some values into input fields. As it stands now, these pages do nothing visably, since the user isnever given a chance to key anything, so both fields will forever beblank, unless they were being passed from some other template. I'mgoing to ignore that because that would just require a third page fordata entry.Now, for the first pass at thispage.tpl:



The clever people on this list will notice that this is, in fact, pureHTML. I believe this is the appropriate place to start, since it willdrive the initial interaction with the user. It is also what the pageshould resolve to, once the WebDNA is entered (i.e. everything else willhave hideif/showif's).The second page (nextpage.tpl) will receive 2 defined form variables,either or both which can be null.[text show=f]missing=[/text][!]always init vars[/!][formvariables] [showif [value]=] [text show=f]missing=missing'[name][/text] [/showif][/formvariables][showif [missing]!][redirectthispage.tpl?missing=[missing][formvariables]&[name]=[value][/formvariables]][/showif][fname] [lname] you done good digging through that form.This is pretty much the same as Bob's page, but I changed the name ofthe error variable and what I am doing with it. What I did will meanthat if lname is not entered, then missing='lname; if fname is notentered, missing='fname; and if both are not enteredmissing='fname'lname. The delimiter character can be anything you wantit to be that is not an alphabetic charatcer.Now, the first can be entered upon the redirect, and, in this case, willbe passed exactly three form variables: missing, fname, and lname. Notethat due to the clever coding that Bob did with the redirect, this codecan actually be used to check any number of variables. I would actuallyuse it as an include file and change the thispage.tpl into a parameterfor the include file, i.e.  [include file=checkup.inc&template=thispage.tpl]In any event, let's return to the first page and finish it with theappropriate tests:

[raw][fname][/raw]]value=[fname][/hideif]>[showif [missing]~fname]oops this one is blank[/showif][raw][lname][/raw]]value=[lname][/hideif]>[showif [missing]~lname]oops this one is blank[/showif]

Note that this form will now operate as I believe Bob intended, yet itdoes not need secure=f, nor any complicated hoops to deal with the fieldtesting. In fact, since I separated the form initialization code fromthe blank field warning, you could also call this template asfirstpage.tpl?fname=my&lname=name and still function as it should.If I had a lot more time, I would state categorically that any set ofpages that rely on secure=f can be easily rewritten to not requireit,and that I could do it on demand. I know that I have never needed touse the variable overloading feature, and I have yet to see any codethat convinced me it is useful. I know that there are some schools ofthought that suggest that all form variables (client side) be named witha preceeding underscore (_fname), so that it is painfully obvious thatit is not the same thing as a similarly named text (server side)variable (fname).Hope this helps someone...John Peacock-------------------------------------------------------------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 Web Archive of this list is at: http://search.smithmicro.com/ John Peacock

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:

WC2.0 Memory Requirements (1997) [WebDNA] A universal version of WebDNA ... (2008) How can I Add several Items into the cart at once? (1997) problem (how to mark orders as 'opened') (1998) Date search - yes or no (1997) RequiredFields template (1997) [WebDNA] Sorry WebDNA server not running. (2015) [SearchString] problem with [search] context (1997) Automatically resizing mac jpg's wi applescript (2000) Banner DNA (1997) WebCatalog can't find database (1997) Displaying photo attached to first record (1997) Funny Chars (1999) case sensitivity in lookups (1997) WebCat2 - Getting to the browser's username/password data (1997) [referrer] tag (1997) Auto Submit (2000) [OT] will work for... (2003) WebCat2: Found Items syntax, etc. (1997) Question re: FlushDatabases (1997)