2

I am developing an application which requires one to fill in a form generated using Jquery Ajax and sent via a https connection.

The problem is when I test the application via a normal http connection the application runs fine but when I upload it to the server and connect to it via the https connection, the $_POST variables arent detected by the receiving file.

What can be the problem here?

Jon Taylor
  • 7,865
  • 5
  • 30
  • 55
Stanley Ngumo
  • 4,089
  • 8
  • 44
  • 64
  • How exactly do you send them? Does the protocol and domain name match for the page and the ajax endpoint? – zerkms Jul 27 '12 at 10:36
  • Could you post your jquery ajax code? – Dr. Dan Jul 27 '12 at 10:40
  • Can you clarify these: Are you on http, making ajax request to https? How are you determining that the $_POST variables are not received? – Esailija Jul 27 '12 at 10:41
  • 2
    @Esailija - Are you on http, making ajax request to https? No the application is hosted on a secure server so its Https to Https. How are you determining that the $_POST variables are not received? I insert some code on the receiving file to echo the variables sent, nothing is displayed – Stanley Ngumo Jul 27 '12 at 11:24
  • Ok then, I'd probably start with the network tab in chrome's developer tools with console expanded to see any possible errors as well. I would then clear network activity, press the record button, and make the request, then see if the client is successfully sending everything to the server. – Esailija Jul 27 '12 at 11:35

1 Answers1

0

This would be a Cross domain posting and would be blocked by the browser. Please see this thread HTTPS request via AJAX from HTTP page

Community
  • 1
  • 1
Dr. Dan
  • 2,288
  • 16
  • 19
  • The question doesn't say that the page is loaded over HTTP, even if it did - the request would still get made, the browser would just refuse to expose the response to JS. – Quentin Jul 27 '12 at 10:38
  • @Quentin it's not 100% clear to me at least, he says he is testing with normal http and when he uploads via https it doesn't work. – Esailija Jul 27 '12 at 10:40
  • 1
    @Quentin Is that true? I thought that SOP would prevent JS from making the request at all. Surely by behaving in this manner the only thing it does is make XSS a much more dangerous thing, and doesn't really serve any legitimate useful purpose. – DaveRandom Jul 27 '12 at 10:48
  • @DaveRandom — It has nothing to do with XSS. The same origin policy stops Mallory from telling Alice's browser to fetch Alice's personal data from Bob's site and give it to Malory. If the request caused something to happen on Bob's site, then Malory could just set up a link or form to make the request. Bob needs to implement [CSRF](http://en.wikipedia.org/wiki/Cross-site_request_forgery) protection to stop that happening. – Quentin Jul 27 '12 at 10:51
  • @Quentin But say that Bob has not sanitised some user input and has allowed Mallory to post a comment that has some unescaped HTML in it, and it appears on a page that Alice is viewing, and Bob doesn't really understand cookie authentication so he has put her raw password in a cookie that is exposed to client side scripting. What your saying means that Mallory could inject a script to steal that cookie and post it to his own site, regardless of same original policy. Doesn't it? Or did I miss something? – DaveRandom Jul 27 '12 at 11:00
  • @DaveRandom — That would be a traditional XSS vulnerability, but not what I'm talking about. A CSRF vulnerability would allow Malory's site to tell Alice's browser to go to Bob's site and (if Bob ran a forum) post rude messages in Alice's name or (if Bob ran a bank) transfer money to Malory's account. Both of those things are things that the site allows, but they should only be possible if Alice wants to do them and Malory shouldn't be able to make Alice's browser do it without Alice approving. – Quentin Jul 27 '12 at 11:04
  • @Quentin I'm liking this Mallory character less and less by the minute. It's my understanding that CSRF involves tricking the browser into requesting what appear to be "static" resources (images, CSS etc) embedded directly into the HTML rather than scripting it - so it's not really relevant to this AJAX-related question. Or is that wrong? – DaveRandom Jul 27 '12 at 11:11
  • CSRF is where a site lets authorised users do something and assumes that requests from authorised users will start out from that site. Then another site sets up a link/form/Ajax/whatever to make that request with some predefined (by the attacker) data. The authorised user then uses the link/form/script and their credentials are used to make the attack. The relevance here is that the question said *$_POST variables arent detected by the receiving file* and the answer claimed the request would not be *sent*. Preventing the request from being send could help (not much) defend against CSRF … – Quentin Jul 27 '12 at 11:23
  • … but browsers don't do that (since there are so many other ways to make requests that it would be pointless). – Quentin Jul 27 '12 at 11:24
  • 1
    And a comment on the question itself has just confirmed that both the Ajax request and the request for the original page are both over HTTPS. – Quentin Jul 27 '12 at 11:25