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
