[
https://issues.apache.org/jira/browse/HDFS-5333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13805766#comment-13805766
]
Haohui Mai commented on HDFS-5333:
----------------------------------
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.
> Improvement of current HDFS Web UI
> ----------------------------------
>
> Key: HDFS-5333
> URL: https://issues.apache.org/jira/browse/HDFS-5333
> Project: Hadoop HDFS
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Jing Zhao
> Assignee: Haohui Mai
>
> This is an umbrella jira for improving the current JSP-based HDFS Web UI.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
