JavaScript common security vulnerabilities and automated detection technology_javascript skills

Foreword

With the development of Web2.0 and the popularity of the Ajax framework, rich client Web applications (Rich Internet Applications, RIA) are increasing day by day, and more and more logic has begun to be transferred from the server side to the client. These logics are usually All are written using JavaScript language. But unfortunately, developers generally don't pay much attention to the security of JavaScript code. According to the IBM X-Force 2011 mid-term trend report, 40% of the Fortune 500 websites and commonly known websites have JavaScript security vulnerabilities. This article will show readers common JavaScript security vulnerabilities in combination with code, aiming to help readers avoid these security vulnerabilities in daily coding work. In addition, the principles of client-side JavaScript security vulnerabilities are slightly different from those of server-side security vulnerabilities. There are currently major technical difficulties in automatically detecting JavsScript security vulnerabilities. This article will use cases to share with readers how to utilize the new features of IBM Rational AppScan Standard Edition V8.0 (JavaScript Security Analyzer (JSA) technology automatically detects JavaScript security vulnerabilities.

Common JavaScript security vulnerabilities

In December 2010, IBM released a white paper on client-side JavaScript security vulnerabilities in web applications, which introduced the JavaScript security status survey conducted by IBM Security Research Institute. The sample data includes 675 websites, including websites of Fortune 500 companies and another 175 well-known websites, including IT companies, web application security service companies, social networking sites, etc. In order not to affect the normal operation of these websites, the researchers used a non-intrusive crawler that scanned only a subset of pages that could be accessed without a login, no more than 200 pages per site. These pages were saved, and the researchers used IBM's JavaScript security analysis technology to analyze these pages offline, focusing on DOM-based cross-site scripting and redirection vulnerabilities.

The test results are amazing. 14% of these well-known websites have serious JavaScript security issues. Hackers can use these vulnerabilities to implant rogue software, implant phishing sites, and hijack user sessions. What's even more amazing is that with the maturity of IBM's JavaScript security analysis technology, the mid-2011 X-Force report showed that IBM retested the above-mentioned well-known websites and discovered more security vulnerabilities, about 40% of websites have JavaScript security vulnerabilities.

java enterprise-level universal permission security framework source code SpringMVC mybatis or hibernate ehcache shiro druid bootstrap HTML5

The following article will show readers these common JavaScript security vulnerabilities in combination with code, so that readers can notice these security issues during the actual coding process and avoid these risks as early as possible.

DOM-based cross-site scripting

We have all heard of XSS (Cross Site Script, also known as cross-site scripting attack), which refers to an attacker inserting malicious script code (usually HTML code and JavaScript) into legitimate web pages code) and then submits the request to the server, and then the server response page is implanted with the attacker's malicious script code. The attacker can use these malicious script codes to carry out attacks such as session hijacking. Cross-site scripting is generally divided into reflective and persistent types: reflective cross-site scripting occurs when request data is rendered unencoded and unfiltered in the server response page; persistent refers to request data that contains malicious code It is stored on the server of the Web application. Every time the user visits a certain page, the malicious code will be automatically executed. This kind of attack is particularly common for Web2.0 type social networking sites, and the threat is also greater. There are two main ways to deal with cross-site scripting: first, do not trust any user input and try to use whitelist technology to verify input parameters; second, escape the content provided by the user when outputting.

But little known is that there is a third type of cross-site scripting vulnerability. In 2005, Amit Klein published the white paper "DOM Based Cross Site Scripting or XSS of the Third Kind" ("DOM Based Cross Site Scripting or XSS of the Third Kind"), which revealed DOM-based cross-site scripting. The compilation of content does not need to rely on server-side responses. If some HTML pages use attributes of DOM elements such as document.location, document.URL, or document.referer, attackers can use these attributes to implant malicious scripts to implement DOM-based cross-reference. Site scripting attacks.

Below we will demonstrate the principle of DOM-based cross-site scripting through a very simple HTML page. Suppose there is a static HTML page (shown in Listing 1) that displays a message welcoming the user to a successful login.

List 1. HTML code with DOM based XSS

<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
 var pos=document.URL.indexOf("name=")+5;
 document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
Welcome to our system
…
</HTML>

按照该页面 JavaScript 代码逻辑，它会接受 URL 中传入的 name 参数并展示欢迎信息，如清单 2 所示：

清单 2. 正常情况下的访问 URL

http://www.vulnerable.site/welcome.html?name=Jeremy

但如果恶意攻击者输入类似如下的脚本，见清单 3，该页面则会执行被注入的 JavaScript 脚本。

清单 3. 访问 URL 中注入脚本

http://www.vulnerable.site/welcome.html?name=3f1c4e4b6b16bbbd69b2ee476dc4f83aalert(document.cookie)df15d2bd3a0797a114d79c25e114807b

很明显，受害者的浏览器访问以上 URL 的时候，服务器端会跟正常情况下一样返回清单 1 中所示 HTML 页面，然后浏览器会继续将这个 HTML 解析成 DOM，DOM 中包含的 document 对象的 URL 属性将包含清单 3 中注入的脚本内容，当浏览器解析到 JavaScript 的时候会执行这段被注入的脚本，跨站点脚本编制攻击即成功实现。

值得关注的是，通过以上示例可以看出，恶意代码不需要嵌入服务器的响应中，基于 DOM 的跨站点脚本编制攻击也能成功。可能某些读者会认为：目前主流浏览器会自动转义 URL 中的 '0b0d3c1d0eac9ad57b06cc87ca4baf9e' 符号，转义后的注入脚本就不会被执行了，基于 DOM 的跨站点脚本编制也就不再有什么威胁了。这句话前半段是对的，但后半段就不准确了。我们要意识到攻击者可以很轻松地绕过浏览器对 URL 的转义，譬如攻击者可以利用锚点 '#' 来欺骗浏览器，如清单 4 所示。浏览器会认为 '#' 后面的都是片段信息，将不会做任何处理。

清单 4. 访问 URL 中结合锚点注入脚本

http://www.vulnerable.site/welcome.html#?name=3f1c4e4b6b16bbbd69b2ee476dc4f83aalert(document.cookie)df15d2bd3a0797a114d79c25e114807b

通过 URL 重定向钓鱼

网络钓鱼是一个通称，代表试图欺骗用户交出私人信息，以便电子欺骗身份。通过 URL 重定向钓鱼指的是 Web 页面会采用 HTTP 参数来保存 URL 值，且 Web 页面的脚本会将请求重定向到该保存的 URL 上，攻击者可以将 HTTP 参数里的 URL 值改为指向恶意站点，从而顺利启用网络钓鱼欺骗当前用户并窃取用户凭证。清单 5 给出了较为常见的含有通过 URL 重定向钓鱼漏洞的代码片段。

清单 5. 执行重定向的 JavaScript 代码片段

<SCRIPT>
…
 var sData = document.location.search.substring(1);
 var sPos = sData.indexOf("url=") + 4;
 var ePos = sData.indexOf("&", sPos);
 var newURL;
 if (ePos< 0) {
 newURL = sData.substring(sPos);
 } else {
 newURL = sData.substring(sPos, ePos);
 }
 window.location.href = newURL;
…
</SCRIPT>

It can be seen that these JavaScript scripts are responsible for performing redirection, and the new address is intercepted from the attribute value of DOM elements such as document.location, document.URL, or document.referer, as shown in user input Listing 6.

Listing 6. URL to perform redirection

http://www.vulnerable.site/redirect.html?url=http://www.phishing.site

Apparently once the user executes the URL shown in Listing 6, they will be redirected to the phishing website. The principle of this vulnerability is simple and easier to understand than the server-side redirection vulnerability. However, in the case of phishing through URL redirection, the URL of the phishing site will not be intercepted and filtered by the server. Therefore, this vulnerability is often more concealed than the server-side redirection vulnerability.

Client JavaScript Cookie Reference

Cookies are usually created by the web server and stored in the client browser. They are used to save the user's identity, session information, and even authorization information on the client. Client-side JavaScript code can manipulate cookie data. If JavaScript is used on the client side to create or modify a site's cookies, an attacker can view the code, understand its logic by reading the code, and even use that knowledge to modify cookies. Once the cookie contains important information, such as permission information, attackers can easily exploit these vulnerabilities to conduct privilege escalation and other attacks.

JavaScript Hijacking

Many web applications utilize JSON as the data transfer mechanism for Ajax, which is usually vulnerable to JavaScript hijacking attacks, while traditional web applications are less vulnerable. JSON is actually a piece of JavaScript, usually in an array format. The attacker calls a JSON dynamic data interface of the attacked site through the 03c6714b8e3ee3238fc596020c4901e1 tag in the page of his malicious site, and obtains the JSON data through technologies such as JavaScript Function Hook. If the user logs in to the attacked website (assuming that the identity authentication information is saved based on the Session Cookie), and is lured by the attacker to visit the malicious site page, then, due to the af699be74605b5b2c644ebd2d249904c request with this tag Cookie information will be carried, and the malicious site will send a JSON data acquisition request to the attacked site. The attacked site server will consider the current request to be legitimate and return the relevant JSON data of the current user of the malicious site, thus causing the entire user data to be leaked. The process is equivalent to an off-site cross-site request forgery CSRF attack

.

With the further promotion of Ajax and the gradual application of HTML5, more client-side security vulnerabilities will appear. At present, there is not much security research on JavaScript. The newly launched HTML5 client-side storage, cross-domain communication and other new features are also closely related to security. Interested readers can read further. In view of the author's limited knowledge, I will not share so much about JavaScript-related security vulnerabilities. Next, I will talk about the detection technology of JavaScript security vulnerabilities.

Automated detection of JavaScript security vulnerabilities

As we all know, there are generally white box inspection and black box inspection to detect code security vulnerabilities. White box inspection focuses on the analysis of the code, either through manual code review or automated code analysis tools. Black box inspection mainly simulates hacker attacks for penetration testing. Generally speaking, black-box inspection has higher accuracy but smaller code coverage, while white-box inspection has higher code coverage but higher false positive rate. The combination of the two methods can make up for each other's shortcomings, and hybrid inspection methods will be the future trend.

In terms of JavaScript code, due to reasons such as cross-browser compatibility and better Ajax feature requirements, more and more web applications rely on third-party JavaScript code libraries, such as Dojo, JQuery, etc. In order to reduce the file size, these code libraries often compress the code, resulting in extremely poor readability, so manual code review is almost impossible. In addition, there are many entry points for JavaScript calls on the page, making manual penetration testing very labor intensive and difficult. Therefore, we need to recommend the use of automated testing tools to detect JavaScript security vulnerabilities.

A brief introduction to the principles of Rational AppScan JSA

JSA is a newly launched AppScan extension of Rational AppScan Standard V8.0, which is used to perform static JavaScript analysis to detect common client security vulnerabilities. JSA combines JavaScript static taint analysis technology and website dynamic crawler technology. In short, AppScan saves the complete HTTP response of all URLs explored by the crawler, and then JSA analyzes the JavaScript code of these response pages one by one. JSA applies two stages when analyzing each page: data flow analysis and string analysis. First, JSA looks for traces from the source to the sink that have not gone through the Sanitizer. If this trace can be found, JSA will verify it in a second step using a variant of string analysis called String Prefix Analysis (SPA). Compared with pure JavaScript code static analysis technology, JSA technology is more advanced and accurate because it analyzes security vulnerabilities in fully parsed HTML pages and DOM environments.

In today's Web2.0 websites and Ajax applications, HTML pages often require the browser to dynamically parse based on the HTML and JavaScript code in the server response to form complete HTML and DOM, which is purely based on the JavaScript code in the server response. Static taint analysis has an obvious flaw - the JavaScript code and execution environment it tests are not necessarily complete, so it cannot guarantee the accuracy and comprehensiveness of the test. JSA overcomes the above shortcomings, combines the advantages of white-box detection and black-box detection, and introduces IBM's string analysis technology, so JSA has better accuracy and comprehensiveness.

Use AppScan to detect JavaScript security vulnerabilities

Altoro Mutual is a web security vulnerability demonstration website provided by IBM. Below, the author will show readers how to use AppScan JSA to detect JavaScript security vulnerabilities in this website.

Start AppScan, click the menu "Scan - Scan Configuration" to open the scan configuration dialog box, and set the starting URL to "http://demo.testfire.net".

Figure 1. Set starting URL

On the left side of the scan configuration dialog, click "Login Management", then click the "Record..." button on the right to record the login process to ensure that detection is active during the session.

Figure 2. Set login method

On the left side of the scan configuration dialog box, click "Test Strategy" to check the test strategy settings. The default test strategy should be "Default", which already includes common JavaScript tests. You can click "Enabled/Disabled" to view the test strategies currently enabled by default.

Figure 3. Check test strategy

Close the scan configuration dialog box, click the menu "Scan -- Explore Only" or click the shortcut button (as shown in Figure 4) to start exploration. This article only illustrates how to detect JavaScript security vulnerabilities, so choose the "Explore Only" client-side JavaScript analysis test method.

Figure 4. Start exploration

Click the menu "Tools – Extensions – JavaScript Security Analyzer" or the shortcut button (as shown in Figure 5) to open "Analyze JavaScript". In the pop-up JavaScript Security Analyzer dialog box, click "Analyze Now".

Figure 5. Analyzing JavaScript

After the JavaScript Security Analyzer scan is completed, the client-side JavaScript security vulnerabilities found are listed in the results list. As shown in the figure below, the Altoro Mutual site has "DOM-based cross-site scripting" and "open redirection" vulnerabilities. The details of these vulnerabilities are shown below.

Figure 6. View scan results

Expand "DOM-based cross-site scripting" in the results list, click on the first "JavaScript" question, and its details will be displayed in the question information below. We can see that AppScan saves the analysis results of the JavaScript problem code and locates the source (Source) and sink (Sink) with yellow marks, which helps developers quickly fix the vulnerability.

Figure 7. DOM-based cross-site scripting issue information

Similarly, expand and view the "Open Redirect" issue. The code analysis results of this vulnerability are displayed in the issue information column.

Figure 8. Open redirect problem information

Note:

In order to quickly demonstrate how to detect JavaScript security vulnerabilities, this article chooses the "Explore Only" client-side JavaScript analysis test method. In actual work, it is recommended that you only need to scan as usual (that is, manual exploration combined with automatic exploration of the site, and then execute the test). AppScan will automatically execute JavaScript Security Analyzer during the test process by default.

Rational AppScan Standard can detect known common JavaScript security vulnerabilities, but Altoro Mutual only exhibits DOM-based cross-site scripting and redirection vulnerabilities, so the result list of this case only includes the above two security vulnerabilities.

Conclusion

java enterprise-level universal permission security framework source code SpringMVC mybatis or hibernate ehcache shiro druid bootstrap HTML5

This article introduces common security vulnerabilities in JavaScript and analyzes the technical difficulties in manually detecting JavaScript code. IBM Rational AppScan V8.x has newly launched the JSA extension component, which is the first in the industry to provide a client-side JavaScript security detection solution. This article shares the basic principles and technical advantages of JSA with readers, and uses cases to demonstrate to readers how to use IBM Rational AppScan JSA to test client-side JavaScript security.

There are problems and limitations in this article. Criticisms are welcome and we can learn and make progress together.