This is correct. The <@USERREFERENCEARGUMENT> is no longer necessary with modern browsers, proxies and security practices. Witango by default supplies and prefers a session cookie to support session management and use of <@USERREFERENCE> in the User scope key.
I will update the builder HTML output and snippets to remove the <@USERREFERENCEARGUMENT> and fix up a few other errors. If anyone would like to make comments or suggestions regarding the builders HTML output, please do so. Robert From: Roland Dumas [mailto:[email protected]] Sent: Friday, December 10, 2010 1:07 PM To: [email protected] Subject: Re: Witango-Talk: Alternate Dumb Question Thread: Security A long-term and easily addressed security issue with tango/witango is the use of _userreference argument in the URL. The builders default to using this. LIkely, back in the early pre-pleistocene days of tango, it was practical to pass this argument in the URL because of cookies being blocked or something like that. Using this feature enables session hijacking and other evils. If you use builders, you should strip out this URL argument. Otherwise, don't do it. On Dec 3, 2010, at 11:14 AM, Deutschendorf, Steve {Dutch} (MSFC-IS30) wrote: Well, I misspoke, we also have a few v5.0.1 sites. Thanks, Robert. Steve Deutschendorf/IS30 NASA/Marshall Space Flight Center Office of the CIO/Applications Team MSFC Account Authorization Official (AAO), MAMS/MIW, NISE, NAMS, MICS, AIM, SRS Phone: 256-544-2250 _____ From: Robert Garcia <[email protected] <x-msg://45/[email protected]> > Reply-To: "[email protected] <x-msg://45/[email protected]> " <[email protected] <x-msg://45/[email protected]> > Date: Fri, 3 Dec 2010 13:00:30 -0600 To: "[email protected] <x-msg://45/[email protected]> " <[email protected] <x-msg://45/[email protected]> > Subject: Re: Witango-Talk: Alternate Dumb Question Thread: Security The only real security issue we ever worried about with witango, is SQL injection, and then just poor coding as it relates to login methodologies where there are "holes", that would occur on any platform. So you should always use BIND or database actions, not custom inserts/updates when user inputted data is going into a query. Witango had a flaw that was patched, so make sure you are on the latest 5.5. Witango will be secure, because it has so little market share, no one is likely to work to exploit it. Anyway, other than that one buffer overflow security patch, I have not seen or heard of a security flaw that was related to witango, it has always been due to poor coding. -- Robert Garcia President - BigHead Technology VP Application Development - eventpix.com <http://eventpix.com <http://eventpix.com/> > 15520 Coutelenc Rd Magalia, Ca 95954 ph: 530.645.4040 x222 fax: 530.645.4040 [email protected] <x-msg://45/[email protected]> - [email protected] <x-msg://45/[email protected]> http://bighead.net/ - http://eventpix.com/ On Dec 3, 2010, at 10:41 AM, Deutschendorf, Steve {Dutch} (MSFC-IS30) wrote: Folks, We've had (Wi)Tango around for a dozen years and I can say it's been worry free in our environment. The fact that it still functions after various degrees of support (or not) over those years is a credit to the foundational work. I can't say that I've seen much discussion on the security implications of the product along the way, so let me ask... What are the security implications in remaining with v5.5 for some of our legacy applications? Looks like we'll be moving to a different environment over time (for various support reasons), so I just wanted to appreciate the risk of hanging with my current version. I realize the product/OS support will eventually force an upward migration. Are there current issues with v5.5 that I may be unaware or is it by it’s very nature strictly dependent on the security gaps in the OS or database? Thanks, Steve Deutschendorf/IS30 NASA/Marshall Space Flight Center Office of the CIO/Applications Team Phone: 256-544-2250 _____ To unsubscribe from this list, please send an email to [email protected] <x-msg://45/[email protected]> with "unsubscribe witango-talk" in the body. _____ To unsubscribe from this list, please send an email to [email protected] <x-msg://45/[email protected]> with "unsubscribe witango-talk" in the body. _____ To unsubscribe from this list, please send an email to [email protected] with "unsubscribe witango-talk" in the body. _____ To unsubscribe from this list, please send an email to [email protected] with "unsubscribe witango-talk" in the body. ---------------------------------------- To unsubscribe from this list, please send an email to [email protected] with "unsubscribe witango-talk" in the body.
