[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 277
  • Last Modified:

XMLHTTPRequest from client-stored HTML page?

Okay, a question for you AJAX pros. =)

It's kind of a wierd scenario, but basically we have customers who will be installing local copies of several .HTML pages on their computer (for local/offline accessibility).

I'd like to have those HTML pages, when an internet connection is available, access dynamic data from our website to populate certain sections.  It seems to me that AJAX would be usable for this scenario, except that apparently XMLHTTPRequests cannot be made between domains (which would obviously be the case in this scenario, because the page would be located on the client's local filesystem and it would need to do the XMLHTTPRequest to my external website)

Is there a way around this?
  • 3
1 Solution
AFAIK not possible to write or update local page with AJAX. Google has developed a plugin which is capable of such things. See http://gears.google.com/
ISCANTEAMAuthor Commented:
Hmm... curses. =(

Though I'm starting to read now about JSON (been spending the day researching), and it seems that there's a (risky from a security perspective) way to inject the data without cross domain restrictions by creating a JSON feed and then consuming that feed with a script tag.

Perhaps I should ask this as a seperate question, but it's somewhat related.  In my reading, I've seen an extensive amount of security concerns related to using JSON in the manner described above, and I have a feeling that it's just the tip of the iceberg.  I'll keep researching, but I might as well appeal now to those who likely know much more than me about this while I investigate (it's all new to me =) ):

If I am the developer of both the client's locally stored webpage and the JSON feed, are there any security vulnerabilities that could still effect me or my clients?  The data being displayed through the feed is non-secret, not like passwords or address information or anything (but it will be updated by us online, as a sort of dynamic resource of publicly available data), and a user need not log in to see this data through the locally stored webpage.  So I'm not worried if someone steals that data (be my guest), but I *am* worried that someone could use this data transfer to somehow usurp unrelated data from the user's PC.  I'm not sure how they'd do it, but if a malicious site could sneak their own script tag in as a result of what I'd be doing, I'm not sure how much harm/scope that script could have as far as stealing a user's data (such as files on the PC, or passwords to other websites, etc...).

Are these feasible scenarios to be worried about, or am I safe because I'll be creating the feed and the data being sent through the feed will be loaded/sanitized by myself?  And in general, could a malicious Javascript code injection be capable of taking things like a user's files or passwords for sites other than the site currently being accessed?  I'd definately like to prevent that scenario from happening in my web programming, and I'm just not sure of the extent to which Javascript could be used for such nefarious purposes.  

(I'd hope that such things would be protected, otherwise using a plugin like Stumbleupon to navigate to random websites could turn out extremely dangerous indeed... ack.)

Anyways, sorry for the rambling. =)  Any information is appreciated!
why not simply use iframes?
(I'd never recommend iframes if security counts somehow, but it may be a solution to your problem)
ISCANTEAMAuthor Commented:
Hmm... iframes?  I'll look into it!  Hadn't thought of that one... I'll do some research and see where that leads.  Thanks!
ISCANTEAMAuthor Commented:
Well, I ended up figuring it out on my own, so I figured I'd post it here.

I used a dynamic script tag to retrieve and call a function, passing it a JSON Object that was generated by my web service that had the security irrelevant data.

Basically for anyone who's interested, it works like this:

1) Create a Webpage that accepts the name of a callback function in its querystring, along with any other needed data (Primary IDs, user names, whatever as long as you don't need anything secure).  This webpage should generate the JSON object, and then create a string that would appear in Javascript to be you calling the callback function and passing the JSON object, like so:

Passed in Callback Function Name: doStuff
Passed in User ID: Mary

(Retrieve information for Mary that doesn't need to be secure, such as news that was custom made for her or whatever)

Return "doStuff(" + strJSONObject + ");"

2) In the client webpage, create a <script> tag that, in the "src" attribute, calls the webpage created in step 1 with the necessary querystring arguments.  In our example:

<script src="http://www.somewhere.com/DoSomething.aspx?Callback=doStuff&UserID=Mary">

3) In that same client webpage, write the "doStuff" Javascript function that will use the JSON data to create new webpage elements or change existing ones.

The one thing for anyone who may run into this to remember is that this JSON communication is inherently insecure as far as I can tell.  I personally wouldn't pass anything but publicly known/available data, or data that isn't really relevant or harmful for anyone to know but the end user.  We have a lot of harmless custom data (resources, news etc...) that we pass to the user in our Application: none of it should ever have a negative impact if someone comes in and makes a forged query in her name, because they couldn't do much with it (except maybe find places to shop that she might like =) ).  But anyways, user beware.  Don't do anything like credit transactions or anything silly with this idea.

And don't use it to process an untrusted JSON service.  <script> tags can be used maliciously in cross site attacks to gain access to user authentication tokens if the dynamic script being pointed to generates malicious data.  So be sure that any data being sent out through your JSON creating webpage in step 1 has been thoroughly validated and parsed to remove malicious code.  Also be sure that either you've written the Webpage yourself in step 1, or that it's from an extremely trusted source (co worker, trusted business partner etc...).  Don't connect to Joe Schmoe's JSON Service run from Geocities or anything like that. ;)

Anyways, good luck, hopefully this helps others so they won't have to research for two days like I did. =)

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now