Objective
With the development of Web2.0 and the popularity of Ajax frameworks, rich-client Web applications (the rich Internet Applications,ria) are growing, and more and more logic has begun to shift from server to client, which is often used in JavaScript The language is written. Unfortunately, developers are generally less concerned about the security of JavaScript code. According to the IBM X-force 2011 medium-term Trend report, 40% of the world's top 500 websites and popular websites have JavaScript vulnerabilities. This article will combine code to present readers with common JavaScript security vulnerabilities designed to help readers circumvent these vulnerabilities in their day-to-day coding efforts. In addition, the client JavaScript security vulnerabilities and the principle of server-side security vulnerabilities slightly different, automated detection javsscript security vulnerabilities at present, there are large technical problems, this article will be combined with the case to share with readers how to use the IBM Rational appscan Standard Edition V8.0 new features (JavaScript security Analyzer,jsa) technology automates the detection of JavaScript vulnerabilities.
JavaScript Common Security vulnerabilities
In December 2010, IBM published a white paper on client-side JavaScript vulnerabilities in WEB applications, which describes the JavaScript Security survey that IBM security research has done. The sample data includes 675 websites, including the Fortune 500 company's website and 175 other famous websites, including IT companies, Web application security services, social networking sites, etc. In order not to affect the normal operation of these sites, the researchers used non-invasive crawler, scanning only the part of the page without login to access, each site does not exceed 200 pages. These pages were saved, and the researchers analyzed the pages off-line using IBM's JavaScript security analysis technology, focusing on the DOM-based cross-site scripting and redirection vulnerabilities.
The test results are stunning, with 14% of these well-known sites having serious JavaScript security problems that hackers can use to embed rogue software, implant phishing sites, and hijack user conversations. What's even more amazing is that with the maturity of IBM's JavaScript Security Analytics technology, the 2011 Interim X-force report shows that IBM has tested these well-known sites and found more security vulnerabilities, with about 40% of web sites having JavaScript security vulnerabilities 。
Java Enterprise Generic Permissions security framework source code SPRINGMVC MyBatis or Hibernate+ehcache Shiro Druid Bootstrap HTML5
This article will combine the code to present the reader with common JavaScript vulnerabilities so that readers can avoid these risks when they are aware of these security issues during the actual coding process.
DOM-based cross-site scripting
We've all heard of XSS (Cross site script, cross-site scripting, also known as cross-site scripting attacks), meaning that attackers insert malicious scripting code (usually HTML code and JavaScript code) into a legitimate Web page and then submit a request to the server. Then the server Response page was implanted with the attacker's malicious scripting code, which could allow attackers to use these malicious scripting code for session hijacking and other attacks. Cross-site scripting is typically divided into reflective and persistent types: reflective Cross-site scripting when the request data renders in the server Response page as not encoded and unfiltered; persistence refers to the request data containing malicious code being saved on the WEB application server, each time a user accesses a page, Malicious code is automatically executed, which is particularly common and more threatening for Web2.0 types of social networking sites. There are two main approaches to Cross-site scripting: First, do not trust any input from users, try to use whitelist technology to validate input parameters, and second, the output of the user provided content to escape processing.
But little is known about a third Cross-site scripting vulnerability. 2005 Amit Klein published the white Paper "Dom-based Cross-site scripting-the third type of cross-site scripting" ("DOM Based Cross site scripting or XSS third Kind"), which reveals the D Cross-site scripting for OM does not require content that relies on server-side responses, if some HTML pages use Document.location, document. The properties of a DOM element, such as a URL or document.referer, that an attacker could use to embed a malicious script to implement a Cross-site scripting attack based on DOM.
Here's a very simple HTML page to demonstrate the principle of Cross-site scripting based on DOM. Suppose you have such a static HTML page (shown in Listing 1) to show you the information that welcomes the user's successful logon.
Listing 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>
Following the page's JavaScript code logic, it accepts the name parameter passed in the URL and displays the welcome information, as shown in Listing 2:
Listing 2. The normal access URL
Http://www.vulnerable.site/welcome.html?name=Jeremy
But if a malicious attacker enters a script similar to the following, see Listing 3, the page executes the injected JavaScript script.
Listing 3. Inject script in Access URL
Alert (Document.cookie)Http://www.vulnerable.site/welcome.html?name=