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=>
很明显,受害者的浏览器访问以上 URL 的时候,服务器端会跟正常情况下一样返回清单 1 中所示 HTML 页面,然后浏览器会继续将这个 HTML 解析成 DOM,DOM 中包含的 document 对象的 URL 属性将包含清单 3 中注入的脚本内容,当浏览器解析到 JavaScript 的时候会执行这段被注入的脚本,跨站点脚本编制攻击即成功实现。
值得关注的是,通过以上示例可以看出,恶意代码不需要嵌入服务器的响应中,基于 DOM 的跨站点脚本编制攻击也能成功。可能某些读者会认为:目前主流浏览器会自动转义 URL 中的 '<' 和 '>' 符号,转义后的注入脚本就不会被执行了,基于 DOM 的跨站点脚本编制也就不再有什么威胁了。这句话前半段是对的,但后半段就不准确了。我们要意识到攻击者可以很轻松地绕过浏览器对 URL 的转义,譬如攻击者可以利用锚点 '#' 来欺骗浏览器,如清单 4 所示。浏览器会认为 '#' 后面的都是片段信息,将不会做任何处理。
清单 4. 访问 URL 中结合锚点注入脚本
http://www.vulnerable.site/welcome.html#?name=>
通过 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