Proposal for New Security Policy

[chunter]

Canvas makes teaching and learning easier by being open and adaptable. Openness is also a core value at Instructure. When we learn about potential security concerns, we want to keep you aware of what Instructure is doing to keep you safe.

Most content on the Internet uses powerful front-end code to render objects on web pages, such as videos, files, and interactive content referred to generically as dynamic content. We have allowed teachers to implement this functionality in Canvas to create engaging digital learning experiences, primarily through the Rich Content Editor. Many courses served on Canvas teach students how to create this type of content so we have also allowed Canvas to render some front-end code created by students as part of the learning process.

We’ve always been aware that allowing Canvas to render user-created code comes with a risk, and we’ve actively managed a code whitelist to help moderate supported content. However, the world is always changing so we regularly revisit this approach to ensure the guard rails we have put in place are appropriate for the level of risk. The goal is to provide access to powerful education technologies in a safe and effective way.

Our Product, Engineering, and Security teams met recently and discussed risks and user needs related to rendering user-generated dynamic content in Canvas. Our conclusion is that it’s time to make adjustments to our approach for allowing this content—specifically JavaScript.

We will implement the following changes:

• By default, if you upload an html file to the "Files" section in Canvas, we will not allow any javascript in that file to be run
• If desired, Canvas Admins can allow the use of JavaScript by enabling a feature option at the account, sub-account, or course level. This feature option allows admins to manage the use of dynamic content for their institution in a granular way. When enabling the use of JavaScript, Canvas will display a warning with the associated risks and require the admin to verify the feature option change.

This proposal would have no impact on:

1) JavaScript uploaded by admins to the Theme Editor.

2) IFrames embedded into a Canvas page that call an external source (for example, Twitter tweets or YouTube videos).

3) Our current practice to not allow inline scripting within the rich content editor.

We believe this approach will allow Canvas administrators to balance security- and privacy-related risk that meets the needs of their specific institution. Our preferred approach is to make this change as part of our standard deployment process—first to beta where it can be evaluated by admins, and then to production.

We welcome any feedback you may have about this upcoming functionality adjustment. Please share your thoughts by Sunday, February 11, so it can be considered as part of our plan.

**Now closed for feedback**

[James]

Thanks for the clarifications, Deactivated user

[laurakgibbs]

I will confess immediately to knowing nothing about javascript security, but I wanted to clarify what I mean by whitelisting Twitter, Flicker, Pinterest: they HOST the script, you just call it. So it is not like whitelisting a link to Twitter exactly, but it is indeed whitelisting scripts hosted on the Twitter.com domain.

The code that Twitter provides looks like this:

Widget for a Twitter user feed:

<a class="twitter-timeline" href="https://twitter.com/OUDaily?ref_src=twsrc%5Etfw">Tweets by OUDaily</a>

<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

Widget for a Twitter hashtag search:

<a class="twitter-timeline" data-dnt="true" href="https://twitter.com/hashtag/FolkloreThursday" data-widget-id="822165780791984129">#FolkloreThursday Tweets</a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+"://platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>

So also for widgets offered by Flickr and Pinterest.

[James]

Thanks for the clarification. With Chris' clarifications, that's not being addressed with policy change.

You're not losing anything because that functionality is not there now. I may be misreading the thread (wouldn't be the first time today), but it seemed like they're trying to move feature requests off to other discussions. The Twitter hashtag has actual code inside the script element, though, so it's a little different from the first one.

[laurakgibbs]

Right now they both work fine as Files: easy peasy!

Here's the OUDaily user:

File: OU Daily 

Here's the #FolkloreThursday hashtag:

File: FolkloreThursday

[a1002160]

I would NOT want students to EVER be able to add JS to a page

Canvas allows this at the moment - have a file submission assignment and make the mistake of using speedgrader. I tried a couple of experiments and it executes the code, clicks on links I cannot see, etc. quite happily.

Preventing cross site scripting attacks is very difficult and requires a mechanism to prevent anything you do not trust being executed by your users' browsers. Iframes only help a bit if the content is from another site but, javascript served up by canvas in an iframe will still look trusted to your browser. HTML5 has a sandbox option to mitigate the problem for javascript but I did not see the relevant tags on the iframe produced by speedgrader.

This is the test file submitted to an assignment (I removed the actual URL used). After the alert pops up, the browser acts as if the user had clicked on the link but the link is not visible to the user.

<a href="https://... some other site ..." target="_blank" id="hello"></a>

<script>

document.getElementById('hello').click() ;

alert('hello');

</script>

[ProfessorBeyrer]

Thank you  @James ‌ for bringing in the student perspective and their likely assumption that anything on a course Canvas page is trustworthy. It's a good thing to keep in mind what they're thinking when they view our course pages and that the security risks we take can affect not only our courses but our student visitors to those courses.

[laurakgibbs]

At the same time, I would hasten to add that if most of the time students are going to be spending time on the real Internet, it is just as important to be teaching them about being safe online at all times.

And just what safety means is very different between K-12 teaching environments and college teaching environments. I think it is great that Canvas is being deployed across that whole range of environments, but there are some substantial differences in terms of what we can and should expect from college students compared to students in high school and, even more dramatically, students in K-8.

I actually don't want students to trust me to keep them safe, or to trust Canvas to keep them safe; I want them to be relying on their own knowledge, skills, experience, and awareness to appreciate what they are doing when they go online.

I often get emails from K-12 teachers who tell me that my Latin blog is blocked at their school because it is at blogspot.com, for example. I know it is not uncommon for K-12 institutions to try to police the Internet in a way that is very different from college. Keeping K-12 students safe might mean blocking the Internet (I'll let people in K-12 make those decisions!), but that would NOT be an appropriate way to keep college students safe.

Again, I am not say that is an exact analogy to the javascript security issue here, but I don't want "students must be protected at all costs" to drive this discussion as the one and only goal. Protecting students is definitely important -- but even the definition of what it means to protect students and from what is going to vary greatly from a six-year-old in first grade and the students I am teaching who are about to go join the world of work and no doubt use the real Internet in their professional lives. To me, keeping them safe means educating my students about how to use the Internet as well-informed and proactive digital citizens. 

[stevenwilliams]

Hi Deactivated user‌, thanks for sharing this update and continuing to engage in the discussion here.

When Instructure is ready to release these changes, we would request that customers be given longer than the usual two-week cycle between a beta and production release. We have courses which use Javascript for a wide range of purposes, and two weeks might not be enough time for all users to review and update templates and other course elements. 

[Renee_Carney]

 @stevenwilliams 

Thank you for this note!  We absolutely know that changes like this impact  some of our users more than others.  We do try hard to weigh the risk with the benefit of a timeline.  When it comes to security, we do hope it is understandable to error a little on the side of getting things secure rather than waiting too long.  We will always do our best to give adequate warning.

[joseph_allen]

This change is pretty consistent with other types of security you see regarding javascript (usually can't email it) and we (Howard County Public Schools) are in favor of moving forward providing there is significant testing just to make sure it works as intended and doesn't impact or break something else.  We use Design Tools and it doesn't sound like there would be any impact, but again, we'd want to thoroughly test it.   @kenneth_larsen  - any thoughts?

[kenneth_larsen]

I have been and will continue to follow along as things progress, but as long as the statement that "This proposal would have no impact on ... JavaScript uploaded by admins to the Theme Editor" remains true then I am not worried about it having an adverse impact on Design Tools.

[cwhermsen]

IT security is incredibly important and becoming more so with each day. So I am happy with this proposal, as it allows admins to block Javascript from running inside courses, except where explicitly allowed.

[michellez]

I want to echo what  @wwolf  and  @cwhermsen ‌ stated - this is incredibly important! Great proposal Deactivated user‌!

[mvandevelde]

I’m always for improving security and empowering administrators. I generally can’t see a reason for a student being able to add executable JS to a page ever, even in a coding class.

I’d want to be sure that the administrator can apply this permission to both the ‘course role’ and ‘account role’ areas. 

I’d also like to see a separation of the permissions between JavaScript in the Rich Content Editor and in the course hosted html files.  This would allow teachers to upload small interactive html pages that rely on JS in some way to still work, but prevent students from posting JS in the RCE.

So my suggestion would create two options in the course and account role permissions area:   

1. Allow JS in Pages (RCE)
2. Allow JS in html (files)

Applying this to roles means that if another user with a role that doesn’t have the permission activated, edits the page or html file, it will be cleaned of any JS that may have been applied with someone who did have the permission.  

[chunter]

Thank you all for the great feedback and discussion! This input will be helpful as we work to finalize our plan.  I'm closing this post for comment but will communicate our next steps in a separate, future post. 

Chris

[scottdennis]

Hi All,

If you are interested in security and privacy policies at Instructure, you might want to check out the blog post Melissa Loble posted today:

https://www.instructure.com/canvas/blog/data-privacy-our-current-and-future-commitment 

Thanks