View source for Toolbox/Javascript Security

==The Risks==

Unrestricted javascript has many security problems:

* Ability to read security tokens and exfiltrate them to a hacker.  In other words, unrestricted javascript can 'steal your log in'.
* Ability to 'act as the editor' without their consent.
* Ability to re-write the mediawiki user interface, as vandalism, as advertising, for tracking users, for misinformation, censorship, DDOS attacks, bitcoin-mining, invasion of privacy.

Scratch and SNAP appear to be able to offer a programming language for animations that is sufficiently safe, and moreover is suitable for children.   Programs are written and shared, and it is expected that people will run and adapt each others code.  

In the context of children, the Scratch and SNAP environment designers must additionally be alert to inappropriate content and also guard against bad actors creating private online communication channels to minors.  

Scratch and SNAP run client side, in the browser.  Blocks in those languages 'wrap javascript'.  Blocks expose a packaged subset of the javscript language.  Each block is effectively a call to an approved javascript function.

{{Note|'''Summary:'''

* Scratch and SNAP DO operate safely.
* &lt;iframe&gt;s can insulate diagram javascript from the rest of the page
* Code that might allow 'sandbox escape' is easy to identify, easy to analyse and only in a small part of the code.
* Visual design (of the frame around a diagram) is needed to ensure that diagrams can't fake it as other user interface elements.
* New vandalism risks can be addressed by extending existing template policy to diagram subroutines, and by ethos of 'No Easter Eggs'.
* External communication outside WMF servers should be barred for diagram scripts, and internal communications, e.g. to fetch more data, rate-limited.
* Long complex scripts are suspicious, and rarely needed (they can be broken down into approved subroutines).  Complex, hence suspicious, scripts can be automatically detected and flagged for admin attention.
}}


==IFrames==
One approach to limiting the capabilities of a diagram creating language in Wikimedia is to host the diagrams in iframes, served from a diagrams server.  This provides a clean separation between the diagram javascript code and the native Wikimedia javascript and HTML.  The diagram javascript is confined to the iframe.  

The only part of the user interface that can then be 'rewritten' by malicious javascript is within the iframe.  The diagram is in a kind of sandboxed. 

Care must still be taken in what subset of javascript is provided 'within the iframe'. For example a primitive that allowed a pop up from within the iframe would be dangerous.  A standard ploy might be to pop up a small panel asking the user to input their password.



==Defensive Coding==
The same goal of excluding global scope from the diagram's javascript can be achieved by alternative technical measures. 

* The eval() function which allows creation of arbitrary javascript code must not be exposed.  
* Any 'writing to the dom', as with the .innerHTML property must be 'cleaned', since it would otherwise allow code to be injected. 

The high level primitives available must operate on the diagram and not bridge to global scope.  Variables in the block based language, for example, are properties of the diagram, not properties 'at global scope'.

These technical measures are relatively easy to verify.  There are many well known hacking techniques designed to thwart code that 'cleans' text of potentially dangerous content.  The part of the code that needs to be carefully checked for these dangers is very small - for example the code that provides the text in the large tooltips.  The security risk is mostly from future revisions that invalidate the analysis. For example, someone adds more flexibility to the tooltips in code that comes after the 'cleaning', or adds a new and convenient block type, that uses eval() or .innerHTML.


==Faking UI==
Apple prohibit programming apps on their iPhones/iPads unless the programs running in the programming app use less than 80% of the screen area and have a clear boundary or frame indicating that a script is running in a software development environment.  They do this to prevent a program passing itself off as some other program, e.g. to capture passwords.

For Wikipedia the diagrams would need to be similarly restricted.  A standard 'frame' is needed to indicate an interactive diagram.

Future revisions risk eroding that safeguard.  It may become tempting to re-use the diagram interface for user interface in Wikimedia, so that later extensions to the current diagram code expose user parameters and preferences.  Part of security planning then is a style guide to prevent erosion of the distinction in look between diagrams and built-in interface features.


==Vandalism==
The existing template mechanism of mediwiki already creates a vandalism risk.  Modification of one popular template can affect a very large number of pages.  This risk is handled by protecting popular templates.

Interactive diagrams will create an additional risk.  The vandalism may not be obvious at time of review.  For example vandalism could trigger on a particular day, e.g. to coincide with an IPO.

To counter that, long complex scripts will be discouraged.  The templates/subroutines mechanism will be used more, so as to keep code short, clear and understandable.  This will make it easier to review code, with the side benefit of lowering the barrier to using interactive features.

There will also need to be an ethos of 'No Easter Eggs' in diagrams.  That is, no hidden features that only show in special circumstances.  

Although Scratch and SNAP offer date and time of day, the diagram language shouldn't.  This rules out some nice diagrams, such as a real-time sundial, moon phase or time zones map.  Perhaps if 'blessed by an admin' a diagram could be allowed access to the time functions.  I think it's wiser to not do so, and table it as a possible future enhancement.


==External Communication==
URLs in interactive diagrams should be Wikimedia controlled, otherwise:
a) Scripts can bring in content that is not reviewed/checkable.
b) Scripts can exfiltrate information, e.g. by accessing custom URLs.
c) Scripts become a vehicle for ad fraud.
d) DDOS atacks against external sites are likely.

With communication only within Wikipedia, there is a still a DDOS risk.  We could put an upper limit of the rate of requests for data from a page, so as to reduce the dangers of accidentally or deliberately DDOSing Wikipedia.  This can be implemented in the javascript.

There will be similar problems to those OpenStreetMaps experiences.  Like maps, some diagrams may be backed by a lot of data.  These problems can be addressed in the same ways OpenStreetMaps does - by limiting preloading of data and caching 'lower resolution' data. 


==Bitcoin Mining==
Restricting external communications goes a long way towards preventing bad actors using Wikipedia viewers' processing power for their own purposes.  Even so, a bitcoin mining script could be invisible most of the time, and show a message such as 'One bitcoin mined!  Scan this QR code to claim your half of $9,469 USD Today!', if it found a bitcoin.

Google monitor their servers to look for characteristics of bitcoin mining on their free introductory offer servers.   Bitcoin mining looks likely to be a minor problem, and probably suspicious scripts can be easily automatically flagged for closer inspection by an admin.