There's been a strong push in the P2PU community to allow users to use arbitrary <iframe/> elements in groups


Benefits (Why are we talking about this?)

• Flexibility of embedding anything into p2pu.
• There are great tools out there to support social learning. We will never build all those tools into P2PU, but we encourage everyone to make full use of them - and this is a way to make that easier.
• Some of our partners have existing tools that would let us expand the functionality available to our users. Embedding these tools into our site will make the experience more seamless.

But there are lots of security risks (see below for a full list). We want to allow more people to add great features.


Suggested Solution

• Don't let people embed arbitrary JavaScript. Offer a workaround for iframes, some trusted users can embed.
• iFrames pass information back and forth. We will be sending messages to another website and they will send us messages. (We need to API)
• Create a trusted account for people we trust to do this
• This would require development work to standardize the communication between P2PU and an embedded iframe.
• We plan to build this step by step, taking into account the use-cases that have most benefit to our users, and depending on developiment resources.
• Here is how you can get involved / help us / get started

Security Issues

1) Phishing

If any registered user can inject content in a page using an iframe, they can pretty effectively phish a website visitor. Imagine the  attacker creates a page with an iframe that points to http://evil.example.com/mypage.html  (a URL that they control). The iframe displays content with a form requesting personally identifiable information, or even worse, credit card information. An unwitting user may fill out the form thinking they were submitting the information to P2PU (an entity they trust) when in fact it is going to http://evil.example.com/mypage.html.

2) URL Redirection

This can range from annoying to dangerous as it could also be used as part of a phishing scam. Imagine now that http://evil.example.com/mypage.html contains the following snippet of Javascript:

<script type="text/javascript">
    parent.window.location = 'http://p2puu.org/en-US/course-home';
</script>

Where p2puu.org is a domain controlled by the attacker. The page could be dressed to look exactly like a page on p2pu.org  and again, the user can be phished for information, thinking they were  providing it to P2PU (e.g. imagine some faked campaign advertising benefits of paid memberships to P2PU).

The annoying case is simply redirecting them to some other site for either a prank (e.g. a porn site) or some ill fated attempt at generating ad revenue. Oh, they could also display ads on our site :) 

3) Using an iFrame to exploit existing vulnerabilities

Certain sites should never be loaded in an iframe, as an attacker could use clickjacking to trick a user into performing some dangerous operation  (usually some kind of user authorization or unwitting posting of  content). Popular examples are Facebook and Twitter worms. To get around  this, most sites send X-Frame-Options headers that prevent them from  being loaded in iframes in modern browsers or  they use frame busting javascript. Unfortunately not everyone gets this  right... case in point, Adobe still have a vulnerability in Flash that  will allow an attacker to activate a website visitors if they can  clickjack the user. Check it out:

http://www.feross.org/webcam-spy/
 
4) Cross Frame Scripting

There are a number  of data theft scenarios, especially on older browsers. I believe P2PU  uses HttpOnly cookies, but some older browsers could still be  compromised. More details here:

https://www.owasp.org/index.php/Cross_Frame_Scripting

Notice that a lot of the attack scenarios described in that link rely on an attacker exploiting an XSS vulnerability to inject an iframe on a compromised site... you'd basically be allowing registered users to skip  that step.

5) Message sending between iframe and parent\

An iframe on a page could  send messages to the parent. It is important to make sure to properly  filter on event.origin as documented at https://developer.mozilla.org/en/DOM/window.postMessage

6) Third Party Tracking

A user visiting a page that contains an iFrame will automatically send a request to the domain specified within the iFrame. This request to the third party domain will contain the parent page within the referrer header and also any established cookies that the user has with the third  party domain. As a result, a third party domain can track a users activity across any website where the iFrame has been placed.