Actually, ENCODING=NONE can expose you to a XSS attack, too. By default encoding I mean the default behaviour in a Results, No Results or Error page when no ENCODING is specified. Witango will escape stuff by default.
<@ARG myInput> will evaluate to ">script..." if I post "<script...". The browser will display "<script..." <@ARG myInput ENCODING=NONE> will evaluate to "<script..." if I post "<script...". The browser may execute the script. -----Original Message----- From: Fogelson, Steve [mailto:[EMAIL PROTECTED] Sent: Friday, April 27, 2007 4:45 PM To: [email protected] Subject: RE: Witango-Talk: Cross Site Scripting Vulnerability Thanks for all the responses. By default encoding, do you mean encoding="none"? Thanks Steve -----Original Message----- From: William M. Conlon [mailto:[EMAIL PROTECTED] Sent: Friday, April 27, 2007 3:43 PM To: [email protected] Subject: Re: Witango-Talk: Cross Site Scripting Vulnerability Agreed. this is one nice aspect of Witango -- the default encoding can thwart XSS. And the automatic databinding can thwart SQL injection! -- Bill ---------- Original Message ----------- From: Jason Pamental <[EMAIL PROTECTED]> To: [email protected] Sent: Fri, 27 Apr 2007 15:05:43 -0400 Subject: Re: Witango-Talk: Cross Site Scripting Vulnerability > Steve, > > This sort of attack depends solely on what you are taking in being > displayed on screen. So while there is obviously a need for basic > validation on whatever you are taking in, it's not necessary to > defend against these sorts of attacks. I've been thinking about it > quite a bit lately and was thinking about some sort of custom tag > that would simply remove any sort of strings that evaluate to > '<script>' (or <script ...>) with nothing. Once you do that, none of > the code will work, and you only need to do it on 'confirm' sorts > of pages for form submission, or use it on insertion into a > database for any bits that are going to be displayed on a page > (body copy for a dynamic web page, etc). > > So something like <@customXSStagname value="<@arg youwanttoclean>"> > would in turn use a series of '<@replaces>' or something like that > to clean the string you're passing into it and then evaluates to > displaying that result. If we created the tag, TCF and maybe an > external file we can easily modify with new strings to check for as > time goes on it could be a really valuable tool for the whole > community. I'd certainly be willing to help out with it - I've found > an interesting page hosted by (I think) some hackers detailing just > how to go about conducting these attacks, so by reverse engineering > what they're suggesting it would be a great start to dealing with > the threat. > > Regards, > > Jason > > ps - there was a really good couple of podcasts about this on > Security Now - very worth listening to: > http://www.grc.com/securitynow ) > > ----- > > Jason Pamental > Director of Web Services > North Sails > > Office: 401.643.1415 > Fax: 401.643.1420 > Mobile: 401.743.4406 > Email: [EMAIL PROTECTED] > > On Apr 27, 2007, at 2:45 PM, Fogelson, Steve wrote: > > > Hi, > > > > After doing additional research it appears I need to check all > > incoming > > arguments whether hidden or contained in the url. I thought I would > > do the > > following > > > > 1) Find all the arguments with <@ASSIGN request$mySEARCHargs > > VALUE="<@SEARCHARGNAMES>"> > > > > 2) Change the args to request scoped vars > > > > 3) Sanitize them by removing these characters & ' " > < ( ) > > [ ] ; : / { } ! > > -- = _ > > > > I was also thinking about pre-pending argument names for forms with a > > character to define that this arg is a number, alpha/numeric, > > telephone > > number, etc. and then validate the field accordingly as well. > > > > All of this would be done server side in my housekeeping tcf. > > > > I would appreciate if anyone could tell me if I am on the right > > path and > > post any suggestions as well. > > > > Thanks > > > > Steve Fogelson > > > > -----Original Message----- > > From: Fogelson, Steve [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 26, 2007 9:48 PM > > To: [email protected] > > Subject: Witango-Talk: Cross Site Scripting Vunerability > > > > Hi, > > > > I just signed up with HackerSafe to scan one of my sites. Well I > > have Cross > > Site Scripting Vunerability on some of my pages. IE: Login, adding > > a new > > customer, adding billing and shipping info, etc. Any page that has > > a form on > > it. > > > > I have researched the Witango forum and didn't find anything, but I > > might > > have used the incorrect search criteria. It appears that the > > solutions are > > the following: > > 1) Don't allow any html tags > > 2) Don't allow any quotes > > 3) Don't allow any parenthesis > > So it looks like I need to filter each field (argument) for the > > above and > > remove it. > > > > I would appreciate any info, filters, etc that anyone could provide. > > > > Thanks in advance. > > > > Steve Fogelson > > Internet Commerce Solutions > > ______________________________________________________________________ > > __ > > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > ______________________________________________________________________ > > __ > > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > > > > > Visit us at http://www.northsails.com > > > > [This E-mail scanned for viruses by Declude Virus] > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ------- End of Original Message ------- ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
