I am building a web application and RESTful web service.
I have been reading various articles about the best way to authenticate the requests to the web service.
The best option for me seems to be to use HTTP basic authentication. Pretty much every article ive read says that authentication should be encrypted over SSL or equivalent.
Im not totally sure what this involves. Does this mean that my whole web service will have to be on a secure server? Will this slow things down?
This really depends on how much data is being transferred and the amount of hits your service is getting. Encrypting the data will increase processing time and typically the amount of information transferred. However, if you choose basic authentication without SSL and there is a user running a packet sniffer on your network, it is almost like yelling your credentials across the room. It is possible to switch between HTTP and HTTPS by configuring your .HTACCESS if you'd like. See the link below:
Correctly switching between HTTP and HTTPS using .htaccess
Related
Im working on some JSON-based web service that is supposed to work with Android application.
I would like to encrypt data transport between client (android) and server (virtual server in datacenter).
I don't have to make sure that my server is my server, just data encryption.
I have no idea how to use HTTPS.
Do I just put my PHP files in private_html and use https://example.com url?
To use HTTPS, you don't have to do anything in the coding of your web service - it's all in your hosting. Here the are steps you can follow. The specific instructions differ in your hosting (IIS, Apache, AWS/Azure, etc), but you can google specifics on how to accomplish any of these steps for whatever host and application framework you decide.
Buy an SSL certificate (there are many different vendors, but expect between $75-$200 for the certificate) based on the vendor, reputation, and level of security you need.
Generate a certificate signing request (CSR) from the server you'll be hosting.
Upload the CSR to the SSL vendor who will validate and provide the certificate for your use.
Import the SSL certificate into your application server, and configure the site to use the certificate. For instance, if you're hosting Microsoft IIS, you'd import the SSL certificate and then add HTTPS bindings on 443 to the specific website hosting your web service.
Another point of security. Since you are deploying SSL, you don't have to do any application level encryption (assuming you are not putting sensitive information in query strings - use POST if you think you need to). You probably would want to implement some security to restrict access to your web service so only your app can access it. Best practice is some level of OAuth, but at a minimum some type of pre-shared key in the header of the request is a lot better than nothing.
Here are some additional sites for more information:
https://www.digicert.com/ssl-certificate-installation.htm
https://support.godaddy.com/help/category/742/ssl-certificates-installing-ssl-certificates?prog_id=GoDaddy
If you don't want to pay for a certificate, you can use certificate signet by your own CA and add the root certificates into your application using HTTPClient and keystores
Here there's some guides
http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/
http://developer.android.com/reference/org/apache/http/client/HttpClient.html
KeyStore, HttpClient, and HTTPS: Can someone explain this code to me?
http://blog.antoine.li/2010/10/22/android-trusting-ssl-certificates/
You can limit users to use JUST and only HTTPS in apache, IIS or whatever do you use. If your client connects to your server, his communications will be likely to encrypted, because he is already using HTTPS. And for responsing in HTTPS you virtually cannot send HTTPS responses, as far as I know, unless that other side isn't also a website (for example, if you have your website, you could send such a response e.g. to Google). You should be okay to send data like http status codes (OK, NotModified, PageNotFound, ...), or if you want something more, or if it is a requirement, then there you still have JSON and you could encode it as well, with some encoding algorithms, or use binary JSON format.
Check if your hosting company provides a free public shared https address. Most of them do.
If you want to understand how to do it right, follow this thread
Warning: Don't stick with the solution below for production.
If you plan o use an https endpoint without a certificate you have to make sure to disable peer verification, check this answer
I have developed a Django application and now want to make sure the POST data transmitted through the page is safe.
I have couple of questions about this?
I see SSL certificates being displayed on many webpages. How do I get this certificate?
Do I need to change anything on my submitted form to encrypt the data or should I change any settings on my webserver?
I know its a general question but it would be great if someone provides a good answer.
First off, the POST data transmitted through the page is never safe from an application perspective. You don't have control over the user of the website. SSL and HTTPS helps prevent man in the middle attacks to ensure the request from the client (browser) to your server is encrypted. The underlying data that is sent can be malicious, so you should always validate inputs.
Secondly, if you want to use HTTPS and SSL, which I highly recommend, you'll need to obtain a certificate from one of the providers out there and install it with your webserver, which I presume is apache. Typically your domain provider can help you with obtaining an SSL certificate for your domain from one of the main certificate authorities. Regarding the installation and setup, there is tons of information about this online as it's a common task. I'm not familiar with Apache configuration to provide any specific recommendations. You'll also want to have rewrite rules so that your site can only be accessed via HTTPS and if someone tries to use HTTP, it simply redirects to HTTPS.
Lastly, you don't need to do anything in your Django application as your webserver should handle the basic interactions between your server and client to validate the HTTPS requests.
My title might be overly specific - I'm having trouble formulating the question, since I haven't dealt with network administration a lot, and especially not SSL / HTTPS. In other words, the answer to "Why haven't you done . . ." is like to be, "I don't know much about ...."
I am testing, and the System Under Test (SUT) is a web service calling into the Facebook API using https://graph.facebook.com.
I have a test server set up on a remote machine that will serve pages to http://graph.facebook.com. I can use the hostfile on the SUT server to redirect requests to http://graph.facebook.com to the test server. This works fine when I then type:
curl http://graph.facebook.com
The test server receives the request, and serves back the expected page.
However, as mentioned before, the SUT isn't using the HTTP site, but the HTTPS site for the Facebook API (naturally). Is there any way I can intercept the outgoing request and redirect it to the HTTP service that I'm running on the other site? I'd like to be able to type:
curl https://graph.facebook.com
and have it be redirected to the fake Facebook service I'm running on the test server. I can configure the servers at both ends.
If this is very difficult, I might also want to put in a feature request for the ability to change the URL for the Facebook API requests. However, I think the dev is using a pre-existing Facebook API module, and this might not be straight-forward. (Okay, I got curious and checked . . . a quick investigation suggests that the API supports data injection of the code that handles the actual HTTPS requests, so he'd have to implement his own version of the interface so that he could pass in a configurable URL that I could set from outside of the code - but I'd still rather not distract him unless it's really necessary).
I'm using an asis-server on port 80 to fake the Facebook responses, if that is relevant.
The solution we ended up using was a service on the test server that intercepted the HTTPS requests and redirected them to the HTTP service. Our ops person used nginx for this.
We're still not sure if this will work as a mock for the SUT - it depends on if the SUT is verifying the certificate information or ignoring it. I still might need to ask the developer to implement a feature to support mocking.
I'm currently developing an iPhone application which implies a server side with some services on it. I did this server side using php and I call the services with a basic HTTP Request from the iPhone.
I don't have any idea on how to secure that kind of call and to make sure that my services are being called only from my iPhone app and not from somewhere else...
Should I change my services to a standard procedure like SOAP or REST services?
Thank you for your advice.
Martin
In short, there's no 100% foolproof way to make sure that the services are only being called by your app.
In longer, if you connect over SSL (ie, use https), it will become much harder for "casual" observers to see what's going on… But it would still be possible for someone to, for example, use an HTTPS proxy and sniff the connection that way.
You could also use a method like oAuth, where there's a secret token hidden in the source code of your application, and it uses that token to authenticate its communication… But, again, it wouldn't be too hard for someone to spend an evening reverse engineering your app to extract that token.
I've been looking at http traffic analyzers which are browser addons that monitor and analyze all incoming and outgoing HTTP traffic between the browser and whatever web server you're connecting to.
The types of information available per request include:
* Request and response headers
* Sent and received cookies
* Querystring parameters
* POST parameters
* Response body
My question is whether it makes sense to use this to build a web service.
What I am interested in is using Windows SkyDrive - which offers 25GB of storage per user account - as a storage solution for my web app.
So what I am considering is using HTTP traffic analysis to figure out how to get my web app to mimic a browser interacting with my SkyDrive account.
Is this a bad solution? I have a feeling one of two things could happen quickly:
Microsoft figures out that these are automated requests and shuts down my SkyDrive account and deletes the data.
Microsoft changes the authentication front-end regularly, requiring me to repeatedly reprogram the portion of my service that interacts with SkyDrive.
Has anyone tried something like this and encountered difficulties? I would like to hear some feedback on whether this is likely to be worth the effort or not.
What you want to do is probably possible, technology wise. But is it allowed under the terms of service of SkyDrive? and what is the worst case scenario if they do change their protocols? Will you be trying to run a business off this data? Have you considered using something like Amazon's Simple Storage Service, which is designed to accommodate exactly what you want to do? Why waste your time reverse engineering the skydrive protocol?