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.
Related
This seems like a duplicate question - but after hours of search, it seems there is no clear question-answer which summarize the issues i'm raising here.
We have a web application (built using asp.net MVC4) which stores customers sensitive customer information.
We've decided to migrate our entire application to https.
My question is, except for the IIS and certificates technical issues, which we've already know how to deal with, what should be changed on code level?
What will happen for instance for:
Included external scripts containing http, such as: http://code.jquery.com/jquery-1.7.1.min.js - will it work automatically without any problem and popup messages or blocking on the client browsers?
Internal links, which we've forgotten to change, which redirect to our site using http?
Images/Sources which have http in their URL.
Should we change all references from http to relative, or just specifying // without the http/https protocol ? (as seen on other posts on this subject)
Should we do nothing, will it happen automatically?
Is there a way to do something in IIS or Global.asax etc, in order to automatically take care of all http leftovers?
What else should we take in account when migrating to https?
Thanks in advance.
For all internal static resources hopefully you have used #Url.Content helper and for all internal dynamic resources you have used #Html.ActionLink, #Html.BeginForm, ... helpers to generate the links. This way you don't need to worry about anything.
For all external resources you could use // syntax in the link which will respect the protocol.
Since you are switching to HTTPS you might consider marking all your cookies (if any) with the secure flag to ensure that they are transmitted only over a secure channel.
I have coded a C# MVC5 Internet application and I have a Web API 2 web service that returns JSON data. I am retrieving this JSON data in an android application.
How can I add a feature to the web service such that only my android application can retrieve the JSON data? I am wanting to do this so that other web users cannot hammer the url and the web service will not send my data to unwanted applications and/or users.
Is this possible? If so, how should I do this?
Thanks in advance.
You have various ways to achieve this in fact.
For example, you can store a key in your android application and use send this key together with the request to your WebAPI. Your webAPI will than check if they key is valid and if it is, it will return the JSon.
However, there's no way to ensure that nobody else can request and get your data. For example by reverse engineering your android application and extracting the key, or by monitoring the network traffic and find the key in there.
You need to understand that there isn't anthing that guarantuees you 100% security.
See it as the following:
You have an open door right now, you can close it little by little, but closing and locking down is not possible. There will always be gap. A house also can't by made burglar proof, but you can make it very hard for a buglar to enter.
Go to this link Web Api. I have used the individual authentication for my web api. When you will register the user the response you will get is access token and use that access token as Authentication header in your ajax call if you are using Jquery ajax to call your Web Api. Refer this The OAuth 2.0 Authorization Framework. Hope this help you.
Are you looking for something like this?
http://httpd.apache.org/docs/2.2/howto/access.html
If you have other web server, there should be appropriate means to support such.
I'm trying to make a login script in PHP, however a user will signup/login via a C# program.
For obvious reasons I don't want to use GET, but I don't want to make forms and use POST either.
How should I (securely) send data over?
This is only a proof of concept so there isn't any SSL on my website/etc, so there's no extra loops to jump through.
Just so nobody's confused:
Web-based login will be made in PHP, and data will be sent to the website via a program made in C#
You have to use GET or POST to submit your form data back to the PHP page. There is no way around that.
Once your PHP code has it on the backend you can do whatever you want to get it to the C# program.
Using a POST would eliminate items being added to the query string like GET does and of course doing it over HTTPS would make it more secure.
The only way to be secure is to use https:. You can look at client-side encryption, but that involves private/public keys - https will be easier.
Client side is HTML/JCSS/Javascript. If you want a user to enter ID annd password then you will have forms, and GET or POST is what you will use. Even if you wrap it up in AJAX, it will still be the same.
Go and think this through, and come back with a proper question. Telepathy isn't sufficiently reliable for your needs. Yet.
I'm not quite sure I understand correctly but what I understood was you want to send the login via a C# program. In that case check this question: HTTP request with post.
If however you want to send the data via the webpage, without having a form. You'd need to make the POST request via javascript.
Any of both methods require POST requests, even though you don't use forms.
I'm building a complex, public web service in WCF that send email to a specific address, similar to a contact form but with some features.
With jQuery I get the data from the textbox and with Ajax and json I send to the web service the strings to proceed at the send.
Now, is there a good way to make it secure?
I mean.. the service is public so someone can have access to it and starting to spam on this address. Can I restrict the users to use the web service only from the correct web site?
Thanks.
IF the WCF service is hosted in the IIS you can allow calls only from a specific IP address, look at the directory security settings under IIS.
By far the simplest way is to have your web service require some type of access key in order to run the operation.
Something simple like a base64 encoded GUID would work. It doesn't even have to change. Just add a parameter called "AccessKey" or something similar. Have your app pass that and let the service validate that it is good.
Another idea is to have the web service check the http headers to see if it came from the page you authorized to use it.
Neither of those are perfect. The first one means that your "key" will be inside the html you send to the client. The second one can be spoofed.
Personally, I'd probably not bother at this level and just log what the service is doing. If the traffic counts to the service start to exceed what you think it ought to be, then I'd investigate ways to mitigate it. Most likely, given that it's a service you won't see any issues.
I am trying to implement ajax back/forward button support and therefore writing variables after a # in my url. I would also like the user to be able to copy the url and then link back to it. Does anyone know how can I parse the url and grab my "querystrings" even though they are behind a #?
The value after the hash is not transmitted to the server. There's another SO question about that somewhere, but I'm having trouble finding it. Likewise it's taken me a while to find a decent reference to cite, but this Wikipedia article has some confirmation:
The fragment identifier functions
differently than the rest of the URI:
namely, its processing is exclusively
client-side with no participation from
the server. When an agent (such as a
Web browser) requests a resource from
a Web server, the agent sends the URI
to the server, but does not send the
fragment.
I assume you want to respond to it on the server side rather than the browser side? (Given that you're asking about doing it in C#...)
http://msdn.microsoft.com/en-us/library/system.uri.fragment.aspx