I have a .net web application that post data to server from javascript via jquery in association with wcf ui services. This enables a non post back modal.
Is it possible to encrypt the data being sent to the server so that using sniffing applications such as fiddler and firebug, the POST of the data cannot be viewed. I want to achieve this for security. The data will need to be read on the server side.
Any tips on this?
Any encryption performed by javascript on the client side will be reversible on the client as well. At best you could achieve some obfuscation for non-technical users.
Make the request to an ssl endpoint. The action would be https://something/action.
Setup IIS 7
http://learn.iis.net/page.aspx/144/how-to-set-up-ssl-on-iis-7/
Setup IIS 6
http://www.petri.co.il/configure_ssl_on_your_website_with_iis.htm
Just use HTTPs. Whether its a "traditional" form or XHR SSL\HTTPS is possible.
Note that, with something like firebug (or Chromes debuger's network tab), you'll still be able to see the data... but that's because its part of the browser. An "external" sniffer, like Wireshark or a potential bad guy doing a man-in-the-middle attack, will not see the plain-text data on the wire (but will see encrypted data instead).
Related
In .Net web-service hosting the IIS and used for the desktop application while login the app the person track and see all the input calls to service and response back into app.
Then analysis the issue and go through google and got solutions. to make HTTPS or ssl in webservice url.also encrypt and decrypt also doing both client and server side.
after that i check with fiddler they also tracking the web services call and responses .even they can able to break and run the app using this.
I was tired and make the protect the webservice calls. and unable to achieve the what i need.
I also attached screenshot below for your reference.
Guys plz help me...if any otherway to protect the service calls in Fiddler.
I see no screenshot. But if I understood correctly then you are saying that fiddler can decrypt your traffic.
Well that is because fiddler imports fake certificates into windows certificate store and then proxies data through itself. That is why it can actually decrypt data. I don't really see a point to try to protect web calls from Fiddler. But you can force direct connection and try not to use proxies with your application. But then again... you won't be able to use any proxies
is there some codes to encrypt a form data through webconfig?
some sort of codes or in global.asax? im currently developing a log in for my website and i dont want to use SSL. is there some way to solve my problem?
No. The web.config file only controls how the server behaves. Between the client and the server you need to rely on the HTTP protocol.
This is exactly why HTTPS (i.e. SSL) exists. If you need to encrypt data while it is being transferred from the client browser to your web server you must use HTTPS. There are no shortcuts.
I am new to web services so I created a web service to replace my current in-app DB transactions. I wanted things to be safer so that is why I went this way.
When using a free packet sniffer, it instantly grabs my web service ASMX call. The problem with this is that using a program such as fiddler they can easily see the data going back and forth and even worse set up a auto responder.
Is there a way to hide the calls being sent to the web service to hide from packet sniffers? Or at least make it more difficult to see the calls?
Expose it over a secured channel (such as SSL) only for transport level security.
Alternatively, you may choose to implement WS-Security to validate the identity of the callers, sign the payload or encrypt the payload (partially or fully); or any combination of the above.
Here is an article that talks about this in the context of ASP.NET: http://msdn.microsoft.com/en-us/magazine/cc188947.aspx
If i want to develop an iPhone app with a client-server design (iPhone devices as the clients and a c# server),two questions:
Is it possible to use my own laptop to run the server on? and if not what are my options?
Do i have to develop my own protocol for transferring messages?
So if i understood right the process of sending a message like "CREATE NEW USER" from the client to the server is as follow:
1. The client will create a JSON/XML containing the command "CREATE NEW USER" and the new user details.
2. The client will send this JSON/XML via HTTP request (as the body of the HTTP request) with a URL that maps to a c# method on the server side.
3. This will trigger the appropriate method on the server and the new user will be created on the database.
4. The server will create JSON/XML containing the replay "CREATED" and will send it to the client vie HTTP response (as the body of the HTTP response).
Is that correct?
You want either xml or json over http. Web Services and REST over http was created for interoperability problems between different platforms which is what you're facing.
Since you're using C# for the server, you can look into WCF and use either a REST pattern or SOAP (web services) to expose your actions and data. Concerning the data you can serialize those objects over the wire as JSON or XML.
For iPhone consumption, I would recommend REST (since that basically maps a url request path to a C# method). From the phones perspective, it's just a url request and xml or json data comes back.
In C# you simply create your methods and decorate them with DataContract attributes. Then, on your methods you map them to url relative paths. Search the net for WCF and REST services. You can run it in any host from a command line to a windows service to IIS.
http://msdn.microsoft.com/en-us/library/bb412178.aspx
When creating those C# services, if REST, you can hit the requests in a browser and see the data come through. You should also look into Fiddler to inspect your traffic: http://www.fiddler2.com/fiddler2/
On the phone side, you first need to make the http request. You can do that with iOS classes but wrappers like ASIHTTPRequest make it much easier. Once you get the response back, you have to parse it. If you choose XML the iOS classes offer simple ways to parse the xml response. If you choose JSON, there's classes like SBJSON.
http://allseeing-i.com/ASIHTTPRequest/ - (Read this ASIHTTPRequest blog before using)
https://github.com/stig/json-framework
rest web services in iphone
There's also a much higher level framework called RESTKit which makes the iPhone side much easier.
https://github.com/RestKit/RestKit
Hope that helps tie it together for you.
EDIT:
Adding the create new user scenario:
The client creates a user object with the data (username, password etc...) and sends an HTTP PUT request to http://yourserver/myservice/users. The client serializes the user object to JSON/XML in the body.
What is the recommended/effective request payload for a REST PUT method?
PUT vs POST in REST
The server receives the request. On the server, you have a WCF "myservice" service (it's a class). It has a "public User CreateUser(User user)" method. In that method it creates a user object by doing whatever it has to do (call database etc...). It returns the User object because perhaps the server added info like the user id. The article below has a put request example.
http://damianm.com/tech/building-a-rest-client-with-wcf/
The client would get the response and the user object with all the details like id, etc... would be in the body as JSON/XML. It would deserialize that into a User object on the phone.
The server could also expose things like:
/User/{id} --> public User GetUser(string id);
I'd strongly recommended to rely on the HTTP protocol. Don't implement your own networking protocol!
Use GET requests to fetch data from the server and POST requests to send big amounts of data from the client to the server.
In order to structure your data, encode the data using JSON.
Here is a nice tutorial that explains how to do that with ASIHTTPRequest and JSONKit: http://www.icodeblog.com/2011/09/30/dynamically-controlling-your-application-from-the-web/
And yes, you can run the server on your working machine.
You can do this fairly easily with ASIHTTPRequest. It's a free 3rd party solution that can talk to different types of web services.
ASIHTTPRequest website
Not sure if this answers your question, but just as a suggestion so you don't have to deal a lot with server side stuff, use Parse
I need to call a .NET SOAP webservice in a secure way. It must be secure in such a way that others can't call the WebService methods, and also it should not be possible for "the middle man" to understand the content of the messages.
The caller will also be a .NET webapplication installed on another IIS.
I can design the webservice methods as I want, so no restrictions there.
I have been researching HTTPS/SSL with certificates, but I don't know if it actually solves my problems in a good way? For example, it would be anoying if the certificates has an expiration date, although it's not a showstopper in any way.
So how would I go about this in a good way..?
Thanks for any help.
As #BrokenGlass said, SSL only encrypts the traffic between points. It doesn't handle securing individual functions from usage without authorization. Here is a good article on just such a topic using SOAP headers:
How to: Perform Custom Authentication Using SOAP Headers
This can be mixed with any form of authentication except Windows Integrated. To use Windows authentication, you'll need to have a separate library which accesses the Active Directory through the DirectoryServices namespace.
Assuming you control the infrastructure then keeping the server that is providing the web services behind a firewall so it's accessible only from the web servers and implementing IPSec should provide the necessary security.
From the software point of view, this article contains all you need to know about protecting the service interactions.
HTTPS/SSL works fine. Just make sure to renew your certificate in time to avoid warnings and messages for your client.
I need to call a .NET SOAP webservice in
a secure way. It must be secure in
such a way that others can't call the
WebService methods, and also it should
not be possible for "the middle man"
to understand the content of the
messages.
HTTPS/SSL only solves the "middle man" part of what you want to achieve. You would still need proper authentication in place on your web service. You could do this i.e by using the built in Forms authentication and providing a Login method that returns your authentication ticket.