Thanks for the reply, Luke. Here I just echo my response from the jira: bq. this client-side js only approach, which is less secure than a progressively enhanced hybrid approach used by YARN. The recent gmail XSS fiasco highlights the issue.
I'm presenting an informal security analysis to compare the security of the old and the new web UIs. An attacker launches an XSS attack by injecting malicious code which are usually HTML or JavaScript fragments into the web page, so that the malicious code can have the same privileges of the web page. First, in the scope of XSS attacks, note that the threat models of launching XSS attacks on Internet sites Gmail/Linkedin and the one of the Hadoop UIs are different. They have fundamental different sets of external inputs that the attackers have control to. Internet sites have little control of these inputs. In the case of Gmail / Linkedin, an attack can send you a crafted e-mail, or put malicious description in his / her Linkedin profile. The sets of external inputs are *restricted* in Hadoop UIs. The new web UIs take JMX and WebHDFS as inputs. The attacker has to launch a XSS attack by: * Compromise the jars so that the output of JMX / WebHDFS have the malicious code. * Replace the web UIs completely to include the malicious code. In either case *the attacker has to compromise the hadoop core or the namenode*. That means the new web UIs are at least as secure as the hadoop core, and the namenode machine. Second, I argue that using client-side templates are more secure than the current JSP-based server-side templates. To defend against XSS attacks, both techniques have to filter the external inputs at *every* possible execution paths. Several facts much be taken into plays when evaluating the security of both approaches in real-world environments: * The JavaScript libraries used in the new web UIs have survived in extremely large-scale production tests. jQuery is used by Google and Microsoft, bootstrap is used by Twitter, and dust.js is used by Linkedin. All libraries survived from hundreds of thousands of attack attempts on a daily basis. I agree that the libraries might still be imperfect, but there's no way that we can test the JSP web UIs to achieve the same level of assurances given the amount of resources the community has. * Client-side templates consolidate all filtering logic in one central place. Recall that the goal is to filter all external inputs at every execution paths, this is a much more systematic approach compared to the server-side templates we have today. It is difficult (if not impossible) to do it in a JSP/ASP/PHP application, since such filtering can be only achieved via ad-hoc approaches ([1] shows some empirical data). Also, HDFS-4901 recently describes a XSS vulnerability in browseDirectory.jsp. bq. You'd require proper SSL (not self signed) setup to avoid JS injection Commodity browsers enforce Same-Origin Policy to defend against code injections. It has nothing to do with what kinds of SSL certificates you hold. bq. I also have concerns that we commit these changes without matching unit tests The JavaScript code can be automatically tested. The same code can be run by node.js and the test can compared with pre-defined results. It is also possible to write an adapter to use Rhino to accomplish the same task. We can discuss how to integrate them into the maven test routines in a different thread. bq. Client side rendering completely breaks the workflows for ops who rely on text based terminal/emacs/vim browsers (no js support) to monitor component UI. links / elinks (http://elinks.or.cz/) are text-based web browsers that support JavaScript. bq. The priority/requirements for UI in core Hadoop should be security and correctness, which client side templating cannot address properly so far. I agree that we should focus on security and correctness. The paragraphs above explain that how the architecture of the new UIs makes the UIs more secure in real-world settings compared to the UI we have today. References: 1. A. Yip et al. Improving Application Security with Data Flow Assertions. In SOSP'2009. On Fri, Oct 25, 2013 at 10:02 AM, Luke Lu <l...@apache.org> wrote: > Echoing my comments on HDFS-3555: > > I have concerns with this client-side js only approach, which is less > secure than a progressively enhanced hybrid approach used by YARN. The > recent gmail XSS fiasco highlights the issue. I also have concerns that we > commit these changes without matching unit tests – the fact you cannot > effectively unit test these changes should tell you something about this > approach. > > *Requiring* JS means that an admin cannot turn off js to (partially) use > core Hadoop UI. You'd *require* proper SSL (not self signed) setup to avoid > JS injection, even if security of js libraries used is perfect, which I > doubt (search gmail/linkedin XSS). Client side rendering completely breaks > the workflows for ops who rely on text based terminal/emacs/vim browsers > (no js support) to monitor component UI. > > IMO, JS-only rendering belongs to social networking sites and/or SaaS > front-ends, where full time UI/security specialists babysits UI changes. I > think eventually most users will use a self servicing UI in a SaaS > front-end that uses REST/JMX API to get data from back-end components, > besides their own app master/service UI. The priority/requirements for UI > in core Hadoop should be security and correctness, which client side > templating cannot address properly so far. > > > On Tue, Oct 22, 2013 at 3:59 PM, Haohui Mai <h...@hortonworks.com> wrote: > > > Hi all, > > > > > > Jing Zhao and I recently have reimplemented the JSP-based web UIs in > HTML 5 > > applications (HDFS-5333). Based on our prelimanary testing results we > > believe thst the new web UIs of the namenodes and the datanode are ready > > for everyday uses. > > > > You're more than welcome to try it out on trunk by visiting http:// > > <namenode>/dfshealth.html > > > > There are a number of benefits from this transition. From a developer's > > prospective, the most notable one is *maintainability*: > > > > (1) The abstractions between the UI and the core server are well-defined, > > decoupling the UI and the core hadoop servers. > > > > (2) It allows us to deprecate the logic in the JSP pages. The old web UIs > > have to duplicate the logic in the JSPs. The logic is often out-of-dated > > and not well-tested, which leads to broken pages and security > > vulnerabilities(e.g. HDFS-5251, HDFS-5307, HDFS-5308, HDFS-5317 and > > HDFS-4901). The architecture of the new UIs prevent these bugs at the > very > > beginning. > > > > > > I propose that deprecate the old, JSP-based web UIs in 2.3. I opened > > HDFS-5402 to track the relevant discussions. > > > > Your feedbacks are highly appreciated. > > > > > > Sincerely, > > > > Haohui > > > > -- > > CONFIDENTIALITY NOTICE > > NOTICE: This message is intended for the use of the individual or entity > to > > which it is addressed and may contain information that is confidential, > > privileged and exempt from disclosure under applicable law. If the reader > > of this message is not the intended recipient, you are hereby notified > that > > any printing, copying, dissemination, distribution, disclosure or > > forwarding of this communication is strictly prohibited. If you have > > received this communication in error, please contact the sender > immediately > > and delete it from your system. Thank You. > > > -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
