1

My friend and I are working on a program. This program is going to submit GET data to our webpage. However, we don't want users accessing the webpage any other way than the program. We can prevent users from sharing the program using HWID authentication, but nothing prevents them from using a packet scanner to get the URL of the webpage. We thought about user-agent authentication, which we will implement, but user-agents can easily be spoofed.

So my question is, how can we prevent users from accessing the webpage directly, instead of through the program?

Even if you don't have an answer that will completely work, anything that will help deter them would be nice.

Currently we will be implementing:

HWID Authentication to use the program User-Agent Authentication to access the web page Instant IP Blacklisting to anyone accessing the webpage without the proper User-Agent

Rob
  • 7,980
  • 30
  • 75
  • 115
  • I don't know what kind of an application you are building, but I would think long and hard whether I really *need* to prevent people from accessing my service through other clients, and if I do, whether there's not something wrong with my business model. Whatever you do, implementing this in a secure way is going to take a lot of time and be expensive. Is it really necessary? – Pekka Apr 18 '10 at 09:15
  • @Pekka: Well I don't want my product getting leaked and made publicly available. If I used a simple webpage and made no authentication methods, people wouldn't have to purchase the product. If I added a username and password to it, the username and passwords would get shared. – Rob Apr 18 '10 at 09:17
  • 2
    I don't know your target market but I think giving out logins is the best you can do. If you see suspicious activity (e.g. the same account logging in from three different countries within the same hour) you have all the means to shut that account down. Who cares what client they use? And if it's any kind of business software, most of your customers will be too scared to give out their personal login credentials. – Pekka Apr 18 '10 at 09:28
  • 2
    You should focus on making good software, not on preventing people from stealing your application. Game editors have been trying to lock users for years, and their protection are still broken within a few days. If your application is useful people will buy it and some will steal it. – Guillaume Apr 18 '10 at 12:04

4 Answers4

4

Do not rely on user agent or any kind of browser fingerprint, HTTP headers are easily forged/spoofed.

You could add some secret token (eg. password/login) to the request and send it through SSL to prevent eavesdropping.

Or better, use an SSL client certificate.

Edit Are you going to distribute the VB program? If so, as bobince mentioned, there's no way you can prevent a determined hacker to forge requests. You can raise the bar but it will be security through obscurity. Even with client certs, the hacker will be able to extract the cert from your program and send modified requests.

As long as you accept requests from the client, these requests can be forged. Deal with it.

Guillaume
  • 14,306
  • 3
  • 43
  • 40
  • Yeah we thought about using SSL except that I don't have a clue about it, and don't know how to make the page accessible via SSL – Rob Apr 18 '10 at 09:11
  • Yeah I suppose. Or I could use google, where everything's free. – Rob Apr 18 '10 at 09:13
  • +1 Encrypting the communication is the only half-way safe way to do this that I can think of. – Pekka Apr 18 '10 at 09:14
  • 2
    In the end of course you can never win. Once you give a copy of the software to someone else, they have any information in it (like a client cert) that would be necessary to connect to the server. – bobince Apr 18 '10 at 09:17
  • @Rob: That depends on how much your time is worth. – Heinzi Apr 18 '10 at 12:10
2

One option is you can set an encrypted token in the request header.

The Token can be used only for single time. If the same token is sent again the server will reject it, means u have to maintain the copy of utilized tokens on the server side.

JChap
  • 1,421
  • 9
  • 23
  • Maintaining copies are easy, I'll simply use a MySQL database. I need to do that anyway for the IP Blacklist – Rob Apr 18 '10 at 09:10
  • Is this not a better way than SSL ?? Cause the encryption logic is inside the application. We cant help if ppl decompile the code !\ Also this is a cheap solution.. rather than investing on the SSL Certificates ! – JChap Apr 18 '10 at 09:20
  • Good point. The one-time algorithm might get reverse engineered one day but so could the encryption key(s) used. – Pekka Apr 18 '10 at 10:32
0

one option is to use and verify a custom header which a web browser does not send, i did a similar thing for a program of my own. Do that ontop of the other verifications you are doing. On serverside, have your server script verify the custom header and simply redirect if the header is wrong

Jim
  • 601
  • 6
  • 17
  • Sounds good, can you please elaborate on how I could make the webpage check for the header? Maybe also elaborate on how to send the custom header. I do the PHP, my buddy does the VB.Net – Rob Apr 18 '10 at 09:08
  • Security through obscurity... What happens if someone intercepts a request and sees that custom header? – Guillaume Apr 18 '10 at 09:16
  • in php, in the page your program is supposed to read, use public array HttpRequest::getHeaders () to get the headers and check/varifiy name and the value, in vb. net with the request object you add a header, you do not return any custom header back to the program and you simply redirect if the headercheck fails – Jim Apr 18 '10 at 09:20
  • the point is that those headers can be duplicated easily by a malicious client. They don't really add security. – Pekka Apr 18 '10 at 09:27
0

  • Try encrypting all ur webpages using the a long key(512bits or more) use the HWID as a salt.

    This way only ur program can decode it and render it as a webpage.

    en.wikipedia.org/wiki/Salt_%28cryptography%29

  • C# & VB.net here:

    obviex.com/samples/hash.aspx

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
TheCodeArtist
  • 21,479
  • 4
  • 69
  • 130