But, again, Karl, I can't see the relevance to the system generated SOAP
services page, because there is no facility for the user, persistent or
non-persistent, to alter the text on that page.
Persistent -- user has an entry page where he can enter fields that
subsequently get output on the service page. CXF has no such entry
page, so XSS is not a concern here.
Non-persistent - user can enter data that gets saved into a database,
that later gets displayed on the service page. CXF has no facility for
the user to enter data that will subsequently be stored on the services
page, so again, XSS is not a concern.
Before you fret over whether the window has a lock on it or not, there
has to be a window first. And CXF has no window here.
It is never XSS if an ill-intentioned *developer* of the system is able
to manipulate something to create a popup (i.e., internally change CXF
settings so the service has a pop-up) because, having access to the code
and data, such an ill-intentioned developer already has full access to
the system to do Bad Things. XSS only kicks in when a third-party
individual (external user) is able to alter the services page, which CXF
simply does not permit.
Glen
On 2/25/2011 3:48 AM, Rhenius, Karl Stefan wrote:
Hi Glenn,
there are persistent and non-persistent XSS attacks.
http://en.wikipedia.org/wiki/Cross-site_scripting describes an exploit
scenario for non-persisting XSS attacks.
Karl
But giving somebody a fraudulent link is not cross-site
scripting, and
browser certificate checks would catch that anyway.
Only the service provider has control over the contents of the
https://www.mybank.com/services/BankingService?wsdl page, Bad
Guy has no
opportunities to enter in data that could alter that page, so I don't
see where the XSS concern is.
--
Glen Mazza
Software Engineer, Talend (http://www.talend.com)
blog: http://www.jroller.com/gmazza
