Comparison between POST and GET (httpwebrequest in C#) - in terms of "visibility"

I would like to implement an online activation feature (something like activating using a cd key), and I would like to do so via http.

I would like to send the key together with an internal password to the server each time an activation request is sent.

The password's use is that, since the http service is exposed publicly, I would like it to be used only by my application, not any unknown third party (like brute-force trying different keys).

As I know that in a web browser, 开发者_运维知识库end users can see the GET form values in the address bar, but for POST method it won't have this issue.

What I want to ask is:

Since, obviously, I don't want this internal password to be known to others, when submitting the cd key and the password via the C# class httpwebrequest, is there any difference between using the GET and POST method, in terms of "visibility"?

It makes sense that I should use POST in the rationale that the form values are visible in the web browser address when using GET, but since now I'm using httpwebrequest, there is no web browser "address bar" to be seen, so is it actually no difference at all?

Or, is it that there is when there is like a hacker that intercepts the web request of my application?

Thanks a lot for your help!

No. Both GET and POST are HTTP verbs. Anyone can observe your app using a tool like Fiddler (both GETs and POSTs).

You could try using HTTPS, but there exist "interceptors" for this as well (using function call hooking, not a man-in-the-middle attack).

You may want to consider using a challenge/response kind of communication, where the server sends a challenge to your app and your app has to respond appropriately. Usually asymmetric encryption is used as part of that handshake.

There isn't a perfect solution; any method of copy protection can be broken with a moderate investment of time and resources. You just have to decide where to draw the line.

From HTTP perspective both get and post requests can be intercepted and modified. Use fiddler to check what I mean. Fiddler can also be used to create a get request and submit a form to you site.

There are number of possible ways to deal with this 1) use SSL 2) on initial request, your web service can return a token, which must be used while sending the data. And you can verify and validate the token on next request, which deals with actual activation.

However, without SSL, it is still possible for the user of the application to trace the internal password being set over HTTP. What you may do is - use the token sent in 1st request to encrypt the password. So, every time the password will be different depending on your validation token.

Hope it makes sense.

Both GET and POST data will be in plain text unless you use HTTPS. It's trivial for anyone on the same subnet (or on an intervening network) to snoop on the data.

In short, don't send sensitive data via HTTP.