Eliminate the need to challenge the consumer when route protected about xfc HOT 7 CLOSED

If the route to mount a content provider is protected by some other means, such as OAuth header validation, there is no need to challenge the consumer for a secret.

Technically all our apps are protected by other means... The question is once the content has been loaded, if I navigate away and go to a malicious site, are they able to to embed this app? How are you preventing that from happening?

from xfc.

If the initial page loads and authorizes itself to be displayed, how would the existing consumer challenge eliminate the ability to navigate to other page within that iFramed window?

from xfc.

Talked through with @slor on idea as well. If the challenge is not provided that any consumer would be able to embed the content of the document served by the provider; however, in this case the document is not even served if the cloud oauth validation (server side) does not succeed. So for a content provider to ignore the challenge could open themselves up to click-jacking only if they do not protect them in some other secure fashion. Maybe that was more of the question being asked.

from xfc.

@whitehatguy, thinking through this security idea, wanted to get your thoughts to if we're opening any holes?

from xfc.

To add a bit more information, what we have discovered is that the communications across the iframe are delayed and sporadic. I've seen the challengeConsumer take anywheres from ~100 ms to upwards of 5+ seconds. Only speculating but possible because of the event loop restrictions within the client consumer. Looking for ways to improve the performance.

from xfc.

FWIW this.authorizeConsumer() is a public method you can call yourself. Though I recommend against it cause I'm not confident you're preventing any UI redress attacks.

from xfc.

Fixed in #12

from xfc.