Reminder: the XML 2007 Call for Participation deadline is tomorrow. Thanks to the many people who have already sent in proposals.
While we haven’t chosen the actual presentations yet, there is now an overview schedule of the XML 2007 conference (3-5 December, Boston) available to help you schedule your visit. The registration page will be going online soon. Hope to see you there!
I love Google Maps and their API, and am using it extensively in my new web site OurAirports. However, there are two problems that keep coming up for using Google Maps with an aviation application:
![[Diagram of Mercator projection]](http://upload.wikimedia.org/wikipedia/commons/thumb/6/62/Usgs_map_mercator.svg/413px-Usgs_map_mercator.svg.png)
Google Maps uses a Mercator Projection, grossly distorting the northern and southern parts of the world, and cutting off the area near the poles so that a few of the Antarctic airports don’t show up on my maps at all. I can understand the reasons for their choice, with simple panning and tile paging and a rectangular area, but it can make things look pretty silly sometimes (such as Greenland and Africa appearing the same size).
Google Maps does not provide an API call to draw a great-circle path. This seems to me to be almost a no-brainer, and it’s especially important in a Mercator projection, where the apparently straight paths drawn by the API are anything but (especially east-west). After messing with some out-of-date third-party libraries, I finally found some JavaScript at one site that does a good job on efficient, approximate great-circle paths, and am waiting to hear from the author about terms for reuse. Google might want to just go ahead and add this, though.
![[Diagram of Mercator projection]](http://upload.wikimedia.org/wikipedia/commons/6/62/Usgs_map_lambert_conformal_conic.PNG)
Aviation charts mostly use a Lambert conformal conic projection, which ensures that distances are preserved (any two points the same distance apart on the chart are the same distance apart in the real world); however, by definition this projection can’t show more than half the world at once, and generally shows much less than that, so it wouldn’t work for something like Google Maps.
The deadline for paper proposals for XML 2007 is only 11 days away, on 31 August 2007.
Last year, we had a lot of good submissions come in late, and had to turn most of them down for lack of space. You can read more information about submissions here, then enter your proposal in the form at http://2007.xmlconference.org/user/proposal/new/4.
Note: There is no late-breaking proposal deadline for 2007. This is the only call for participation.
Our audiences are interested in all structural markup languages, not just XML. Proposals for talks on JSON, SGML, etc. are very welcome.
We have four tracks: Documents and Publishing, XML on the Web, Enterprise XML, and XML training. It’s OK if your paper fits in more than one track — just pick the best one (we’ll move it if necessary).
In addition to regular speaking slots, we have lightning rounds available for standards and spec groups on Tuesday evening. These are open to the public free of charge, and are a great opportunity to learn about a lot of XML-related standards and specs in a hurry.
Instead of a tutorial day with an extra registration charge, we’re offering a training track on Wednesday afternoon that’s open to all registrants, with a mixture of short and long sessions; standards, tech, and product training; etc.
Boston in December is not usually very cold, but the Back Bay, where our conference is held, is nothing if not cool.
Update: Nope, my solution won’t work. As Christian Matthies points out in the comments, it is possible to spoof the HTTP Host header as well (his link in the comment is broken because of an extra comma, but this one works). As a kludge, browsers could be modified to prevent Host header spoofing, but (a) it would take a long time to deploy to the world at large, and (b) it would be only a bandaid for a much bigger problem.
Summary: While there’s no way to protect browsers against the DNS rebinding attack, you can protect web sites and web services by forcing them to check the HTTP
Hostheader with every request. This is easy to do for RESTful services going through a regular web server like Apache — you get it by default with virtual hosts — but might be trickier for WS-* services.
If you or your company is using HTTP-based web services (either WS-* or REST), you might be in trouble — a new exploit allows a web site from outside your firewall to use a web browser as a proxy to read any web site or service inside your firewall.
Artur Bergman at O’Reilly has a posting on the DNS rebinding (aka anti-DNS-pinning) attack that works against all major browsers, including all versions of Firefox and MSIE. There’s no obvious general fix for this, though there’s a Firefox extension that helps a tiny bit.
In a DNS-rebinding attack, the attacker is able to force your browser to read data from any IP address that your browser has access to, even if you’re behind a router/firewall, by changing the IP address associated with a domain name you’ve connected to. That means that given an IP address, an outside attacker can read your local website (at 127.0.0.1), anything behind your corporate firewall (such as an Intranet accounting page or a web service), or — I think (haven’t tested yet) — a website that you’re logged into using a cookie (HTTP authentication will force a popup, since the browser will see a different domain name, even if you’re logged into the site in another tab/window). If you run a local web server on your computer (say, at 127.0.0.1), you can go to http://www.jumperz.net/index.php?i=2&a=1&b=7, type in the local address, and see jumperz.net use the exploit display the source of your home page.
There’s no way to protect the browser yet, but you can protect your HTTP-based sites and services from this attack very easily — in fact, many sites on the web are already unknowingly protected, though I don’t know if most enterprise web services are.
The trick is in the HTTP Host header. While the DNS rebinding attack can associate a new IP address with a hostname, it cannot change the hostname itself, so the browser will still send the original hostname to the new host. Nearly all shared-hosting servers — and many servers at dedicated hosts as well — will check the Host header to decide what pages to serve out. As long as the site does something harmless when it gets an unrecognized hostname (such as returning a “501 Not implemented” HTTP status code), the site will be safe the attack. In Apache, for example, you use the ServerName directive for each virtual host, and just make sure that there’s a default virtual host that returns an error or at least does nothing harmful.
For Web Services, the same thing applies. It’s often tempting to use IP addresses instead of hostnames for web services (including RESTful services), especially during development, but doing so opens you right up to a DNS-rebinding attack, which could be very harmful if you’re using real data for development and testing. To protect your HTTP-based services from this attack, you need to make sure that every web service is accessed via a hostname rather than a raw IP address, and that every service checks its hostname. For RESTful services, this is trivially easy (since you’re probably going through Apache or something similar anyway, just as with a web site); for WS-* services, I don’t know the implementations well enough to be sure, but it should be possible to force them to check the Host header somehow.
Even if you’re not building web services, managing an enterprise intranet, or running a public web site, don’t forget to protect the web server on your local computer, if you have one.