[Geoserver-devel] Some results of (external) security test, cross-site scripting and request for a bit of help on fixes

GeoServer GeoServer Developer
1

Hi list,

Recently a security expert took a look at an application, using Geoserver, I have been working on. I'd like to share some results of that test and discuss two vulnerabilities found. And I am looking for already existing / possible solutions (before starting to develop something myself), so hopefully someone can help.

Background on the test
----------------------
The application involved uses a WMS, a WFS and TMS/WMTS served by GeoServer/GeoWebCache. A very common situation. Note that this instance of GeoServer will not be entirely exposed to the public (for example: the webadmin is not exposed in this case and therefore not vulnerable and the network people have taken some measures). In addition, GeoServer runs in "read-only" mode: editing data is not possible. So the data itself is not at risk.

The security expert has performed several tests and referred to OWASP (https://www.owasp.org) among others. Very interesting stuff. The tests were performed on the (OGC) service interfaces alone.

The issues
----------
The security tests showed only 2 improvements / vulnerabilities for GeoServer. The other tests (like SQL injection etc) all seemed fine, which is good news! So compliments & thanks to the GeoServer team!

The 2 remaining issues are:
1) vulnerability for cross site scripting (XSS). High risk, as identified by the security expert, on a few places
2) (OGC) Service Exceptions expose technical, implementation details. Low risk.

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=&lt;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 :).

re 2)
To me this vulnerability (service exceptions expose technical details) is less relevant, since you can get all information easily once you know that Geoserver is used and you can easily find the documentation and source code. However, my client (and the security expert) wishes to make it hard for hackers-with-bad-intentions to exploit anything. They have a point there. So probably we might end up avoiding stack traces in Service Exceptions. Maybe we could have a flag to set if stack traces should be reported? My client would like to have a solution others could benefit from as well, ideally in the GS code base. Therefore: any thoughts, pointers etc on stack traces in the Service Exceptions are appreciated :). Any ideas?

Ok, enough for now :). (And sorry for the long email..)

Thijs

2

On Mon, Mar 11, 2013 at 6:13 PM, Thijs Brentjens <lists@anonymised.com> wrote:

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 :).

Hmm… I’m afraid I can’t help, but don’t believe there are solutions already in
place for WMTS.

re 2)
To me this vulnerability (service exceptions expose technical details)
is less relevant, since you can get all information easily once you know
that Geoserver is used and you can easily find the documentation and
source code. However, my client (and the security expert) wishes to make
it hard for hackers-with-bad-intentions to exploit anything. They have a
point there. So probably we might end up avoiding stack traces in
Service Exceptions. Maybe we could have a flag to set if stack traces
should be reported? My client would like to have a solution others could
benefit from as well, ideally in the GS code base. Therefore: any
thoughts, pointers etc on stack traces in the Service Exceptions are
appreciated :). Any ideas?

Full stack traces should be included in exception responses only if
“verbose exception reporting” is enabled.
Otherwise you only get the messages from the chain of exceptions, but
not the stack trace per se

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

3

Ok, thanks. I’ll try something then and will let it know. Ah, already implemented (prefectly). Sorry, could have found that one more easily. We’ll try that then first. Thanks!

···

On 11-03-13 20:17, Andrea Aime wrote:

On Mon, Mar 11, 2013 at 6:13 PM, Thijs Brentjens <lists@anonymised.com> wrote:

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 :).

Hmm… I’m afraid I can’t help, but don’t believe there are solutions already in
place for WMTS.

re 2)
To me this vulnerability (service exceptions expose technical details)
is less relevant, since you can get all information easily once you know
that Geoserver is used and you can easily find the documentation and
source code. However, my client (and the security expert) wishes to make
it hard for hackers-with-bad-intentions to exploit anything. They have a
point there. So probably we might end up avoiding stack traces in
Service Exceptions. Maybe we could have a flag to set if stack traces
should be reported? My client would like to have a solution others could
benefit from as well, ideally in the GS code base. Therefore: any
thoughts, pointers etc on stack traces in the Service Exceptions are
appreciated :). Any ideas?

Full stack traces should be included in exception responses only if
“verbose exception reporting” is enabled.
Otherwise you only get the messages from the chain of exceptions, but
not the stack trace per se

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

4

Hello,

re GEOS-4210, this is the commit I meant in the comment
<https://github.com/GeoWebCache/geowebcache/commit/f4b3d357533b8ba1f05965fc57098bb5250b067b&gt;

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
<lists@anonymised.com> 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=&lt;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 :).

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

5

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=&lt;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 :slight_smile: (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&gt;

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
<lists@anonymised.com> 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=&lt;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 :).

6

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=""/><axmlns:a='http://www.w3.org/1999/xhtml'><a:body%20onload="alert('xss')"/></a> )

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=&lt;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 :slight_smile: (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&gt;

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
<lists@anonymised.com> 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=&lt;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

7

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 (lists@anonymised.com) 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=""/><axmlns:a='http://www.w3.org/1999/xhtml'><a:body%20onload="alert('xss')"/></a>
    )

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:body onload=“alert(‘xss’)”/>

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 … ). 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 :slight_smile: (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
lists@anonymised.com 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:body onload=“alert(‘xss’)”/>.

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

8

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 (lists@anonymised.com <mailto://lists@anonymised.com>) 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=""/><axmlns:a='http://www.w3.org/1999/xhtml'><a:body%20onload="alert('xss')"/></a>

)

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=&lt;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 :slight_smile: (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&gt;
>>
>> 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
>> <lists@anonymised.com> 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=&lt;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

9

Please submit pull request, if not you can revisit this next time you do an “external” security review on a newer version of GeoServer :slight_smile:

···

Jody Garnett

On Wed, Jan 22, 2014 at 3:41 AM, Thijs Brentjens <lists@anonymised.com> 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 (lists@anonymised.com) 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:body onload=“alert(‘xss’)”/>

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 … ). 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 :slight_smile: (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
lists@anonymised.com 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:body onload=“alert(‘xss’)”/>.

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