The service should check that the `Host` header on every request specifies `localhost`, `127.0.0.1`, or whatever other name is normally used to access it. If the `Host` header specifies a possibly-attacker-controlled name, the service should reject the request.

Explanation:

The problem is that the service is relying on same-origin policy to prevent a web site running in a local browser from making requests to it -- but it does not actually check what origin requests are addressed to. A random web site running in a browser normally cannot make requests to a hostname other than its own. Or, more precisely, it can make requests, but it can't read the responses. The Blizzard updater therefore forces the client to make an initial request whose response contains a secret token, and then subsequent requests contain that token, proving that the client was able to read the response and is therefore not a web site running in a browser.

However, it's perfectly possible to define an evil hostname whose DNS records assign it the IP address 127.0.0.1. Thus requests to this evil hostname would end up reaching the local Blizzard updater service. Unfortunately, the service will happily respond to these requests because it does not pay attention to what hostname the client was requesting.

(To actually exploit this, it's necessary to load an evil web site from the evil host name, which then performs the attack. This means that the evil hostname can't only map to 127.0.0.1, but must also map to the attack server. But a hostname can indeed have multiple DNS records, and the browser will arbitrarily switch between them, allowing an attack to proceed.)