If I was to send a URL to a DNS server, lets say: "dev.example.com/?username=daniel",
what is exactly sent to the DNS server? The whole URL (including any passed parameters) or is it just website section "dev.example.com"? I want to know so that I know what parameters I should be hiding in a URL.
The reason I am asking is because I just don't want confidential information sent to DNS servers. I am using https for all URLs but when someone asks to go to a URL, I want all parameter information from the URLs to be hidden from all DNS servers. I just am not sure what is sent to a DNS server to establish an SSL connection. Since I have a site that needs just about every parameter encrypted I am concerned about how to hide this information if DNS reads it.
dev.example.com may be resolved (if it is not already in the local cache) by sending it to your DNS server (which will almost certainly refer to another DNS Server).
Only the "dev.example.com" is sent, the rest will be passed only to the resolved IP number as an HTTP request.
So, you do not need to hide any parameters, except of course that these parameters could well end up on another website if a user visits it from your page (as a referer). If these parameters are really sensitive encode them or (ab)use POST,
The Domain Name System (DNS) resolves hostnames to IP addresses, so only the value of the hostname is sent.
DNS is agnostic of protocol. The value sent is just the hostname, so in this case dev.example.com.
I'm also not sure what this has to do with "parameter hiding" but if you could expand on that we might be able to provide more helpful advice.
Edit (based on your update): Ah. Well then you shoud be good to go, as only the domain name itself is sent.
If the DNS server happens to be a web server which root web application happens to answer to the "username" query, then you might get something back. Other than that, DNS is another kind of animal.
Related
I currently have the problem that I don't know whether a firewall has access to the query string of a URL, for example:
www.example.com/muster.html?Name=Max+Mustermann&Ort=Musterstadt&PLZ=1234
If it checks the URL, does it only see www.examle.com or the rest of the URL as well?
The reason behind my question is that I don't want the metadata that I send in the URL as a query string to be blocked by the firewall.
Depends on the layer your firewall operates.
Wiki https://en.wikipedia.org/wiki/Firewall_(computing)#Network_layer_or_packet_filters:
Network layer firewalls, also called packet filters, operate at a relatively low level of the TCP/IP protocol stack.
They basically check IP address and port.
Many modern products also work at application layer and with technologies like content filters - they can see the entire request - including the request parameters (but they would also see your post body).
By using HTTPS your query parameters are encrypted (check Is an HTTPS query string secure?). In this case the firewall can't access these parameters. In practice there are e.g. corporate proxy scenarios where even HTTPS requests are intercepted, checked and re-signed by a trusted certificate. In these scenarios content filters can even see encrypted query parameters/ request information.
Hope that helps!
A Firewall is here to protect computer, he can check url and of course the data passed through URL.
I am trying to understand how to bypass HSTS protection. I've read about tools by LeonardoNve ( https://github.com/LeonardoNve/sslstrip2 and https://github.com/LeonardoNve/dns2proxy ). But I quite don't get it.
If the client is requesting for the first time the server, it will work anytime, because sslstrip will simply strip the Strict-Transport-Security: header field. So we're back in the old case with the original sslstrip.
If not ... ? What happens ? The client know it should only interact with the server using HTTPS, so it will automatically try to connect to the server with HTTPS, no ? In that case, MitM is useless ... ><
Looking at the code, I kinda get that sslstrip2 will change the domain name of the ressources needed by the client, so the client will not have to use HSTS since these ressources are not on the same domain (is that true?). The client will send a DNS request that the dns2proxy tool will intercept and sends back the IP address for the real domain name.At the end, the client will just HTTP the ressources it should have done in a HTTPS manner.
Example : From the server response, the client will have to download mail.google.com. The attacker change that to gmail.google.com, so it's not the same (sub) domain. Then client will DNS request for this domain, the dns2proxy will answer with the real IP of mail.google.com. The client will then simply ask this ressource over HTTP.
What I don't get is before that... How the attacker can html-strip while the connection should be HTTPS from the client to server ... ?
A piece is missing ... :s
Thank you
Ok after watching the video, I get a better understanding of the scope of action possible by the dns2proxy tool.
From what I understood :
Most of the users will get on a HTTPS page either by clicking a link, or by redirection. If the user directly fetch the HTTPS version, the attack fails because we are unable to decrypt the traffic without the server certificate.
In the case of a redirection or link with sslstrip+ + dns2proxy enabled with us being in the middle of the connection .. mitm ! ==>
The user goes on google.com
the attacker intercept the traffic from the server to the client and change the link to sign in from "https://account.google.com" to "http://compte.google.com".
The user browser will make a DNS request to "compte.google.com".
the attacker intercept the request, make a real DNS request to the real name "account.google.com" and sends back the response "fake domain name + real IP" back to the user.
When the browser receives the DNS answer, it will search if this domain should be accessed by HTTPS. By checking a Preloaded HSTS list of domains, or by seeing the domain already visited that are in the cache or for the session, dunno. Since the domain is not real, the browser will simply make a HTTP connection the REAL address ip.
==> HTTP traffic at the end ;)
So the real limitations still is that the need for indirect HTTPS links for this to work. Sometime browser directly "re-type" the url entered to an HTTPS link.
Cheers !
Scenario: I want a staging environment at a customer's site. The customer owns www.example.com. I want to map the site to staging.example.com reachable from the outside, but I haven't got time to wait for the bureaucracy surrounding either the purchase of the new subdomain or opening of secondary HTTP ports.
Assumption: If I spoof the HTTP Header param Host to be staging.example.com on the client side, but actually make the request to the IP of www.example.com, IIS will redirect the request to the configured site for staging.example.com. Am I right?
So is there any client tool that can help me with that? I'm fairly famailiar with Fiddler, but it seem to override my rewrites of the host parameter. Also I would need to configure it to do it for every request, not just one, to make it trivial to test.
Are there simpler solutions to this problem?
I'm not entirely sure what you're asking.
Inside Fiddler, by clicking Tools > HOSTS and you can send all traffic targeting one site, e.g. dev.example.com to the IP of your choice. The target site (namely dev.example.com) doesn't need to exist at all in this case. Your client (e.g. the browser) has no idea that Fiddler is retargeting the traffic, it just thinks that it is talking to dev.example.com.
If you have the Fiddler book, check out the Retargeting Traffic section for many other ways to retarget traffic.
In general on any non-HTTP server. Would there be a way to detect what domain was used to reach the IP?
I know HTTP servers get the domain passed within the request header, but would this be possible with any other server that does not require this information to be received from the client?
I'm especially looking for a way to do this with the minecraft server (Bukkit) so my preferred language (if needed for you to answer) would be Java. But I'd like to not have the theories about this language specific.
In general, no, which is why the HTTP protocol includes it in the headers.
In order to reach your server, first a DNS lookup is performed to resolve your IP, which is then followed by the connection itself. These two steps are separate, and hard to link together.
Logging what domain was last requested by a client is tricky, too, as DNS information is often cached, so the DNS request may not even reach your DNS server before being answered.
If it isn't cached, it also often isn't directly looked up by the end client, but rather by a caching DNS server operated, for instance, by the ISP.
No. The only way to get the DNS name used to connect to a server is to have the client provide it.
No, if there are no means for this in the protocol itself like the Host header in HTTP you cannot find out which hostname was used on the client to resolve your IP address.
I have a server/client architecture where the client hits the ASP.NET server's service at a certain host name, IP address, and port. Without thinking, I logged on to the server and set up permanent HTTP301 redirection through IIS from that service to another URL that the machine handles via IIS (same IP and port), mistakenly thinking it was another site that is hosted there. When the client hit the server at the old host name, it cached the permanent redirect. Now, even though I have removed the redirection, the client no longer uses the old address. How can I clear the client's cache so that it no longer stores the redirect?
I have read about how permanent HTTP301 can be, but in this case, it should be possible to reset a single client's knowledge of the incorrectly-learned host name. Any ideas?
The HTTP status code 301 is unambiguously defined in RFC 2616 as
any future references to this
resource SHOULD use one of the
returned URIs
which means you have to go ask all your clients to revalidate the resource. If you have a system where you can push updates to your clients, perhaps you can push an update to use the same URI again, but force a revalidation.
Nothing you do on the server side will help - in fact, by removing the permanent redirect in IIS you have already taken all measures you should.