-
-
Notifications
You must be signed in to change notification settings - Fork 364
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Buffer overflow in WFS xsi:schemaLocation #4413
Comments
|
what query string are you using, I'm not managing to reproduce this |
|
I'm suspecting the mapfile you provided isn't exactly the one where you're getting this issue. When running with your mapfile, I get |
|
Hi Tom, Thank you for looking into this. I might have removed some layers from the mapfile but apart from that I did not modify it. The mapfile seems to work fine on my system. I should have mentioned that my environment is: OS: Microsoft Windows 7 64-bit Enterprise I pass the mapfile path to Mapserver via an environment variable using the following directive: SetEnvIf Request_URI "/test-wms" MS_MAPFILE=/GIS/apps/demo-map/world.map The datasets used by the map are: http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/110m/cultural/110m-admin-0-countries.zip http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/110m/cultural/110m-populated-places.zip To facilitate the debugging I have translated the HTTP POST request to an equivalent GET request. The error is a little bit random and does not always result in an invalid XML file. I have taken a screenshot of a GET request that failed (http://i.imgur.com/TgGif.png). The entire (unmodified) mapfile is: |
|
Tom, your comment about the missing "onlineresource" metadata brought me to an idea to try to add the "wfs_onlineresource" "https://127.0.0.1:8443/test-wms?" URL to my mapfile (i.e., instead of relying only on the "ows_service_onlineresource" URL). When "wfs_onlineresource" is defined than this bug does not happen. So, it seems that this bug might have something to do with a scenario when Mapserver tries to automatically detect the "onlineresource" URL as described here: http://mapserver.org/ogc/wfs_server.html in the "Configuring your MapFile to Serve WFS layers". Hope this helps to narrow down the issue. |
|
@josefbicik I still cannot reproduce your issue. Which version are you testing this on? Using your unmodified mapfile you updated, I'm getting: i.e. the corrupt block does not show up at all ... |
|
with the previous fix, I'm now getting: i.e., still nothing .... |
|
OK, I was running from the command line, and was missing a few env vars to get this running. I'm now getting: Note that the URL is built from the ows_onlineresource metadata key, and not the ows_service_onlineresource. If ows_onlineresource is not set, then it is built using the env vars set by the webserver. |
|
Hi Tom, this is the version of Mapserver I used for this test. MapServer version 6.0.3 (MS4W 3.0.6) OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=KM and also: MapServer version 6.2.0-beta2 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=KML SUPPO |
|
You are right that the "ows_onlineresource" was missing in the mapfile. Nevertheless, even the xsi:Schema you posted does not seem to be entirely correct since there is an "&" entity missing there between map and SERVICE ("...test2.mapSERVICE..."). I still think that there is a bug in the code that determines the "ows_onlineresource" URL from the server when it is not defined in the mapfile. |
|
@josefbicik can you confirm this commit fixes your issue ? |
|
Thank you for fixing the problem! I can confirm that the issue with invalid characters in the URL no longer occurrs after applying your fix to 6.2-beta2. As you suggested the correct approach is to specify the "ows_onlineresource" URL in the mapfile. |
There seems to be a buffer-overflow bug in WFS server response in the xsi:schemaLocation section when the URL defined in "ows_service_onlineresource" is HTTPS with a non-standard port (e.g., "https://127.0.0.1:8443/test-wms?"). This affects Mapserver 6.0.3 and also 6.2beta2. The buffer overflow results in the generation of an invalid XML response that cannot be parsed by the client. See part of the XML response below (strange characters after https://127.0.0.1:8443/test-wms?):
My mapfile is:
And the POST request looks like:
The text was updated successfully, but these errors were encountered: