What is the difference between request by form submit and request by ajax?

Question

I understand the basic ideas of XSS and same-origin-policy, so if your knee jerk reaction is to school me on the basics, you can jump ahead at least a half step...

If javascript is client-side, at what point is an http request submitted via XMLHttpRequest distinguished from a user submitting a request via a form submit button?

Here's my actual situation:

I am working on a script that will (if it's possible) aggregate secure data from a secure subdomain where such private data lives. For the sake of this question, I'll call my site staff.work.org and the other site personal.work.org.

Back Story, skip if you want

So the benefits of such a script is that it would both streamline a redundant process and add benefits to both staff and management. Right now, ever staff member has to send the scheduling manager their availability for that term. Since most of the staff are students, they basically just need to email their class schedule. They each send in their schedule via email and the manager does whatever they do with it, probably just makes a big text file or Excel file.

But what I want is for them to simply go to a "Schedule Importer" type page that would pull the data from personal.work.org onto my script at staff.work.org (the company has direct sponsorship and branding of the college, so we are hosted on their domain). This way, they can confirm the classes, make any changes, and then submit their availability. The data would then go to an SQL DB that the manager could pull up on a admin page and get a much better idea of the big picture. Not only that, but my script would offer the staff members the ability to convert their schedules to ical so they can put in their Google Calendar and keep up with school better, yadda yadda.

---

I gave that back story so that a) You'd see this isn't just ajax for the sake of ajax or cross-domain scraping just to cut a few corners, and b) because any alternative ARE welcome.

So, both sites (staff and personal), use the same authentication method, and thus the same cookie. Logging in to one means logging in to both. So the user can very easily have both pages open at the same time, etc. If I set the private data in an iFrame, they'd see it with no need to login again.

Things that don't work

So, the data can't be retrieved by cURL because the cookie has the login IP wrapped in it, and thus cURL shows up with the server's IP, not the user's. A new cookie can't be created on the server side, among other reasons, because the login site refuses any login attempts that originate from IPs tied to the main servers. So server-side is out, as far as I can tell.

But attempts to retrieve client-side via ajax and jquery result in the request being treated as cross-site, since I have to put in the full URL due to the subdomain. Instead of passing the cookie and the GET Method, it's passing:

Access-Control-Request-Method GET
Access-Control-Request-Headers cookie,x-requested-with

Which a quick Google search tells me is the w3c's attempt to have legit XSS. Fair enough, but it's not working so I guess that won't work.

I know that if I put it in an iframe I won't be able to traverse into it for similar reasons.

lame workarounds

But the only other alternatives I can think of are a) having the user download the schedule page and upload it to my page, b) having them view source, copy and paste that onto my page, or c) having them copy and paste straight from the normal browser view.

The first two are not going to win me any genius awards or really catch on. And any copying and pasting is so full of potential error on both my end and theirs that it's not worth the risk.

Short version of question

But if I put in a form that points to the schedule page with method as get, hitting a submit button (with no other inputs or values) just takes them straight to the page like it was a link. Is this simply part of the browser's XSS policy, where request sent by js are warped before they make it onto the tubes? Or does something happen at another point? Is there a way to "download" the page using a form (without having server access to personal.work.org to change the Headers on that end?

Basically I'm guessing I'm out of luck and it's for the greater good, but it seems like there is something I am missing that should allow for trading data when the user is already authenticated using the same cookie...

Oh, I checked out this article on the topic that was insightful that suggested setting document.domain = work.org in both documents would fix the issue. Not only is that not an option, but all attempts to set that even on my script failed, according to Firebug (document > domain : "")..

Any ideas?

Answer 1

Thats correct, those attempts will be treated as XSS and I don't think you can get ride of it so easily. But, there's a nice workaround that you can see being used by Google to authenticate users cross-domainly over their services. Adaptating it to your situation, it would do something like this:

1. Domain A submit data to domain B via iframe, not expecting to have access to the answer.

2. Domain B in answer, tells the browser that it is being redirected back to domain A, page /handle.php?data=[some encrypted data which server A can decrypt with a password only your system know]

3. Domain A now knows what came from B, and can tell user's browser what do do with it.

Recomendations about this encrypted data: First bytes should be a checksum. Even if hackers can't decode it, they can push erroneous data to your server by editing the request dumbly. The data shall also bring an unique ID and possibly a expiration date of 1 or 2 minutes, so it can't be submited twice or recorded to be submitted in a different time.