Author | Tina, Wan Jia
Whether it's a front-end or a back-end, as long as there's code, vulnerabilities can occur.
Recently, there are two screenshots of Vue security issues widely spread in the industry, the screenshot content shows that there are currently a number of companies in the software development process using Vue.js and SonarQube situation, suspected hackers using Vue .js and SonarQube vulnerabilities to implement network attack detection on mainland government agencies and important enterprises and institutions.
Vue is a popular JavaScript front-end framework that was released in 2014 as a personal project of indie open source developer Yu Yuxi. Today, Vue has become one of the most popular open source projects on GitHub. Meanwhile, in the JavaScript framework, Vue has earned more stars than React and higher than Backbone.js, Angular 2, jQuery, and other projects.
Will the front-end framework have security vulnerabilities?
Although the source of the screenshot is unknown, due to the large number of Vue users, many developers have sent screenshots to You Yuxi.
On January 25, You Yuxi made a public response on Zhihu: https://zhuanlan.zhihu.com/p/461720764
He said that Vue is very serious about security issues, and they have not received vulnerability reports recently, and there are currently no vulnerabilities in the public CVE database that target Vue .js itself. Vue is an open source project and a front-end project published as JavaScript source code, and each line of code is publicly audited by any security audit. Vue 2 has been around for more than 5 years and is widely used in the global industry, during which time no true security vulnerability has ever been discovered.
At the same time, he explained, "Hacker infiltration may exploit vulnerabilities in the front-end framework used by the attacker, but hackers will not use the front-end framework as a tool for their infiltration, because the front-end framework does not have this function at all." ”
As the front-end is the code executed in the user's browser, the vulnerability type is usually XSS (Cross-Site Scripting), XSS Chinese called cross-site scripting attack, which refers to the upload of malicious information, so that the script contained in the information is accidentally rendered, so that it can be executed when other users log in and steal other users' data. XSS can come in many forms, and can happen on pages rendered purely on the server, not necessarily involving front-end frameworks.
We've also received some so-called "vulnerability" reports in private in the past, but these reports are almost all based on the assumption that arbitrary HTML content uploaded by users is used as vue templates or v-html data - this scenario is not fundamentally different from directly rendering arbitrary HTML uploaded by users, whether it is Vue or not, it will lead to XSS, and the security section of our documentation also has a special warning about this practice. The responsibility of the front-end framework is to render the interface according to the template and data provided by the developer, and if the developer forcibly asks the framework to render an untrusted template and then accuses the framework of being unsafe, it is like rendering the untrusted content with innerHTML and then accusing the browser of having security vulnerabilities.
Finally, he emphasized: "As long as you follow universal front-end security common sense, Vue itself does not have any security problems." ”
For You Yuxi's reply, most netizens expressed support: "Can the front-end framework still have security vulnerabilities?" "Throwing the pot to Vue is really far-fetched."
But as a widely used open source software, it's normal for users to have concerns, especially after the Log4j breach.
Apache Log4j is an open source logging framework that is widely used in Java development. According to Google's security team, as of December 16, 2021, 35,863 available Java components from Maven Central rely on Log4j. This means that more than 8% of packages on Maven Central have at least one version affected by this vulnerability.
Therefore, since the Log4j vulnerability just broke out last year, it has attracted the attention of everyone in the security circle because of its large scope of impact and high degree of danger, and even the Ministry of Industry and Information Technology has given risk tips specifically for the Log4j vulnerability. The Belgian Ministry of Defense has also confirmed in the media that a cyberattack involving the Log4j vulnerability has occurred on its network.
On January 13, the White House also held an open source software security summit for the Log4j vulnerability, bringing together Google, Apple, Amazon, Microsoft and other major technology organizations, including the Apache Software Foundation (owner and maintainer of the Log4j library), Oracle (the owner of the Java software platform on which the Log4j library runs), GitHub and the Linux Open Source Foundation, to discuss the security of open source software.
Open source software security issues should not be overlooked
Today, open source software has become an important part of the software world, and according to Gartner, 99% of organizations use open source software in their IT systems. Gartner also said that most modern software is "assembled," not "developed." Well, in the same way that enterprises write their own source code, open source software is also at the source of the software supply chain. From source to delivery, each link may introduce supply chain security risks and thus be attacked, and the security problems of the upstream link will be passed on to the downstream link and magnified.
Some people think that open source software is in full view, and the vulnerability problem will not be too serious. But in reality, the security flaws in open source software are very dense. According to Qianxin's "2021 China Software Supply Chain Security Analysis Report", in the whole year of 2020, Qianxin Code Security Lab conducted security defect detection on 1364 open source software source codes, with a total code volume of 124296804 lines, and found a total of 1859129 security defects, of which 117738 were high-risk defects, the overall defect density was 14.96 / thousand lines, and the high-risk defect density was 0.95 / thousand lines. Moreover, the dependencies between open source software make vulnerability management of open source software very complicated.
This also means that in open source software, there is about one high-risk software defect in every 1,000 lines of code.
In an interview with InfoQ about open source security, Qianxin said that vulnerabilities are essentially "exploited network flaws" that are innate, but not every flaw will be exploited. Profit-seeking, curiosity is human nature, and when a flaw is found and exploited, the loophole is created. "So flaws are innate, vulnerabilities are inevitable, and cyberattacks are inevitable." Whether it's a front-end or a back-end, as long as there's code, vulnerabilities can occur. ”
Huang Yonggang, general manager of the code security division of Qianxin, also said in a previous interview: "Security began to shift to the left, and everyone began to pay attention to security work at the source. Open source software is the raw material of software development and the first security threshold for our information system development and construction. ”
In software development, whether it is technical aspects, or process and management aspects, any slight negligence will lead to security problems in open source software. Specifically, Huang Yonggang summarized three reasons:
There are problems with the open source software developer's own technical ability and security development knowledge, resulting in security defects in the developed code;
The development of most open source projects lacks the processes and tools of the SDL (Secure Development Lifecycle). Moreover, many open source projects can use very limited resources, lack of professional code security analysis tools, and most of the professional code security analysis tools are fee-based and expensive;
Attackers attack the open source ecosystem, such as injecting malicious code into open source libraries and putting malicious components into the package manager repository.
Five safety tips
How can I improve the security of open source software? Huang Yonggang believes that technically, open source projects need to more systematically introduce processes, methods and tools to ensure application security, such as SDL-based processes and concepts to manage the development process of open source projects, and popularize the knowledge of safe development for open source project developers. Second, use tools such as static source code analysis, dynamic security testing, interactive security testing, and comprehensive security testing of code submitted by open source project developers.
For software developers and enterprises, Huang Yonggang suggested strengthening the security governance of open source software from five aspects: introduction control, asset sorting, risk identification, vulnerability alarm and reasonable repair.
Introduce controls. Enterprises should standardize the introduction process of open source software and establish a mechanism for the safe introduction and exit of open source software. At the same time, the introduction of open source software needs to add security assessment factors, not only to evaluate whether the open source software introduced by the project team has open vulnerabilities and whether there are open source legal risks, but also enterprises should conduct integrity verification, whether the open source software comes from the official, and avoid using tampered open source software.
Asset grooming. Whether it is software developers or enterprises, they introduce a lot of open source software in the software development process. However, security managers and development managers are often unclear about how much open source software is introduced into their information systems and which open source software is introduced. Open source software has layers of nested dependencies, and it is difficult for software developers or companies to sort through manual methods. Therefore, it is recommended to use professional automation tools to identify which open source software is contained in the software system and the correlation between open source software, so as to form a visual asset list of enterprise open source software.
Risk identification. There may be known vulnerabilities in the open source software used in the software, and other open source software that is called or relied on behind these open source software may also have known security vulnerabilities. In the process of software development, enterprises should find open source software versions with vulnerabilities and upgrade them in a timely manner.
Vulnerability alerts. In the software operation stage, enterprises should monitor the open source software vulnerability intelligence information, timely discover the latest vulnerability information of the open source software, and carry out emergency response.
Reasonable fixes. The vast majority of open source software is bug fixes through version updates. For vulnerabilities that cannot be fixed by upgrading new versions or patching, enterprises should introduce professional vulnerability research teams to customize vulnerability repair solutions.