Snap! version 6.9 and the JavaScript Function block

Announcements
1

So, about a week ago, we had our first serious malware attack using users' ability to write JavaScript code in the Snap! environment to present users with a fake version of the snap.berkeley.edu web site, with the goal both of collecting passwords and of potentially infecting users' computers.

We've known all along that the JS Function block was a security hole, but our users are generally well behaved and we're not a bank or anything, so I'm pretty sure this was the first real attack (as opposed to benign practical jokes).

I'm not 100% sure about this, but I think it's unlikely that this program was around long enough to do any significant damage, outside of the perpetrator's school. (That aspect of things is under investigation and not my department.)

But as a result, we now feel a need to close this security hole quickly. Version 6.9 of Snap! disables the JS Function block by default.

Certain Snap! libraries depend on JS Function. We have a plan to solve that problem, but it might be a couple of weeks before it's fully live.

Projects that use JS Function can only be run in the Snap! Editor window (not on the web site, nor in presentation mode), by first enabling JS Function in the settings menu. This setting must be enabled in every session; it can't be stored with a project.

Here's what you'll see when you run a script containing a JS Function:
gbdaecedlegdlajj

And here's how to enable JSF:
lgmmpbnjnbhcldia

Sorry for this brouhaha.

2

How bad is that the human nature makes running security forces and security measures the biggest effort in almost all human activities.

3

Hm. Kind of makes useless what I've been working on for the last 5 months, but I guess it's the right thing to do. Will 6.9 do anything else?

4

image
image754×469 22 KB

6

I knew that when I first knew that Snap! is written in JS.I can see "Process.prototype.enableJS" even in old versions.

7

It should be quite easy to whitelist a hash of all JS functions from built-in libraries.

Second, you know that it's a "one way" solution. Once enabled only page reload can really block JS.

For school teacher it will be easier to use separate URL of the Snap_no_JS! and Snap_with_JS! to block unwanted traffic at firewall level.

8

Are there any risks for sessions where no one is logged in? If there are none, could JS be disabled when one logs in?

9

Or at least a URL parameter that disables logging in but keeps JS? I'm thinking of making it feasible to demo a JS-enhanced project without risk.

11

Hi Ken, we're exploring various options, especially with projects such as yours in mind, because we want them to keep working as before with as little changes as possible, and as much freedom to extend them. Please expect only a short time of this current hassle.

13

So because of a website that copied Snap! and stole passwords we can't use JS anymore? Isn't there a way to fix the security in the JS block?

14

you can use JSF! You only need to enable it in the settings menu.

16

What about all of my projects that had JS blocks in them to function and most of my Custom Blocks do not work nor all of my HTML stuff. I do not fully understand why JS is disabled is it because someone could script it so you get their password.

17

You can edit, run, and share all your projects and your ideas using JS, we did not take the JSF out of Snap at all, nor did we limit what it can do. We are only disabling JS extensions when you first start Snap for a session, because we want to user of your project to understand that by allowing it to run arbitrary scripts they are exposing themselves to security risks, starting with pranks all the way to serious fraud and phishing. I think it's good to be honest with the community to let them know that, don't you?

18

Yes, I think this is a good idea. in snap, you should mostly program in snap, and in a javascript text editor, mostly javascript. even if you can use javascript in snap, it's not the main point of it.

19

What should happen after the first time the user receives this warning and enables JS? Could it change the policy for that user in future sessions?

20

Host the projects on a different domain. That's what most online HTML/CSS/JS playgrounds do to prevent session hijacking. Also add CSRF protection to the API

What exactly do you mean by "infected?"

21

Is there any risk of being infected currently?

22

we'll have a mechanism to publish trusted extensions that won't require the user to manually enable them.

23

Yes, but what if you want to do things that Snap! can't do directly (e.g. DOM manipulation)?

24

You can use the JSF block, like before, you just have to ask the user for permission.