Afternoon Thijs:
I wanted to check back and see if you contributed your fix back to the
GeoServer project?
I remembered that you had found a fix, and wanted to make sure you were in a
position to submit a patch and so forth.
--
Jody Garnett
On 14 March 2013 at 8:55:15 am, Thijs Brentjens (li...@brentjensgeoict.nl)
wrote:
Hi,
Got further and think I have a solution. Happy to get feedback, it has
been a while since I've actually coded something this way :).
Note: worked on a fork of the geoserver code, for now in the 2.1.x
branch, because I need a fix here. See
https://github.com/thijsbrentjens/geoserver/commit/ba5c0ecb1cc72878b2bdd3db84239d30eb779000
for changes. Should work for other versions as well.
Background. The problems with XSS vulnerabilities arise here:
1. In ServiceExceptions for OGC-style services (wms, wfs etc) the
vulnerability for XSS exists, because of reporting back the input in the
exceptiontext and the locator-part of the exceptions un-encoded.
2. In the WMS OpenLayers outputformat XSS vulnerability is caused by
writing the request parameters directly (unescaped) in the JavaScript
output as specified in the Openlayers template.
http://jira.codehaus.org/browse/GEOS-5318
3. through GWC WMTS and WMS interface. Exceptions are reported a bit
differently here. Bug report: http://jira.codehaus.org/browse/GEOS-4210,
but found some other XSS vulnerability.
4. in the web-admin. For the projects where I work on, the XSS
vulnerability in the web-admin is less relevant, since the webadmin is
not accessible publicly.
I have fixes available for 1 to 3. I haven't got time for 4., but hope
my examples might help others if needed. The OWASP encoder
(https://www.owasp.org/index.php/OWASP_Java_Encoder_Project) library
seemed very useful to me. It provides encoders for several context as
they call it. E.g. for XML output, HTML or JavaScript. To me it looked
the easiest and most reliable for encoding. The OWASP website also
provides lots of information on XSS and other vulnerabilities.
What I did:
1. in the platform, ows and wms packages: add the OWASP encoder library
for encoding easily for different context (e.g. encode for HTML, XML or
JavaScript)
2. changed ServiceException.java: make sure that the exception text and
locator are encoded for output in XML (as text and attribute).
3. in the OpenLayersMapOutputFormat class: encode the input parameters
for JavaScript output.
4. in util.OwsUtils added encoding for error messages, for all messages,
to make sure they are encoded properly (this makes sure that XSS does
not work with something like:
http://localhost:8080/geoserver/gwc/service/wmts?request=%22%22/%3E%3Caxmlns:a=%27http://www.w3.org/1999/xhtml%27%3E%3Ca:body%20onload=%22alert%28%27xss%27%29%22/%3E%3C/a%3E
)
Hopefully the code is clear. I used a less elegant solution first for
the ServiceException class (that is in an earlier commit), please be
aware of that when looking at the differences compared to the original
2.1.x source.
Probably, it could be done better or improved somewhere. I have done
several tests (for XSS), but would really like more (functional) tests
for the OpenLayers preview. For my cases it works fine though. Am very
curious if it's okay for you and usable for others as well.
So please feel free to try and give any feedback! And if I can do
anything to help it further, just let me know.
Thijs
On 13-03-13 12:02, Thijs Brentjens wrote:
> Hello Gabriel,
>
> Thanks for looking it up and pointing to the code! For the SRS parameter
> the solution you implemented seems to be good. The thing is, other
> (invalid) input could also be used for XSS.
>
> If you would send this request to a Geoserver instance:
> http://localhost:8080/geoserver/gwc/service/wmts?request=<a
> xmlns:a='http://www.w3.org/1999/xhtml'><a:body onload="alert('xss')"/></a>
>
> the script gets executed. So the request-parameter is vulnerable (SRS
> seems okay). In fact, most WMTS parameters seem to be vulnerable. I took
> a valid, working WMTS request and replaced several parameter values
> (like the format, request and tilematrixset params) with the value in
> the example above ( <a .... etc ... </a> ). If you execute that, the
> service exception triggers browsers to execute the script.
>
> If the exception report would HTML encode the input value of the
> parameter (if reporting it) that caused the exception, it should be fixed.
> The website
> https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
>
> lists some measures that could be taken for all kinds of XSS. I think
> for Service Exceptions there is no need to cover all defenses. HTML
> encoding would do (there is no data input through CSS in a Service
> Exception for example..) because the input values are only reported in
> the "body" of the service exception. But I'll check that.
>
> I also just found a WMS vulnerability, in Geoserver 2.2.4. Just to be
> sure: the best would be if all Service Exceptions (in fact: all
> exception reports that report back the input) would always encode any
> input parameter before writing the exception, that would fix a lot of
> issues.
>
> I'm happy to help (will try something soon ) and provide more test
> requests. Not sure if sending these on the mailinglist is such a good
> idea :) (from a security point of view). So let me know.
>
> Thanks in advance!
>
> Thijs
>
> On 13-03-13 04:15, Gabriel Roldan wrote:
>> Hello,
>>
>> re GEOS-4210, this is the commit I meant in the comment
>> <https://github.com/GeoWebCache/geowebcache/commit/f4b3d357533b8ba1f05965fc57098bb5250b067b>
>>
>>
>> Looks like I was too lazy at the moment as to chase it down but its
>> easier with git now.
>>
>> The way I understand it is that an exception will be thrown when
>> attempting to parse the SRS parameter which ultimately will be handled
>> by that writeError method in GeoWebcacheDispatcher. If you can confirm
>> that's not what's going on and the XSS vulnerability exists while
>> calling a gwc service I'll be glad to look deeper into it.
>>
>> Cheers,
>> Gabriel
>>
>> On Mon, Mar 11, 2013 at 2:13 PM, Thijs Brentjens
>> <li...@brentjensgeoict.nl> wrote:
>>> re 1):
>>> There is/was some discussion on XSS already, I noticed:
>>> http://jira.codehaus.org/browse/GEOS-5318 --> still open
>>> http://jira.codehaus.org/browse/GEOS-4210 --> says for GWC a fix has
>>> been done a while ago.
>>> From another source:
>>> http://itsecuritysolutions.org/2012-04-13-ActiveX,-Remote-DoS-and-XSS/,
>>> also lists some XSS vulnerabilities for GS 2.1.4
>>>
>>> Summary: in 2.1.x XSS can be used by exploiting the Service Exceptions
>>> for WMS and WFS. This is confirmed in our test. In 2.2.x this seems to
>>> be fixed already for WMS and WFS. However 2.2.x versions still are
>>> vulnerable. For example: WMTS by GWC is vulnerable,
>>> http://localhost:8080/geoserver/gwc/service/wmts?request=<a
>>> xmlns:a='http://www.w3.org/1999/xhtml'><a:body onload="alert('xss')"/></a>.
>>>
>>>
>>> Before I get my hands dirty myself: has someone a solution available
>>> maybe (I can't see any activity now, but you never know) or knows of
>>> something? Or can someone point me to where the fixes between 2.1 and
>>> 2.2 have been done to avoid XSS? Maybe I could use that for my client
>>> (and in the end others) and use it to fix some other XSS issues as well.
>>> If not, I'll dive into the code :).
>>
>>
>
> ------------------------------------------------------------------------------
>
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
