[WebDNA] Are your sandbox prefs broken? (If not, are you vulnerable to formvar hacks?)
This WebDNA talk-list message is from 2011
It keeps the original formatting.
numero = 107352
interpreted = N
texte = Hey guys You well remember the security hole when someone passes a get or post = formvar named after a webdna wrapper tag.. well someone (or everyone) = please help me confirm an issue that I am amazed that I seem to be the = first one to discover, and which I am guessing is affecting more than = just my 3 clients I have on one host (have not checked my other = clients/hosts yet): ** Step 1.) Install (input and *save*) some version of the security = patch code in your pre-parse script (if you have not already), like e.g. = this one Donovan came up with (which is more compact and likely less-CPU = intensive than the other one that was floating on this list before) : [formvariables name=3Dtext][redirect url=3Dindex.html][/formvariables] = [text]t_commands=3D|[url]![/url]|addfields|addlineitem|append|appendfile|a= pplescript|arrayget|arrayset|authenticate|boldwords|browsername|calcfilecr= c32|capitalize|cart|case|clearlineitems|closedatabase|command|commitdataba= se|convertchars|convertwords|copyfile|copyfolder|countchars|countwords|cre= atefolder|date|ddeconnect|ddesend|decrypt|delete|deletefile|deletefolder|d= os|elapsedtime|else|encrypt|exclusivelock|filecompare|fileinfo|findstring|= flushcache|flushdatabases|format|format|formvariables|founditems|freememor= y|function|getchars|getcookie|getmimeheader|grep|hideif|html1|html2|html3|= httpmethod|if|include|input|interpret|ipaddress|issecureclient|lastautonum= ner|lastrandom|lineitems|listchars|listcookies|listdatabases|listfields|li= stfiles|listmimeheaders|listpath|listvariables|listwords|lookup|lookup|loo= p|lowercase|math|middle|movefile|object|orderfile|password|platform|produc= t|protect|purchase|random|raw|redirect|referrer|removehtml|removelineitem|= replace|replacefounditems|retu = rn|returnraw|scope|search|sendmail|setcookie|setheader|setlineitem|setmime= header|shell|showif|shownext|spawn|sql|sql|sqlconnect|sqldisconnect|sqlexe= cute|sqlinfo|sqlrelease|sqlresult|switch|table|tcpconnect|tcpsend|then|thi= surl|time|unurl|uppercase|url|username|validcard|version|waitforfile|write= file|xmlnode|xmlnodes|xmlnodesattributes|xmlparse|xsl|xslt|[/text] [formvariables] [showif [t_commands]^|[url][name][/url]|] [redirect url=3Dindex.html] [/showif] [/formvariables] ** Step 2.) Now try to alter one of your sandbox preferences, and save = them. You can even just leave every pref. set as it is... just save = them. If you experience what I seem to be experiencing.. then you find that = instead of saving, you got redirected to wherever your patch (above) = said to redirect when an 'illegal' formvar was passed. ?! The = internal pref-saving sandbox form submits a form var named after a = webdna tag?? =20 I have not tried this on my webdna 7 local install yet.. nor on any = version 6- install that does not use a sandbox.. but so far the issue = is confirmed on one machine running webdna version 6 , and on another = machine running webdna version 6.2 - both using sandboxes. IIRC the host I am lately working with told me that he tried it on his = master webdna pref-saving form and the issue arises there too.. implying = the issue is not only in sandboxes. My first thought was just to confirm the issue with you all here. = Please try it! My second thought, as workaround, was to set up a conditional in the = pre-parse script that checks [thisurl] to see if we are in the sandbox = admin area or not.. before applying our patch. My third thought is to = look again if I can find the formvar in the pref-saving form which is = actually causing the patch to fire a [redirect] (my first glance did not = find it), and where. Your thoughts? -Govinda=
Associated Messages, from the most recent to the oldest:
Hey guys You well remember the security hole when someone passes a get or post = formvar named after a webdna wrapper tag.. well someone (or everyone) = please help me confirm an issue that I am amazed that I seem to be the = first one to discover, and which I am guessing is affecting more than = just my 3 clients I have on one host (have not checked my other = clients/hosts yet): ** Step 1.) Install (input and *save*) some version of the security = patch code in your pre-parse script (if you have not already), like e.g. = this one Donovan came up with (which is more compact and likely less-CPU = intensive than the other one that was floating on this list before) : [formvariables name=3Dtext][redirect url=3Dindex.html][/formvariables] =
[text]t_commands=3D|
[url]![/url]|addfields|addlineitem|append|appendfile|a= pplescript|arrayget|arrayset|authenticate|boldwords|browsername|calcfilecr= c32|capitalize|cart|case|clearlineitems|closedatabase|command|commitdataba= se|convertchars|convertwords|copyfile|copyfolder|countchars|countwords|cre= atefolder|date|ddeconnect|ddesend|decrypt|delete|deletefile|deletefolder|d= os|elapsedtime|else|encrypt|exclusivelock|filecompare|fileinfo|findstring|= flushcache|flushdatabases|format|format|formvariables|founditems|freememor= y|function|getchars|getcookie|getmimeheader|grep|hideif|html1|html2|html3|= httpmethod|if|include|input|interpret|ipaddress|issecureclient|lastautonum= ner|lastrandom|lineitems|listchars|listcookies|listdatabases|listfields|li= stfiles|listmimeheaders|listpath|listvariables|listwords|lookup|lookup|loo= p|lowercase|math|middle|movefile|object|orderfile|password|platform|produc= t|protect|purchase|random|raw|redirect|referrer|removehtml|removelineitem|= replace|replacefounditems|retu = rn|returnraw|scope|search|sendmail|setcookie|setheader|setlineitem|setmime= header|shell|showif|shownext|spawn|sql|sql|sqlconnect|sqldisconnect|sqlexe= cute|sqlinfo|sqlrelease|sqlresult|switch|table|tcpconnect|tcpsend|then|thi= surl|time|unurl|uppercase|url|username|validcard|version|waitforfile|write= file|xmlnode|xmlnodes|xmlnodesattributes|xmlparse|xsl|xslt|[/text]
[formvariables] [showif [t_commands]^|
[url][name][/url]|] [redirect url=3Dindex.html] [/showif] [/formvariables] ** Step 2.) Now try to alter one of your sandbox preferences, and save = them. You can even just leave every pref. set as it is... just save = them. If you experience what I seem to be experiencing.. then you find that = instead of saving, you got redirected to wherever your patch (above) = said to redirect when an 'illegal' formvar was passed. ?! The = internal pref-saving sandbox form submits a form var named after a = webdna tag?? =20 I have not tried this on my webdna 7 local install yet.. nor on any = version 6- install that does not use a sandbox.. but so far the issue = is confirmed on one machine running webdna version 6 , and on another = machine running webdna version 6.2 - both using sandboxes. IIRC the host I am lately working with told me that he tried it on his = master webdna pref-saving form and the issue arises there too.. implying = the issue is not only in sandboxes. My first thought was just to confirm the issue with you all here. = Please try it! My second thought, as workaround, was to set up a conditional in the = pre-parse script that checks
[thisurl] to see if we are in the sandbox = admin area or not.. before applying our patch. My third thought is to = look again if I can find the formvar in the pref-saving form which is = actually causing the patch to fire a
[redirect] (my first glance did not = find it), and where. Your thoughts? -Govinda=
Govinda
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:
Re:2nd WebCatalog2 Feature Request (1996)
CommitDatabase vs. CloseDatabase (2001)
Re[2]: 2nd WebCatalog2 Feature Request (1996)
Help! WebCat2 bug (1997)
Transferring textareas (1997)
Frames and WebCat (1997)
select multiple (1997)
Discounts (1998)
Multiple Form Fields (2000)
WebCommerce: Folder organization ? (1997)
WebCat editing, SiteGuard & SiteEdit (1997)
[OT] (waaaay OT) further off topic than before (2004)
Emails stuck in emails folder (2003)
[OT] "Hacker Safe" (2007)
[isfolder] and [filename] (1997)
WebMerchant/MacAuthorize (1998)
Country & Ship-to address & other fields ? (1997)
Math (1997)
WebCat2 Append problem (B14Macacgi) (1997)
Nested tags count question (1997)