Apex Code Development You need to sign in to do that
Don't have an account?
jhart Critical bug in IE: scripting in Visualforce broken unless subdomain added to Trusted Sites list
We use Visualforce pages both at the top-level (their own page) and embedded as <page> elements in standard objects' page layouts.
These pages no longer work in IE if their Visualforce subdomain has been added to IE's "Trusted Sites" list. We think the breakage occurred last night, but it's hard to say because we don't do browser testing every day just to see if something broke last night. Maybe we should.
However, for top-level pages, no such message is displayed to the end-user. Instead, the page loads and displays just fine, but the discerning eye notices that a javascript error is thrown on page load. Clicking on IE's little "javascript error" icon on the bottom left brings up this dialog:
Viewing source, we see that line 5 is the UserContext.initialize call:
This bug has serious downstream consequences, because actionFunction and actionSupport methods are broken. If I click on link that calls an actionFunction, my UI just hangs in its "loading/throbber" state but I can again click that little javascript error icon on the bottom left and see this error:
Only by adding my subdomain (i.na5.visual.force.com) to IE's "Trusted Sites" list fixes these problem. However, for the top-level pages, the user has no way of knowing to do this. Instead, they just think that our app is broken.
As best as my testing recalls, all of this worked fine last week.
It all still works fine in Firefox 3 (of course, per this post, Salesforce does not officialy support Firefox 3)
These pages no longer work in IE if their Visualforce subdomain has been added to IE's "Trusted Sites" list. We think the breakage occurred last night, but it's hard to say because we don't do browser testing every day just to see if something broke last night. Maybe we should.
However, for top-level pages, no such message is displayed to the end-user. Instead, the page loads and displays just fine, but the discerning eye notices that a javascript error is thrown on page load. Clicking on IE's little "javascript error" icon on the bottom left brings up this dialog:
Viewing source, we see that line 5 is the UserContext.initialize call:
Code:
4 <script type="text/javascript">window.sfdcPage = new GenericSfdcPage(); 5 UserContext.initialize(....
Only by adding my subdomain (i.na5.visual.force.com) to IE's "Trusted Sites" list fixes these problem. However, for the top-level pages, the user has no way of knowing to do this. Instead, they just think that our app is broken.
As best as my testing recalls, all of this worked fine last week.
It all still works fine in Firefox 3 (of course, per this post, Salesforce does not officialy support Firefox 3)
We're trying to decide if we should be delaying fresh installs until this issue is resolved.
Can you shed a light on the expected behavior?
My guess is:
a. Top-level visualforce pages will "just work"
b. Inline visualforce pages will require IE users to "always enable session cookies" or to add the package subdomain (or "https://*.force.com") to their Trusted Sites list.
thanks,
john
This bug actually strikes other browsers, too.
If I have my browser set to reject 3rd party cookies (which I do), then hyperlinks in my embedded <page> elements lead to infinite loops.
See this discussion board post.
My colleague who discovered the issue has never touched his security settings - he doesn't even know where they are. But the bug happens to him, because he has "automatic updates" turned on and was fully patched.
Salesforce's QA did not have fully patched IE, so did not discover this bug.
Given IE's market share, plus having "automatic updates" turned on by default in Windows, I suspect this bug effects at least 35% of Salesforce's customers.
One of my colleagues was also unable to replicate until he enabled automatic updates and got his IE up to a "fully patched" state. Your testing refers to "clean installs" - are they also fully patched via automatic updates?
I'd be happy to learn that this only strikes me and my colleagues, as opposed to all of our clients =).
But I'm not sure that's the case.
Also related to 3rd party cookies / trusted sites is this discussion thread.
I just posted on that thread a link to a video showing Firefox 3 going into an infinite loop if it's not set to accept 3rd party cookies (which I, at least, prefer to reject). Chrome and IE have a similar behavior if configured similarly.
I think there's a larger issue of how the new subdomain handling, which prevents the theoretical attack vector of client-side javascript from one app snooping on another, was implemented without P3P headers and thus has led to a few hard-to-track-down bugs relating to browsers and how they handle 3rd party cookies.
It seems like partner apps are getting a rough ride from this subdomain handling, as our customers will call and complain to *us* instead of *you* when our apps don't work.
Any prospect of getting P3P headers set? That should help with IE, at least, if not the others...
A comprehensive guide to partners about the subdomains, with "this are the problems that might occur, and these are the browser settings that avoid them" would be very helpful. We shouldn't have to generate this ourselves.
Message Edited by jhart on 11-12-2008 04:31 PM
Message Edited by jhart on 11-12-2008 04:32 PM
We are looking into deploying P3P. But whilst it is technically easy, there are a number of legal issues. P3P is a "good faith" protocol with different ramifications across the globe, depending on the internet privacy laws of the user's country. We'll keep you posted.
P3P headers do not really solve the problem. With IE default privacy settings, if a P3P header is set, then the browser will accept a third party cookie. So we'd like to set such a header, if the legal issues can be resolved, to simplify usage for default IE browser settings.
But with both IE and FF, if you have explicitly turned off 3rd party cookies, the P3P header does not help any.
(FF3 seems to have no equivalent of the default IE "accept 3rd party cookies for pages that have a P3P header").
See this video from this post about a related bug.
Similar issues do strike FFox & Chrome if they are set to ignore 3rd party cookies.
See this post for a particularly nasty example (there's a video there too).
I've been pushing on Salesforce for a better resolution to all of these issues, but so far the primary response is "this only happens if you customize your IE settings or set them to 'high', so don't do that."
If anyone is running into these issues, please chime in. I don't think that anyone (including salesforce) knows how widespread this issue is / isn't, so the more info the better.
Kleb... did you get any response yet on your iframe cross-browser problems? I had some slick resizing functions set up for a homepage component that displays a vf page... worked in sandbox (where the domains are the same... perhaps until i do a refresh)... upon moving it to production, i got a nice surprise.
I liked the /apex/mypagename URL scheme... so far I have not dug up any good reasoning behind the seperate domain...
buller? buller?
The move to separate domains has one very specific purpose: leverage the browser security model (same domain policy) to protect our customers and the salesforce.com service from cross site scripting and cross site request forgery attacks.
Moving to the serving pages from separate domains is a critical component of our ongoing commitment to insure the highest level of security and availability for everyone.
I understand what salesforce.com was trying to do here and security needs to
be taken seriously but in this particular case I believe that
salesforce.com was wrong.
The ASP model is successful because customers do not have to deal with an IT
burden and can be priced linearly with users added. Because of that
salesforce.com has attracted customers of all shapes and sizes. We work
with Fortune 500 all the way down to grandmothers working at non-profits,
even a singer managing his fans.
This means that the technical knowledge of many of salesforce.com customers
is near zero and no IT resource is either available or tasked with helping
maintain Salesforce. This leads to a very practical problem.
Practically speaking, no one knows what is going on when this error occurs
and they either uninstall the app or call in for support. I have seen cases
where customers have struggled with this for weeks before having an
incidental conversation with us that leads to the simple but hidden fix.
This is a crippling problem from both a usability standpoint and also a
support cost standpoint. Also, I have to say, convincing a non-technical
person to add a domain to a trusted site list is not always received well.
Also, isn't this a bandaid over the bigger issue?. If an app wants to harm
a customer, there are far easier ways than cross-frame scripting ... once an
app is installed, it has access to all kinds of objects and data, and this
is a much bigger attack risk than installing a visualforce page, getting the
customer to embed it in their page layout, and then cross-frame scripting to
pull data out of the surrounding page. I feel like we have made the
AppExchange much harder to use with little improvement in security.
If the intent here is to reduce the risk of a partner doing something really
bad, then Salesforce needs to do line-by-line reviews of all partner code.
Preventing partner apps from doing cross-frame scripting attacks does not
solve any problem. It just switches the problem to another, much easier
attack vector that a malicious actor would have chosen anyway.
Finally, the burden of security issues should be born by salesforce.com and
the partner when at all possible - not by the customer.
We shouldn't need to have 1.5 million people tweaking their security
settings to make the AppExchange work.
I had embedded a Visualforce page inside a homepage component... and even after i stripped any cross-domain scripting away... many users were simply unable to load the page... it would freeze up in certain versions of IE. So, the problem is even deeper than the "clever resizing" functions i mentioned before... iframe displaying a different domain causes a variety of problems.
I agree with AJK-1972, as a developer, If i were asked to I could come up with many easier ways to create malicious apps that would not include cross-domain scripting.
It was a sad and frustrating moment when I had to announce that the go-live of the new homepage component would be delayed a week or two as I would have to transition from Visualforce to an S-Control.