Please submit pull request, if not you can revisit this next time you do an
"external" security review on a newer version of GeoServer :)
Jody Garnett
On Wed, Jan 22, 2014 at 3:41 AM, Thijs Brentjens
<li...@brentjensgeoict.nl>wrote:
> Hi Jody,
>
> Sorry for a very, very late reply. I totally missed this email (ouch)...
>
> I didn't submit a patch or create a pull request yet. Only shared the
> information below. I have fixes for the 2.1.x series (
> https://github.com/thijsbrentjens/geoserver/commit/ba5c0ecb1cc72878b2bdd3db84239d30eb779000).
> Shall I create a pull request?
>
> I remembered looking at the 2.4.x code and trying to port the fixes to
> 2.4.x as well, but that code has had quite some changes I remeber. I
> couldn't find the classes to fix as easy. Will take a look again.
>
> Thijs
>
>
> On 17/12/13 07:07, Jody Garnett wrote:
>
> 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<//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><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> <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
>
>
>
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
