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/25 10:08:14 UTC
Re : XSS flaw in Available SOAP services page
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: 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