You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by sami <zo...@yahoo.fr> on 2011/02/24 17:44:04 UTC
XSS flaw in Available SOAP services page
On the "Available SOAP services page", I have an XSS injection problem.
Ex :
http://localhost:8080/webapp/services/<script>alert('XSS')</script>
This could be used against site using CXf for phishing.
What do you recommend to prevent that problem?
Thanks,
Emeric
--
View this message in context: http://cxf.547215.n5.nabble.com/XSS-flaw-in-Available-SOAP-services-page-tp3398847p3398847.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Re : XSS flaw in Available SOAP services page
Posted by sami <zo...@yahoo.fr>.
I solved the problem!
I didn't came from CXF but from the Esapi filter (from OWASP) that I used to
checked the http header.
Ironic that a framework provided to improve security can be in fact source
for unsecurity.
I think that the Esapi filter prevented CXF to parse a page containing the
"<" char and redisplayed the service list page but using the url containing
the XSS.
And the CXF service page displayed the XSS in the HTML (I suppose it is
because of the way CXF displays the value of the the "Endpoint address")
So there is no security problem with CXF alone. But CXF + another filter can
cause a problem because the SOAP service page uses the current url to write
the "Endpoit address" value.
Thanks for your help.
Sami
--
View this message in context: http://cxf.547215.n5.nabble.com/XSS-flaw-in-Available-SOAP-services-page-tp3398847p3400135.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Re : XSS flaw in Available SOAP services page
Posted by Glen Mazza <gm...@talend.com>.
Thanks for clarifying, I couldn't understand how we were providing an
ability for an external user to alter the text of the services page.
Now you mention by entering address fields in the browser URL field.
Probably best to enter a JIRA ticket for this. I'll test locally on my
end with a dummy web service to see if I can duplicate.
Glen
On 2/25/2011 8:14 AM, sami wrote:
> However in my case, it is a not a code sent by the developper but a
> non-persistant XSS.
>
> If I type the url :
> http://localhost:8080/webapp/services/
> -> It displays the http://localhost:8080/webapp/services/ page with the next
> text :
> http://localhost:8080/webapp/services/myDefaultWebservice
>
> If I type the url :
> http://localhost:8080/webapp/services/1 -> No such service
>
> If I type the url
> http://localhost:8080/webapp/services/&
> -> It displays the http://localhost:8080/webapp/services/ page with the next
> text :
> http://localhost:8080/webapp/services/&/myDefaultWebservice (Notice the&)
>
> If I type the next url :
> http://localhost:8080/webapp/services/<script>alert('XSS')</script>
> I have the popup displayed!
> Because the next text is displayed :
> http://localhost:8080/webapp/services/<script>alert('XSS')</script>/myDefaultWebservice
>
> If you do not have the same problem, than it means that something else is
> disturbing the CXF flow in my case...
>
> Thanks,
> Sami
>
--
Glen Mazza
Software Engineer, Talend (http://www.talend.com)
blog: http://www.jroller.com/gmazza
Re: Re : XSS flaw in Available SOAP services page
Posted by sami <zo...@yahoo.fr>.
However in my case, it is a not a code sent by the developper but a
non-persistant XSS.
If I type the url :
http://localhost:8080/webapp/services/
-> It displays the http://localhost:8080/webapp/services/ page with the next
text :
http://localhost:8080/webapp/services/myDefaultWebservice
If I type the url :
http://localhost:8080/webapp/services/1 -> No such service
If I type the url
http://localhost:8080/webapp/services/&
-> It displays the http://localhost:8080/webapp/services/ page with the next
text :
http://localhost:8080/webapp/services/&/myDefaultWebservice (Notice the &)
If I type the next url :
http://localhost:8080/webapp/services/<script>alert('XSS')</script>
I have the popup displayed!
Because the next text is displayed :
http://localhost:8080/webapp/services/<script>alert('XSS')</script>/myDefaultWebservice
If you do not have the same problem, than it means that something else is
disturbing the CXF flow in my case...
Thanks,
Sami
--
View this message in context: http://cxf.547215.n5.nabble.com/XSS-flaw-in-Available-SOAP-services-page-tp3398847p3400093.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Re : XSS flaw in Available SOAP services page
Posted by Glen Mazza <gm...@talend.com>.
CXF offers no facility, persistent or non-persistent, for an external
user to alter that text of the services page. Therefore, you don't need
to worry about XSS. Your security society is failing to understand the
difference between malevolent *development team members* who already
have internal access to the system and hence don't need to bother with
XSS (i.e., those who can go into the server settings and alter
configuration files to create a popup), and *malevolent external users*,
the only group for which XSS is a concern.
The code base needs to gummed up with anti-XSS checks only when the
external user does have such an ability. Otherwise, you're adding
security risks by unnecessarily bloating up the code--especially when
the code is being bloated up by Bad Development Guy to begin with. It's
not good to code locks for windows that don't exist.
That said, CXF can probably do a better job in preventing invalid URL
names like popups, but that will not guard against Bad Development Guy,
because he's going to use a valid URL anyway if you give him the chance
to direct external users to his Bad System.
Glen
On 2/25/2011 4:08 AM, sami wrote:
> Hi,
> The main concern of that kind of non-persistant XSS attack is phishing.
> A security society that audited our code highlighted that problem.
> It is a minor security flaw, but it is still a security flaw.
> If there is no easy workaround, I will try to disable the services page on my
> webservices.
>
>
>
>
>
> ________________________________
> De : "Rhenius, Karl Stefan [via CXF]"
> <ml...@n5.nabble.com>
> À : sami<zo...@yahoo.fr>
> Envoyé le : Ven 25 février 2011, 9h 59min 47s
> Objet : RE: XSS flaw in Available SOAP services page
>
> 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.
>
> ________________________________
>
> If you reply to this email, your message will be added to the discussion
> below:http://cxf.547215.n5.nabble.com/XSS-flaw-in-Available-SOAP-services-page-tp3398847p3399776.html
>
> To unsubscribe from XSS flaw in Available SOAP services page, click here.
>
>
>
--
Glen Mazza
Software Engineer, Talend (http://www.talend.com)
blog: http://www.jroller.com/gmazza
Re : XSS flaw in Available SOAP services page
Posted by sami <zo...@yahoo.fr>.
Hi,
The main concern of that kind of non-persistant XSS attack is phishing.
A security society that audited our code highlighted that problem.
It is a minor security flaw, but it is still a security flaw.
If there is no easy workaround, I will try to disable the services page on my
webservices.
________________________________
De : "Rhenius, Karl Stefan [via CXF]"
<ml...@n5.nabble.com>
À : sami <zo...@yahoo.fr>
Envoyé le : Ven 25 février 2011, 9h 59min 47s
Objet : RE: XSS flaw in Available SOAP services page
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.
________________________________
If you reply to this email, your message will be added to the discussion
below:http://cxf.547215.n5.nabble.com/XSS-flaw-in-Available-SOAP-services-page-tp3398847p3399776.html
To unsubscribe from XSS flaw in Available SOAP services page, click here.
--
View this message in context: http://cxf.547215.n5.nabble.com/XSS-flaw-in-Available-SOAP-services-page-tp3398847p3399794.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: XSS flaw in Available SOAP services page
Posted by "Rhenius, Karl Stefan" <ks...@mach.de>.
>
> 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.
Hm .. you may be right - I now tried the link given by sami, but nothing
happened.
I just wanted to answer on your initial question, that XSS is not only
about storing malicious data in a form, that will be shown later, but
also about non persisting things, that are only shown to the victim
clicking a manipulated link.
So I think we misunderstood each other - my answer was unrelated to the
SOAP service page :)
Regards
Karl
Re: XSS flaw in Available SOAP services page
Posted by Glen Mazza <gm...@talend.com>.
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
RE: XSS flaw in Available SOAP services page
Posted by "Rhenius, Karl Stefan" <ks...@mach.de>.
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.
Re: XSS flaw in Available SOAP services page
Posted by Glen Mazza <gm...@talend.com>.
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
On 2/24/2011 12:20 PM, Rhenius, Karl Stefan wrote:
>> But how could Bad Guy inject that on the Available SOAP
>> services page?
>> AFAIK cross-site scripting is only a problem when you allow
>> user entry
>> of fields that are reproduced as-is on HTML pages.
> He can give you a link that misuses a trustworthy domain to show his
> content
>
> Karl
RE: XSS flaw in Available SOAP services page
Posted by "Rhenius, Karl Stefan" <ks...@mach.de>.
> But how could Bad Guy inject that on the Available SOAP
> services page?
> AFAIK cross-site scripting is only a problem when you allow
> user entry
> of fields that are reproduced as-is on HTML pages.
He can give you a link that misuses a trustworthy domain to show his
content
Karl
Re: XSS flaw in Available SOAP services page
Posted by Glen Mazza <gm...@talend.com>.
But how could Bad Guy inject that on the Available SOAP services page?
AFAIK cross-site scripting is only a problem when you allow user entry
of fields that are reproduced as-is on HTML pages.
Glen
On 2/24/2011 11:44 AM, sami wrote:
> On the "Available SOAP services page", I have an XSS injection problem.
> Ex :
> http://localhost:8080/webapp/services/<script>alert('XSS')</script>
>
> This could be used against site using CXf for phishing.
>
> What do you recommend to prevent that problem?
>
> Thanks,
> Emeric