2

Microsoft has the following to say about configuring asp.net core with http.sys:

Top-level wildcard bindings (http://*:80/ and http://+:80) should not be used. Top-level wildcard bindings create app security vulnerabilities. This applies to both strong and weak wildcards. Use explicit host names or IP addresses rather than wildcards. Subdomain wildcard binding (for example, *.mysub.com) isn't a security risk if you control the entire parent domain (as opposed to *.com, which is vulnerable). For more information, see RFC 7230: Section 5.4: Host.

HTTP.sys web server implementation in ASP.NET Core.

I've read the referenced section of the RFC but the only thing I see is that a client could be tricked if a proxy server in between was compromised.

Voo
  • 651
  • 5
  • 14
  • 4
    It'd be nice if the downvoter explained what exactly is wrong with the question. – Voo Mar 05 '19 at 07:57

2 Answers2

5

It's unsafe because of DNS rebinding attacks, a technique which allows an attacker to bypass the Same-origin policy:

The attacker registers a domain (such as attacker.com) and delegates it to a DNS server that is under the attacker's control. The server is configured to respond with a very short time to live (TTL) record, preventing the DNS response from being cached. When the victim browses to the malicious domain, the attacker's DNS server first responds with the IP address of a server hosting the malicious client-side code. For instance, they could point the victim's browser to a website that contains malicious JavaScript or Flash scripts that are intended to execute on the victim's computer.

The malicious client-side code makes additional accesses to the original domain name (such as attacker.com). These are permitted by the same-origin policy. However, when the victim's browser runs the script it makes a new DNS request for the domain, and the attacker replies with a new IP address. For instance, they could reply with an internal IP address or the IP address of a target somewhere else on the Internet.

While the browser won't send any cookie to your webserver (unless the victim logs in), it will still execute any JavaScript code controlled by the attacker, and will be able to load pages / submit forms, like any XSS / CSRF vulnerability.

Your webserver should only reply to requests intended for domains you control.

Community
  • 1
Benoit Esnard
  • 13,942
  • 7
  • 65
  • 65
  • So the attack here is that a malicious site could cause a (presumably trusted) client to call our web server with parameters under its control? I guess this enables the attacker to gain confidential information our server has that the client is allowed to query. Quite interesting. But I think using a strong wild card should avoid this problem if I read the [documentation](https://docs.microsoft.com/en-gb/windows/desktop/Http/urlprefix-strings) correctly, since it will only register all the actual host names of the server. – Voo Mar 06 '19 at 11:02
  • So if my code always checks the Host header first and 404s any unknown host value, I should be okay? – billpg Apr 12 '22 at 17:01
  • @billpg: Yes. :) – Benoit Esnard Apr 12 '22 at 19:54
0

I would say Top-level Domains (TLD) should not use wildcards bindings. Let's say instead of getting a 404 error when you pass-in an invalid/not existing domain you get redirected to an actual, but most importantly unanticipated domain resolution.

All responses are positives, whatever the query is, if your domain uses TLD it never returns a "name error" like response. The problem here is that every application (not user) that rely on DNS response types (positive AND negative) will have unpredictable behaviour.

The Internet Architecture Board (IAB) acknowledged that the wildcard mechanism had been a part of the DNS protocol since the specifications were originally written. However, the mechanism was also understood to be tricky, especially when more than one protocol is invoked:

An authoritative name server returns one of three responses to a query: “success,” “no data” (which means that the name exists but the does not have information about it) and “no such name”. When wildcards are present, the “no such name” response cannot occur and server provides the same response to queries that otherwise might have been either “success” or “no data.” Hence, in the instance of Site Finder and other similar services, mistakes in typing are processed, rather than rejected, and the user redirected to a page that provides information. But this may be, in a sense, a false positive since the system appears to be providing a valid response when in fact it is masking an error, and an error is a legitimate form of information. Applications that rely on the “no such name” response fail since the “no such name” response no longer occurs.

Think about Email servers, SSH and FTP for instance who will be attempting to connect to the IP address in the response.

This link summarizes it pretty well and you can check Site Finder Review and Redirection in the COM and NET Domains - ICANN for more details.

In addition to this, TDL opens to DNS "brute forcing / reconnaissance" unlike what might be believed.

Community
  • 1
Soufiane Tahiri
  • 2,667
  • 12
  • 27
  • "All responses are positives, whatever the query is, if your domain uses TLD it never returns a "name error" like response". How would that happen? The http.sys binding doesn't have anything to do with DNS - just because I tell http.sys to listen on "foo:80", if my server is registered as "bar" in the DNS it won't suddenly get requests for foo, because the traffic is never directed that way anyhow. – Voo Mar 06 '19 at 10:48