I have to integrate a 3rd party newsletter signup form that makes an AJAX call to HTTP url.
That form I'm placing on pages that use HTTP or HTTPS protocols ( http for home pg., ect.; https for ecommerce related stuff )
I don't think anything is sent back from the destination server ( at least I can't see the response) other than status code.
I'm getting 200 OK whether I submit the form from HTTP or HTTPS page and watch what's going on with it in Firebug. Wonder if it's safe to assume the call gets processed successfully?
Usually, I like to have a proof positive that something worked or didn't, but in this case all test signups show up the next day, ( due to sign up getting processed as some scheduled task I'm guessing ), hence the unease.
You can call https server from http but can't call http from https directly using AJAX.
To call http user from https server you need to call your server side application from java script using AJAX, and then call http url from your server side application then send back this to the client.
You can use window.location.protocol to check whether you're currently on a Secure connection, and if so, you should AJAX a secure url.
Related
I plan to use https to build a website. After the user logs in, s/he is directed to a dashboard. The dashboard will be developed using javascript and html5. What are the thing I need to keep in mind when I make ajax calls using SOAP to a web service while using https?
The most important things:
always use the same domain name, otherwise browser will throw cross domain errors,
always use https protocol for every ajax request, so browser won't get same origin errors.
On the server side check for X-Requested-With: XMLHttpRequest HTTP header, to be sure that the request came as AJAX, not standalone GET/POST request. This is only difference.
With AJAX request browser will send the same cookies value as in the any other request, so you can surely check user session with it.
Cross domain AJAX requests are reported as "aborted" in firebug. I know this is supposed to be security feature but where exactly these requests get rejected ? At the browser end or at the server end ?
Browser - they don't get sent at all. If you check your HTTP traffic (e.g. using Fiddler), you'll see that there is no corresponding HTTP request initiated for those aborted AJAX requests.
(That is also the only place where such blocking makes sense, as the server doesn't have a reliable way to distinguish between AJAX requests and normal requests; only the browser has enough context to make such decision.)
Given all the coverage FireSheep has been getting, I have been trying to work out the best practices for balancing HTTP / HTTPS usage for some sites I manage (e.g. blogging sites, magazine sites with user contributed comments).
To me, its over kill to deliver all pages over HTTPS if the user is logged in. If a page is public (e.g. a blog) there is little point encrypting the public page. All I want to do is prevent session hijacking by sniffing cookies over HTTP channels.
So, one plan is:
Login form is over HTTPS
Issue two cookies: One cookie is 'public' and identifies there user for read only aspects (e.g. 'welcome bob!'). The second cookie is private and 'HTTPS only'. This is the cookie that is verified whenever the user makes a change (e.g. adds a comment, deletes a post).
This means that all 'changing' requests must be issued over HTTPS.
We use a lot of AJAX. Indeed, many comment forms use AJAX to post the content.
Obviously, I cant use AJAX directly to post content to a HTTPS backend from a HTTP frontend.
My question is: Can I use script injection (I think this is commonly called 'JSONP'?) to access the API? So in this case there would be a HTTP public page that sends data to the private backend by injecting a script accessed via HTTPS (so that the private cookie is visible in the request).
Can you have HTTPS content inside a HTTP page? I know you get warnings the other way around, but I figure that HTTPS inside HTTP is not a security breach.
Would that work? It seems to work in chrome and FF, but its IE that would be the party pooper!
Another way is to have an iframe which points to a https page that can make all kinds (GET, POST, PUT etc) of Ajax calls to the server over https (same domain as iframe is on https too). Once the response is back inside the iframe, you can post a message back to the main window using HTML5 postMessage API.
Pseudo code:
<iframe src="https://<hostname>/sslProxy">
sslProxy:
MakeAjaxyCall('GET', 'https://<hostname>/endpoint', function (response) {
top.postMessage(response, domain);
});
This works in all modern browsers except IE <= 7 for which you'll have to either resort to JSONP or cross domain communication using Flash.
The problem with JSONP is that you can only use it for GETs.
Can you have HTTPS content inside a
HTTP page? I know you get warnings the
other way around, but I figure that
HTTPS inside HTTP is not a security
breach.breach.
Including HTTPS content inside a regular HTTP page won't raise any alerts in any browser.
However, I don't think JSONP will help you out of this one. Using GETs to post content and modify data is a very bad idea, and prone to other attacks like CSFR
One of my colleagues is having a problem with an AJAX call to a .NET WebService. The call works under HTTP, but the same call is having a problem under HTTPS. The webservice is written in .NET 4.0 with C# on an IIS 7 server.
The secure website is at https://sql.data-rx.com/grouppharmdrugsearch/. There is an unsecured version at http://sql.data-rx.com/grouppharmdrugsearch/. There isn't any sensitive information on the page itself. It is embedded (I believe in a frame) on a client's website that does use HTTPS, and our page needs to be in HTTPS so browsers don't give a mixed secured/unsecured elements present message.
To test the problem on the site you first have to enter a zip code in the second textbox (I have been using 90210 for testing) and then you can enter the first few letters of a drug into the third textbox. After waiting a second or so for additional letters the page calls the webservice to populate a drop down list of possible drug choices beginning with the supplied letters. The secure webservice call is to https://sql.data-rx.com/grouppharmdrugsearch/Service/drugNameAutocomplete.svc/GetDrugList with POST data for 'prefixText' and 'count'. Under HTTP the service call succeeds and populates the drop down; under HTTPS the call gets a 404 error. The HTTPS web service is reachable if you point a browser to https://sql.data-rx.com/grouppharmdrugsearch/Service/drugNameAutocomplete.svc, but the method isn't recognized when it is appended to the service.
I have been using Firefox's Tamper Data addon to compare the service calls and they appear to be exactly the same, except one is to the HTTPS site and one is to the HTTP site, with the referrers changing appropriately. The HTTPS call receives the 404 error, while the HTTP call receives the JSON data.
I believe there may either be something missing from the webservice that would allow the call to function under HTTPS (though I can't think of anything that should matter in this case), or the HTTPS web site itself was misconfigured when it was setup. Any help would be appreciated.
We finally figured out the solution from this site. Basically the binding was only configured for HTTP, not HTTPS, and we need to create a custom binding to allow the webservice to function over HTTPS.
Would there be any problems calling an HTTPS page (e.g. a credit card authorisation service i.e. WorldPay) from a standard HTTP page via AJAX?
I can't imagine why there would be a problem, the response would be an HTML page which I could then embed in a result pane or such like?
Yes this would be a Cross domain posting and would be blocked by the browser.
Anthony is right, but what you could do is create a local page the AJAX calls and that communicates with the HTTPS service via cURL or something else and returns. That way everything is done locally according to Java script.