Running with Scissors: The Dangers of Cutting and Pasting Sample Code

May 02, 2018 | Simon Zuckerbraun

Developers tend to be busy people. As such, they tend to take shortcuts at various times – especially when they are attempting to backport a new language feature. I’ve already mentioned the ubiquity of JavaScript, and with its rise in popularity came JavaScript Object Notation (JSON). Although JSON is derived from JavaScript, it is supported either natively or through libraries in most popular programming languages. JSON eventually eclipsed XML in popularity as it allows you to do nearly the same things just in fewer lines of code. In today’s world, JSON is nearly the de-facto standard for data exchanges between mobile and web systems and back-end web services.

To produce or consume JSON data in JavaScript, you use the built-in JSON object that has been added to the JavaScript language standard. At times, however, developers need their code to also run on older web browsers (most notably, Internet Explorer (IE) 6 and 7) which do not offer the intrinsic JSON object. In a situation such as this, you use a polyfill – a plugin or other piece of code that emulates functionality that would otherwise be provided natively. A polyfill flattens the API landscape so that a single version of the code will work regardless of whether the needed API is provided natively or not.

As a developer, you are a busy person and have no time for writing such a polyfill. Fear not! The Mozilla website provides this example for everyone to use:

Partial screenshot of the now archived polyfill example

While this code example provides the needed functionality to the otherwise unsupported browsers, it also introduces a security vulnerability. The specific flaw exists due to the use of eval on line 3, which can produce unwanted script execution. In cases where an attacker is in a position to send phony “JSON” data that will arrive and be parsed by this polyfill, the attacker can inject arbitrary script, better known as Cross Site Scripting (XSS). An attacker can leverage this vulnerability to disclose information or perform other actions under the context of the victim domain.

The dangerous code was removed in revision 31806 on March 30, 2012 but was subsequently added back in revision 31810 on April 12 of that same year. After we disclosed this problem to Mozilla, this sample was removed again with revision 1370011 on March 28, 2018. Hopefully, this time it stays gone. That final revision includes the note, “Remove polyfill for JSON - only needed for IE < 8, and they often have security vulnerabilities.” An accurate statement if ever there was one.

JSON isn’t natively supported in IE versions prior to IE8, and those versions of IE are no longer supported by Microsoft. While these old, unsupported browsers do still see some usage, developers should not be coding for them. Let’s face it, if you’re running IE6, a polyfill for a JSON object should be pretty low on your list of concerns. This is also a reminder that when you cut-and-paste code from the internet – even from reputable sites – you inherit any vulnerabilities that may exist in that code. Always review it carefully to ensure you understand the security risk when you accept code from online resources.

You can find me on Twitter at @HexKitchen, and follow the team for the latest in exploit techniques and security patches.