2014r2: webapp in iFrame ??

I have a webapp named “saferpay terminal” which runs standalone on a ubuntu linux server. I used to display it in an iFrame of a website. My latest build is with Xojo 2014r2 and now it no longer appears in the iFrame.

When I call it directly, outside of the iframe, then it shows up as expected.

Most likely this is my bad, but I can’t figure out what I did to provoke this. So I just want to make sure that there is not a known issue with the latest Xojo here.

Is anyone successfully running in an iframe a standalone webapp, which was built with the latest Xojo (2014r2)?

Ah, this was in the release notes but to bring it up here- we added a X-Frame-Options header with default value of SAMEORIGIN as of r2. This was to be more secure from clickjacking attacks by default.

Are you able to make your web app come from the same domain name as your website? That would address the issue.

I just built with Xojo 2013 r4.1 and then the webapp shows up without issues in the iframe.

The webapp comes from the same domain in my test, but this is not necessarily always the case. We have websites in different countries with the option to register with seminars taking place in Switzerland. We want to have one registration app for all of those.

But right now I have the website and the webapp on the same testserver and it does not work.

Please make this setting an option, and not a forced lock down!

OK. We’ll work to address this for you in a near-term release.

[quote=107189:@Travis Hill]Ah, this was in the release notes but to bring it up here- we added a X-Frame-Options header with default value of SAMEORIGIN as of r2. This was to be more secure from clickjacking attacks by default.

Are you able to make your web app come from the same domain name as your website? That would address the issue.[/quote]

Is it not possible to edit that header ?

[quote=107189:@Travis Hill]Ah, this was in the release notes but to bring it up here- we added a X-Frame-Options header with default value of SAMEORIGIN as of r2. This was to be more secure from clickjacking attacks by default.

Are you able to make your web app come from the same domain name as your website? That would address the issue.
[/quote]

Ugh. I have to test this, but on the surface, this sounds like it’s in the realm of unacceptable. At the very least, this requires a simple way to turn it off.

Keep in mind that if you can do this, so can anyone else. You have no control over who is showing off your app as theirs.

That being said, we’re working on fixing it.

[quote=107278:@Greg O’Lone]Keep in mind that if you can do this, so can anyone else. You have no control over who is showing off your app as theirs.

That being said, we’re working on fixing it.
[/quote]

Not quite accurate. One can hack the CGI script or Session.Open to look at the referrer and divert elsewhere. I actually remember showing you the effects of that a year or two ago with my clock widget ;-).

Well yeah, but most users are not going to think about having to do that. It’d be better all around if we could provide you a way to have this built in security with the ability to turn it off if you want to.

[quote=107321:@Greg O’Lone]Well yeah, but most users are not going to think about having to do that. It’d be better all around if we could provide you a way to have this built in security with the ability to turn it off if you want to.
[/quote]

I guess. I’d hope that before future security features are implemented, some consideration is given to legitimate use cases that would then become problematic. This one didn’t make my radar as a potential problem during beta testing. It seemed an innocuous fix to solve click-jacking problems. This is the release note summary:

We did consider this when making the decision, but to us, the risks to our users outweigh the potential benefits. To be fair, that’s part of the role of our beta testers… To tell us if anything we did in the release cycle broke anything. We had no reports, so as far as we knew, everything was good.

Well, that would take a deployment–squared test from a beta tester to find, i.e. deploy then try embedded. A more descriptive change description in the release notes might have helped there.

Good morning.

1.) Right now it is not working as you intended. I have an app starting from the same domain as its enclosing website, but the 2014r2 built version doesn’t show up in the iframe.

2.) If you make such an important restriction, I expect you to announce this in a more prominent way, in the beta cycle. I did read the release notes, but as Brad pointed out, that text sounded harmless to me and did not make my alarm bells ring.

3.) You can only try to make sure a Xojo webapp remains enclosed in its original iFrame, in a website with the same url. You have no way to secure the website itself. A potential hacker could still replace my webapp in the iframe with his own. You cannot really provide security here. We pay more than we gain.

4.) I think it is a bad idea to castrate web functionality and make it work in a “Xojo” way, which now is different from how iframes work in general. I don’t know of any other tool which would impose such a restriction. Bad idea.

5.) Security of iframes is anyway not in your responsibility. It is in our own responsibility to evaluate the use-case and the risks and then decide about what we do.

6.) What would be very helpful and highly appreciated would be a boolean property SAMEORIGIN where we could set ourselves the expected behavior. But then it would actually have to work.

Preventing display of a Xojo app in an iFrame from another site is indeed an interesting feature, and it can be set as default, but it should be possible to turn it off.

Not long ago I advised another member to keep major parts of his site in HTML and use Xojo only for dynamic content. This is exactly the way my half dozen sites work, to keep the search engine visibility I painfully built through the years. iFrames are a convenient way to mutualize resources across different URL of the same group without redundant applications.

I understand you have your customers security at heart and this is honorable. But in this instance, you may want to consider your developer customers adult enough to make their own security decisions. In many ways, this feels like some antiviruses which are trying to control too much, and end up ruining customer’s experience.

It is working exactly as we intended. It requires that the item in the frame be coming from the EXACT same domain.

To be fair, we’ve added other global security features and this is the first to cause any problems. So far, we’ve had only two reports of this issue out of the hundreds of people that are using the web framework.

You miss the point. this is about preventing someone from making your wab app appear in THEIR site, as if it is part of their page.

Functionality hasnt been castrated. we add feature that we think will benefit the community as a whole.
this one will, as soon as we add a switch to turn it off.

We disagree. The web framwork makes it insanely easy for users to get into web development and they trust that we are following safe internet practices within our framework. otherwise theyd learn HTML, CSS and Javascript and do it themselves.

Well good, you came to the same conclusion we did yesterday. Look, r2 has been out a total of two days and we’re working on it. just go look at the beta channel.

[quote=107474:@Greg O’Lone]To be fair, we’ve added other global security features and this is the first to cause any problems. So far, we’ve had only two reports of this issue out of the hundreds of people that are using the web framework.
[/quote]

Can we at least get these things marked as “Web Security” in release notes, and given enough details in descriptions so we can figure out what’s up? These just feel like the kinds of changes that are most likely to have unintended consequences that will end up being difficult to track down when we notice them.

We are sensitive about this kind of thing because there’s an implicit contract here about what’s supposed to work, and it’s being changed on a whim “for the benefit of the community” without telling us. Also, “because security” is beginning to sound like a trump card, triggering an immediate round of head shaking and scratching. You need more buy-in on these kinds of changes while you’re making them. No offense intended, just telling you the perception out here, Greg.

This is currently NOT working on my testsite, and if you had not announced to publish a switch, I would protest much louder against this kind of paternalism.

[quote=107474:@Greg O’Lone]
You miss the point. this is about preventing someone from making your wab app appear in THEIR site, as if it is part of their page. [/quote]
I have not missed that. But what can be used in a bad way can also be used in a good way, that what it was initially meant for.
So I doubt that you are able to imagine all possible use-cases out there and I strongly oppose general restrictions, exactly because of this reason. Don’t make your power car a super-safe baby buggy.

[quote=107474:@Greg O’Lone] we add feature that we think will benefit the community as a whole.
this one will, as soon as we add a switch to turn it off.[/quote]
I’m waiting for this.

Hmm. Let me try to explain my point: We use iFrames in order to avoid reinstalling the same webapp several times. Like this, we can continue using existing homepages with existing providers and just add pages with iframes. The webapp itself can check if it is at the right place.

In the process of seminar registration, the app will hand over data to a payment provider (saferpay.com) and his payment terminal is displayed in the same iframe we started. Before coming to the point to enter credit-card data, the registrant can decide whether he wants the payment terminal to load in its own window.

The default is to keep the registrant on one website, and not open up another window. With the current WE implementation this is broken.

And this raises more questions: how do you handle cases where the same homepage can have multiple domain names? Or domain names on websites with non-static ip addresses? Are you sure that you are not over-securing and locking down things which are perfectly in order?!

I can reproduce a case where your intended mechanism is not working, all on the exact same domain:

I have a testsite on a homeoffice server. It has a domain name and runs with SSL, but the ip changes. And there I load a test webapp into an iframe. It does NOT load, even though "the item in the frame is coming from the EXACT same domain" (As I mentioned before, it does load when built with an earlier version of Xojo).

Right now I went back to a Xojo 2013r4.1 built webapp, and it works on a testsite (with meaningless contents). See links further down. The same thing does not work when built with Xojo 2014r2

The xojo testapp is here:
https://xojopro.com:9001/

The testsite url is here:
https://www.xojopro.com/tut/iframe-2/

Oliver, to be fair here, you can work around this by removing the header via Session.PrepareSession event handler. But yeah, it’s hard to overstate frustration here.

[quote=107534:@Oliver Osswald]The xojo testapp is here:
https://xojopro.com:9001/

The testsite url is here:
https://www.xojopro.com/tut/iframe-2/[/quote]

…and that’s the issue. Browser same-origin policy must be exactly the same. Not a different subdomain, not a different port, not a different protocol. That’s how the standard is written. The whole point is making sure no one else can route through your site- and if you’re able to change http to https or to a different port, then that’s possible. The right way to do this is to setup your primary server as a reverse proxy back to any support material and then you can lock in SAMEORIGIN even inside of a frame. That’s how major websites handle X servers serving through their main website in a frame. But we understand that’s a lot to ask of our users.

With all that said, we’re rolling it back in r2.1. When we put it back in, it’ll be an easy toggle.

Seriously?! You locked this down in a way that one has to install nginx before one can address a standalone ssl secured webapp!? Really?

That’s what I would call to shoot in one’s own foot.