XSS-beveiliging in populaire Javascript-bibliotheken. Moet ik me nog steeds zorgen maken?

XSS

We live in the age of frameworks, not languages. This implicates that programmers should be able to worry less about many aspects of development, including security. The majority of current backend frameworks implement security modules, which are being tested by external, specialized companies and large societies. Therefore, declining security awareness could be apparent, for example between young programmers, who take more responsibility for the products, especially in terms of freelancing.

One of the common attacks on the client-side of the application is XSS (Cross-Site Scripting). It is performed by injecting runnable client-side scripts into web applications [1] and uses implemented HTML rendering methods or Javascript code evaluators that execute it. XSS is relatively lucrative as many different data may be gathered, including session cookies or user data, and it can install a tracking application such as a keylogger, making it dangerous for both users and business owners. Sometimes, other forms of attack are performed to allow XSS on the page, such as SQL injection.

Voorbeeld

Login form on page renders loginName parameter send within GET request in login name input. Value is not processed neither by server or client-side of the application. By requesting: http://localhost:8080/login?name=<script>alert(document.cookies)</script>
code is being executed and data is exposed

This is an example of a reflected XSS attack, where scripts are being injected through specially prepared URL address submitted to the victim and reflected by the server response. Other known popular forms of attacks are as follows:

• Stored XSS performed with injected data stored on the server-side, usually by forms available in the application. The client application renders code that is stored, for example, in a database.
• DOM XSS performs an XSS attack with no use of the server-side. In the further part of article, we will focus on this form of attack.

Current vulnerabilities in React and Vue libraries

For the current React/Vue versions, two major problems had been detected and not yet officially fixed. The first vulnerability has the same nature for every framework and is related to methods allowing raw HTML rendering within templates: v-html en dangerouslySetInnerHTML, respectively, for Vue and React. Each documentation [2] informs readers that unwise usage may expose users to XSS attack. If no other options allow for resolving the problem, ensure that the data is filtered en escaped. Although they are dangerous, you should not expect those methods to be fixed. Use them at your own risk.

In the first quarter of 2018, a large bug was detected in React, allowing direct code execution by setting the property for tag element. Passing example code within attributes, such as javascript:alert(1) and running a rendered link will execute the code. This issue [4] is still open and no fix has been prepared and merged, so make sure your code is safe. Examples proposed in official discussion suggest some ways to overcome this problem.

If updating to the latest versions is not possible, make sure that old issues don’t cause problems for you by ensuring that your code is not exposed for:

• child knooppunt injection – React, usage of React.createElement [5]
• server-side rendering – React/Vue [6]
• CSS injection [8]

It is still about Javascript. It is still about front-end

Do not forget that in addition to frameworks or libraries themselves, Javascript as a language has some dangerous functions, which must be avoided or used with caution. They are generally related to DOM manipulation or script execution. eval() represents flagship functions of this kind and is extremely dangerous because it executes given stringified code directly [9]. Also,  take a better look at your code when finding one of these functions:

• document.write
• document.writeln
• (element).innerHTML
• (element).outerHTML
• (element).insertAdjacentHTML

Here, using linters with proper rules set may be helpful in finding such vulnerable points. There are also plenty of open or commercial code analyzers that may help you detect security gaps in developed code.

No matter which library/framework is chosen, we still have to remember basic principles related to front-end development. First, always ensure that the external code you inject comes from a trusted source. Controle your dependencies, and choose them wisely. Some can contain serious vulnerabilities, exposing your code even if everything is fine with the code itself. You can read more about dependencies security here:

https://thecodest.co/blog/security-in-javascript-packages/

So… should you still be concerned?

Yes  – and I strongly encourage everyone to never trust external libraries or yourself in terms of security. No matter how safe you expect your software to be, always make an effort to test it as much as possible in terms of common attack forms [10].

1. https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml
2. https://vuejs.org/v2/guide/syntax.html#Raw-HTML
3. https://github.com/facebook/react/issues/12441
4. http://danlec.com/blog/xss-via-a-spoofed-react-element
5. https://medium.com/node-security/the-most-common-xss-vulnerability-in-react-js-applications-2bdffbcc1fa0
6. https://github.com/dotboris/vuejs-serverside-template-xss
7. https://frontarm.com/james-k-nelson/how-can-i-use-css-in-js-securely/
8. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval#Do_not_ever_use_eval!

Lees meer:

5 fouten die je moet vermijden bij het onderhouden van een project in PHP

PHP Ontwikkeling. Symfony Console Component - Tips & Trucs

Waarom hebben we Symfony Polyfill nodig (... en waarom niet)?