OGR WCTS Implementation

Deprecated: See Security Concern section below.

As a part of a project to implement a Coordinate Transformations Server for DM Solutions Group I am implementing a WCTS (Web Coordinate Transformation Server) attempting to conform to the OpenGIS internal discussion paper 02-061r2. This paper can be found in the OpenGIS internal documents are for OpenGIS members.

Note that this is not yet a specification, it is a proposal that might be adopted as a specification at some point, likely after further changes. Thus WCTS is a protocol in flux.

This implementation is based on the OGRSpatialReference class within the GDAL/OGR library. The underlying projections engine is PROJ.4, and the GML support from OGR is used.

The code implementing the server can be found in the GDAL/OGR CVS tree in the gdal/ogr/wcts directory, along with some sample request documents. Currently all the server specific code is in the ogrwcts.cpp file in this directory.

Some Implementation Details on features and limitations of the server are available. There is also an Installation and Configuration document.

Some sample XML input requests are available for the following requests:

A development server is running at http://maps.gdal.org/cgi-bin/ogrwcts. Some sample KVP encoded requests are:

Note that WCTS does not support KVP (including the arguments in the URL) usage for the actual transformation operations, so you need something that can PUT the XML request data to utilize the transform operator.

An HTML form based client (backed by a cgi-bin program) has been implemented for user interface to WCTS services and testing.

Security Concern

The OGR WCTS server has been moved to "spike" due to lack of maintenance and a non-trivial SSRF security bug. In light of this problem, it is advised that this service only be used with caution. Robert Coup describes it this way:

If the WCTS stuff is compiled with -DHAVE_CURL, then the ogrwcts process is vulnerable to SSRF. The wctsclient process (which looks to me like a cgi server) is always vulnerable, since it doesn't care about -DHAVE_CURL.

(a) Either passing in a user-supplied URL which isn't validated before requesting it - this leaves "internal" http services which should only be readable to the server readable to any client.

(b) Using a redirect to the gopher protocol a client can send HTTP POST requests or other payloads to any host accessible to the server. *Why* curl enables the gopher protocol is beyond me, but it does.

We can protect against (b) by disabling redirect-following (CURLOPT_FOLLOWLOCATION=0). But we can't really protect against (a) at all without adding some black/whitelist of IP addresses.

Steps to reproduce:

Overview:

  1. send evil request to wctsclient or ogrwcts services
  2. wcts requests client-specified http url (via in ogrwcts, or WCTSServer/GMLURL in wctsclient)
  3. either that reveals private inf

Other WCTS Implementations

Currently there is only one other WCTS implementation in existance. That is the one done by lat/lon, the folks that write the WCTS document. That implementation is also open source, and can be found within the deegree project.

A user form for interacting with an instance of the deegree based server is available at lat/lon .