• Advertisement
Sign in to follow this  

avoid localhost // verify url

This topic is 1228 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

 

Share this post


Link to post
Share on other sites
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. Edited by BitMaster

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Edited by tonemgub

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

It sounds like you're trying to prevent tampering with the file. If that's the case then you should verify the data in the file, not where it came from. To me, that implies that you should be signing the file and checking its signature when you load it. If the file is signed with your certificate then it does't matter whether the bytes were loaded from the Internet or localhost because you know that nobody has tampered with the data in transit.

Share this post


Link to post
Share on other sites

To me, that implies that you should be signing the file and checking its signature when you load it.

Doesn't work since this is client side.  Debuggers and other advanced diagnostic tools (sometimes called 'hacking tools') can easily freeze your program, detect how the file is touched and poked and decoded, then modify the executable to accept an unencrypted file.

 

Encryption ensures safe delivery of the package between two trusted endpoints through a hostile environment.  If the end point is not trusted, such as a player's client machine, encryption doesn't help.

 

As a parallel, a secure connection between you and your bank works because you trust your side and you trust the bank's side. The dangerous zone is in the middle. A one-time session key prevents bad guys from intercepting and immediately using the content, and the short term use-and-discard nature of session keys makes them non-reusable and (usually) too expensive to justify cracking.  However, the bad guys can also get a client, reverse engineer the protocols, send invalid but correctly encrypted messages, and see everything that is internally happening inside the client.  The bad guys can build their own trusted communications links. They'll be assured by the encryption that nobody is doing anything untoward with their communication stream (just like your communication stream is safe from them), but they can modify content of their own stream and modify their own copy of the client, so your server better be prepared to limit the data sent and to validate every transaction.

 

If the client has access to the data and protocols in any form then an attacker also has access to the data and the protocols. No amount of  encryption will protect the data within the stream from an attacker who has a valid client.

Edited by frob

Share this post


Link to post
Share on other sites

If you can't trust the end-point then *everything* goes out the window. I don't think there's any way to be secure under those conditions, so I don't spend much time worrying about it. But that doesn't mean you shouldn't do everything you can to protect the data between the server and the customer's machine.

 

For example, my day job is doing web application development and browsers "helpfully" include a full suite of debugging tools built right in. Couple that with the fact that all application logic is delivered in source code form and you have an environment that is *very* friendly to hackers. There's not much we can do about it except run the code through an obfuscator and monitor the situation as best we can. So far we haven't seen any serious hack attempts, but then we're not a AAA game title. 

 

Security is always a balancing act because you often have to live with the fact that your security isn't perfect. The trick is to find a balance between the risk (what damage an attacker could do) and the threat (how likely you are to be attacked). If you're working on the next Dota with millions of dollars in prize money riding on the results of your matches then you need to take a very different approach to prevent cheating compared to a small personal project that's only ever going to be distributed to your friends.

Share this post


Link to post
Share on other sites

I'd concentrate more on securing the content on the server, rather than preventing the client from connecting to hacked servers.

 

Any Tom, Dick or Harry can make an offline copy of a website, using tools like HTTrack, so if your web server does nothing to hide the game content from those tools, then you're just making the hacker's job easier. Your mention of curl is actually a dead-give-away that a tool like that (perhaps coupled with a monitoring tool like Wiresark to discover all of the URLs that must be downloaded) is sufficient to download all of your game content off the server - a hacker wouldn't even have to look at modifying your game client.

 

A few techniques come to mind to avoid this:

 - A single game client usually doesn't need all of the game content downloaded at once, so you know that whoever tries to do that probably uses a hacked version of the client, and you can interrupt them (or start sending them random data) before they get to replicate the whole game content.

 - To protect against URL monitoring, you could randomize&encrypt the URLs.

Edited by tonemgub

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement