Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HDFS >> mail # dev >> Replacing the JSP web UIs to HTML 5 applications

Copy link to this message
Re: Replacing the JSP web UIs to HTML 5 applications
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

* 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

bq. You'd require proper SSL (not self signed) setup to avoid JS

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


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 <[EMAIL PROTECTED]> wrote:
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.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB