I am planning to work on an Asp.Net/C# RESTful Web Api 2 project. One of REST actions is receiving "username" and "password" with GET method. The value of "password" passed in query string is needed to be protected from REST client programmers/consumers. The "password" passed in query string (please see a sample REST call below) is sensitive data entered from any non-technical user who is not REST client programmer but who is using REST client programmers' software applications.
REST client programmers are RESTful web service consumers who write software applications in any device platform and any programming language (Java, C++, or Object-C, C, PHP, etc.).
I am supposed to use HTTPS protocol (not HTTP) to host my Asp.Net Rest Web Api services. And one sample GET call to get "password" from client/consuming programmers looks like:
https://www.mycompanyhost.com/account?username=abc&password=some_password
My questions:
1/ Is using https protocol secured enough for my Web Api services side receiving sensitive data and for the consumer/client side sending sensitive data?
2/ if https protocol is not secured enough, then how do I as web service provider and service consumers/programmers to protect sensitive data like "password" as I mentioned?
For me, the follows sound complex:
If Rest web service consumers use some encrypting method/algorithm, then on my Rest service provider side, how can I understand the same encrypting method/algorithm to decrypt "password"?
On my side as provider I am using C#, but web service consumers can use any programming language and device as mentioned above, how do we (both sides) understand each other with encrypting approach?
To achieve secure communication has a long history as you might guess (maybe since the day of digital communication born?). In your question, please consider https is the must-do yet minimum security standard that you can rely on.
Moreover, there are two things that you can consider.
I don't know why you have to GET password from server. Almost all web service treat password as hashed manner (written with several mathematically encryption). So it can compare only, cannot read words back.
It is only your decision which crypto algorithm you choose. There are many encryption/decryption library provider in .NET. I recommend you to buy-and-apply one of them.
Finally, I strongly recommend you a book to read "Pro ASP.NET Web Api Security" (amazon link). It will give you enough knowledge to make decision in your technical domain.
Related
Could somebody help me find an example of getting data from SalesForce using its api with c#? E.g. getting a Contact information by its email address?
There are ready-built libraries for .NET integration such as https://github.com/wadewegner/Force.com-Toolkit-for-NET, I'd suggest starting with one of these. (old but official). Another one could be https://github.com/anthonyreilly/NetCoreForce
Old, stable, battle-tested or you want to craft the SOAP / REST messages yourself, read up about security tokens, oauth scopes, error handling, bulk API options? I'd offload at least the login part to existing library but your call :) There are many ways to connect, there's even (paid) SQL server plugin or azure data factory solution...
".NET toolkit" seems to use old SOAP API. It's... simple. You provide username, password and you get total impersonation. The app will be able to do everything the connecting user can do. The other one seems to use client id and secret, this sounds like newer REST-based API implementation (OAuth2 keys). This is slightly better, you get extra security layer of the connected app and for example if "scope" is only set to Chatter - even admin's session connecting via this app can't be abused.
There are slight differences between the APIs and the way they handle certain features (for example downloading a Document/Attachment/File via SOAP API will give you base64-encoded payload while REST API will give you a link to download the binary separately). And of course how much of the API does the library actually implement, how well it's maintained...
But generally I'd say explore the libraries first. At least steal some ideas around login logic. If nothing off-the-shelf works for you - consume the WSDL and hand-craft something in SOAP API. Worst case - craft the XML messages manually, worry about escaping special characters etc.
Get an account and api key and then use the official programming interface:
https://developer.salesforce.com/docs/apis
i'd choose: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_rest_resources.htm
So You have to read and understand this: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/using_resources_working_with_searches_and_queries.htm
:)
I need to push data from applications made in VB.net, Java, C#, C++, Node.js and other modern languages to our server. These applications are running in retail stores and our service is 3-party service. I am planning to offer REST API to push the data but my concern is how do I authenticate a single store.
One of the ways I thought was using the AWS way : AccessKey and Secret Key approach outlined here :
http://docs.aws.amazon.com/AmazonS3/latest/dev/S3_Authentication2.html
Each store can have multiple billing machines/computers --> so what will be a better approach to authenticate because the AWS way requires to paste the Keys from our interface to their local machine setups (At this point I am assuming our services will be directly called from the front end application rather than Back-End Servers.
I am confused how to go about approaching this problem - if the REST API Calls should be made from front-end or back-end services and if its front-end how do I go about authenticating the store.
To first answer
I am confused how to go about approaching this problem - if the REST
API Calls should be made from front-end or back-end services and if
its front-end how do I go about authenticating the store.
Since you say
I need to push data from applications made in VB.net, Java, C#, C++,
Node.js and other modern languages to our server.
To me it sounds like you want server (your customers) -> server (your REST API) communication.
Before getting into security options, you need to think about security-ness and time/resources.
Starting with security, if you're dealing with HIPAA, PII or other sensitive data, then definitely do more research.
Next, time/resources. A SaaS service like AuthRocket or Okta will make life much easier, however, it is a monthly expense. You can roll an open source library into your API, you'll just need to spend the time to develop, test and maintain (and deal with stuff like user registration, lost pws, etc).
And so now, authentication. ID/Token auth like Amazon is the most common way. Every REST request a customer issues will include their ID and token (eg ID=customer-123, Token=laksdjflaksjdf). To handle a customer w/multiple machines, you can issue n tokens, one for each machine. The customer would be responsible for putting the credentials on each machine. Again, this is the most common way to do things.
You can also use OAuth, but this doesn't make as much sense for your use case since its companies and not individuals (usually OAuth is for developer-oriented APIs).
There are also other various token based authentication approaches, but these are usually better suited for client->API requests (websites->APIs).
I have an online application with PHP & MySQL. I need to provide some functionality using a a desktop application built in C#. My task includes follwoing..
Authentication
Database query
Please suggest me a proper way to proceed with this scenario.
Some of my doubts..
should I use webservice in my PHP end?
How to authenticate?
any security issue?
Yes. You will need to build a webservice on the PHP end, that contains a method that will execute your query. You can then add a 'Service Reference' in your C# application to the PHP service.
Regarding authentication: it depends on your scenario. If you are the only user of the webservice you can use basic authentication (over HTTPS) to ensure that your credentials are safe from sniffers.
Problem with security is that you will have to rely on tokens, keys, or something. And because these are stored on the desktop computer that uses the software, someone can steal these secrets (by using a decompiler f.e.). If security is really important, you will need to rely on 3rd party solutions like DigiPass.
Webservice: It is the standard way of working. But it has some overhead (XML and that all) so if you transmit complex structures you might need other options (passing data with your own codification over an HTTP connection, for example). Maybe even a mixed system were simple requests are through plain webservices and more complex ones go through HTTP but without using XML, or passing a structure codified this way inside the webservice. Anyway, try to keep non-standard solutions to a minimum.
Depends of your security requirements. Webservices is HTTP, so the standard web authentication works.
Same as before, you have the basic solution, it depends of what your application does.
I am new to RESTful web services. We are taking the REST route for building our public web services to be consumed by out clients.And i had a few questions.
Are there any kind of limitation with pure REST webs services? and if yes then would a hybrid REST web service take care of those limitations?
I am thinking about using SSL + Hash Message Authentication Code (HMAC) in Authorization header for security along with IP based based filtering. what do you guys think about it?
Are there any good client side tools for testing?
Currently i am using the following
http://code.google.com/p/rest-client/
And what about some kind of client side code generation tool?
The following links are my source of info.
http://msdn.microsoft.com/en-us/library/dd203052.aspx
Link
The first thing to keep in mind is that a REST service should be stateless, which is very different when compared to a SOAP/RPC type of service interface. Using REST methodology requires you to rethink how you want your clients to interact with the service, breaking down the interactions into clear and concise method calls.
REST
+ Lightweight messages, very little overhead (other than the XML itself)
+ Easily readable results, can easily test with a web browser
+ Easy to implement
- Looser interface, loose type checking
SOAP
+ More rigid, with a strict contract definition
+ Plenty of development tools available.
Looking through the WCF MSDN documentation, WCF SOAP support was integrated from the start while REST support is a recently added feature. I myself am having a hard time finding documentation for authentication/security for REST services, as most of the documentation is directed towards SOAP.
Client side generation tools: I haven't come across any for REST services as REST doesn't define a service contract as SOAP does. WADL is an attempt to do that for REST services.
http://en.wikipedia.org/wiki/Web_Application_Description_Language
http://wadl.codeplex.com/
I'm interesting in reading more responses dealing with authentication and security, as I'm looking into that myself.
This is a good starting point of a WCF REST WebService:
REST / SOAP endpoints for a WCF service
(BTW: Stackoverflow has nice REST kind of urls.)
You can test a REST service with just a web browser (Go to the url and get the XML or JSON). Fiddler is also good tool, and FireBug-plugin for FireFox. I usually make a thin service-interface project and a separate (unit-tested) logics-project.
For authentication I would first generate a Guid and a timestamp. Then based on those a hash (.NET supports SHA256 and SHA512). The Guid can be stored to server (database table) to map it some concrete numerical id. Then you can have a rest url like:
/myobject/1?timestamp=20100802201000&hash=4DR7HGJPRE54Y
and just disable the hash & timestamp check in development environment (e.g. with AOP). With timestamp I would check that the stamp is between 15 minutes back and forward in time (=should be enough to prevent attacks).
Will your service be visible to the public/internet and is your client a jQuery or Silverlight -client? Then you still have a problem: You don't want to include a secret key in the client software code.
So you need to generate hash in server and some kind of cookie to store the client session. (This can be done e.g. with a separate login-page/application in a folder with different config-file.) I remember that this book did have something on the topic:
If you want to enable the HttpContext when using WCF, you need to set <serviceHostingEnvironment aspNetCompatibilityEnabled="true"> under <system.serviceModel>.
Then you can check current user identity from HttpContext.Current.User.Identity.Name.
However, if you want to make a pure REST service then you don't use cookies, but a HTTP Basic Authentication coupled with SSL/TLS for each call.
I think that it's easy to make a client with just LINQ2Xml or jQuery so maybe client generation is not needed.
Or you can also have both, a SOAP and a REST interface, and use a service reference to make a client.
One thing to keep in mind is that you can take REST as a philosophy (everything should be reachable by a clean URL, without hidden strings attached) or as a dogma (you have to use PUT and DELETE even if that means a lot of hardship down the line).
The emphasis is on simplification - like using simple data types for params instead of stuctured pileups, nor clobering interface for superfluous reasons (like towing giant page "title" in a url), not using headers which are not well known and de-facto standard.
So, you can design perfectly RESTful interface using just GET and retain usability and testability from web browsers. You can also use any standard authentication methods or several of them for redundancy depending on your actual target audience. If you are making an app to run on a corpnet with standardized credentials and tokens you can continue using that. If you are doing something for very general access you can use combination of GET args and/or cookies - keeps your URL-s clean for 99.99% of users.
You can even serve both JSON and XML (like Google maps for example) and still be RESTfull, but you can't do full scale SOAP (complex input types etc). You can do limited SOAP - simple types for requests, always expressible as GET args, people still get WSDL for documentation.
Hope this paints flexible enough picture - the way of thinking above any strict dogma.
I am going to be creating a web service that will be passing confidential information across the network.
What would be the best way to secure the web service?
how do I know if the application requesting the information is who it says it is, and it's not another application that is using another's user name and password?
Use WCF for your web service! It has tons of security capabilities:
You can
secure your clients via Certificates - only those that have the appropriate certificate will be allowed to get their calls processed
secure your clients by looking them up in your internal Active Directory domain - only those with AD accounts will be allowed to get their requests processed
secure your clients with custom username/passwords which you can look up against anything you want (this is the most flexible, but also the most complicated option, and offer the most potential for failure if you get something wrong)
Plus, with WCF, you also have loads of options to secure the transport between client and service, or encrypt and sign the messages going back and forth.
See the WCF Developer Center as a great starting point for all things WCF.
If you're serious about safely and securely programming WCF services, grab a copy of the Programming WCF Services book by Juval Lowy - it's the bible for WCF.
I've done this once or twice in the past:
Use SSL
Write the webservice to require a token which is retrieved from a method on the webservice.
Have the token returned from a method which requires a login and password.
After a certain number of webservice requests, or at random intervals, change the token required, thus forcing a re-authentication.
If you want to, encrypt the data in the ssl stream, by using an encryption method which both parties understand. (if you're paranoid.)
You don't write which implementation technology you intent to use, so let me start by recommending that you use Windows Communication Foundation (WCF) instead of asmx web services.
With WCF you can select between many different bindings, many of which offer data protection. Overall, there are two different styles of data protection for web services:
Transport protection, where the transport mechanism itself offers protection in form of encryption. The best known version of this is HTTPS/SSL. However, note that unless you employ client certificates, the service has no guarantee that the client is what it says it is.
Message protection, where the message itself is encrypted and signed. Such messages can travel over otherwise unprotected networks and still be protected.
The WsHttpBinding offers message protection according to open standards. That's where I would start.
Have a look at WIF (aka Geneva framework). Its purpose is to solve the exact problem you describe.
http://msdn.microsoft.com/en-us/security/aa570351.aspx