avoid localhost // verify url

Started by
12 comments, last by tonemgub 9 years, 6 months ago

Hi

I get a file via curl ok. Now I want to avoid users to change hosts file, so that they could place/access a copy of that file locally.

Any ideas in c++? I've tried with htaccess on the server but no luck as curl uses apparently http to get the file. So I guess I need to check

if localhost is running and if so disable loading of my file? Or better check for the correct url?

Many thanks

Advertisement
The obvious solution would be to only allow https connections and the client validates the expected certificate is used. Obviously the client could still be manipulated to ignore the certificate check but it's a bit more involved than redirecting a DNS query.

If the URL starts with "htt?ps:/?/" then cURL will use HTTPS to connect.

EDIT: forum filters "htt?ps:/?/" o_o (added zero-width spaces to work around it)

Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

Thanks. I'm currently investigating to change:

curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L))

to 0L. What's the L anyway?

http://curl.haxx.se/libcurl/c/CURLOPT_FOLLOWLOCATION.html

Now that would be as easy as it gets...wub.png

I need a localhost to test?

The L just means it's a long constant instead of an integer constant.

That said, I do not think you can solve the problem with cURL. cURL needs to resolve a DNS. It has to ask the operating system to do that, and Windows will lie as much as the user wants to with just a hosts entry.

Sik_the_hedgehog: I don't think just any https will do. You need to validate (with the public key contained in your client) that the server uses the exact matching private key.

Yes, but the original post seemed to imply that https could be used to do such a validation =P (especially if you consider that you can use your own certificates) Although of course you could just swap the certificate the program checks against and you're back to zero. This kind of stuff is exactly why DRM doesn't work in practice.

Also disabling following is a bad idea, what that would do is to not retry when getting a redirect status code from the server (and the fact it's disabled by default is annoying). That would not help at all if you can just manipulate the hosts file, because the original server would never be seen in the first place.

Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

You could use gethostbyname or getaddrinfo to detect if the DNS name you're trying to connect to resolves to the same IP/address as localhost (or any non-routable IP/addresses)...

Of course, anyone who could circumvent your public HTTPS certificate could probably also disable the IP/address checks even faster.

The best you can do is hide the public certificate in your executable (the code section if possible), and maybe even encrypt it with a password stored somewhere else.

I'll try now with user agent and htaccess:

http://curl.haxx.se/libcurl/c/CURLOPT_USERAGENT.html

"Pass a pointer to a zero terminated string as parameter." Hmm don't understand, how should for example "MyUserAgent" look below?

&& CURLE_OK == (code = curl_easy_setopt(curl, CURLOPT_USERAGENT, MyUserAgent))

Thanks again

Um no, you keep looking for things that let the server verify the client when you want the client to verify the server instead (and even then there's a chance that it'd just get worked around by messing with the client itself).

Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.


Now I want to avoid users to change hosts file, so that they could place/access a copy of that file locally.
Nobody seems to be asking the critical question:

WHY?

What exactly are you trying to prevent?

Anyone with even a tiny amount of experience (or a bit of Google) and a collection of free tools can redirect your traffic, provide fake or MITM SSL certs, spoof DNS information, or freeze and modify your program.

If you are trying to prevent various client-side cheats, the most viable solution is to never send the information to the clients in the first place.

If you are trying to prevent interception, that is not possible; corporate environments do it all the time and substitute SSL/TLS certs with a corporate edition as it passes through their proxies. The protocol is designed to permit that type of MITM attack because our corporate overlords demand it. :-)

What specifically are you trying to prevent, and why?

This topic is closed to new replies.

Advertisement